digint / digint/btrbk

`btrbk archive`: consider removing same-volume prohibition

Open
#610 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Perl
Stars
2.1k
Forks
139
PR merge metrics
No merged PRs in 30d

Description

`ERROR: Source and target subvolumes are on the same btrfs filesystem!`

I just hit this. It makes sense on its face, but I've found use cases for same-volume `btrbk archive` recently.

For the snapshots for a given machine, both on the "home" disk for that subvol and any backup drives or remote targets, I used to use the directory scheme `.btrbk/$MACHINE_NAME`, but now I use: `.btrbk/$MACHINE_NAME/$VOLUME_NAME`. This works much better because it's always obvious whether a particular snapshot set "belongs" on a given disk.

Given btrfs's ongoing bugs around snapshot moves/renames (it used to prohibit moves and renames, now it only blocks moves), and the recent closure of the only workaround (temporarily making each snapshot writeable) that properly preserves parent relationships — without properly fixing the bugs — my options for reorganising snapshot trees are a bit limited.

However, I've found that since `btrfs receive` magically finds parents and clone sources wherever they are on the volume, I can exploit incremental send to duplicate a snapshot set, in a different directory on the same disk, in a way that neither spoils incremental lineage nor duplicates the data.

This is all to say that there are valid use cases for `btrbk archive` on the same disk. **IMO this should not be an error, only a warning.**

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.