Snapshot directories about btrfs-sxbackup HOT 5 CLOSED

The code seems to be very thoroughly written, congratulations

thank you.

you're right, conceptually it's not well documented atm which can lead to misunderstandings.

.sxbackup is actually the default source container for local snapshots and should not be used as a destination. there's currently no sanity check preventing this.

I believe it would be best to manually clean this up (remove all subvolumes that have been created) and start over using a dedicated destination subvolume of your own.

.sxbackup will be created on init for storing the backup job configuration and local snapshots.
If all you need is local snapshots you can actually omit the destination entirely.

here's some examples

Local snapshots only

init /

Push backups locally

init / /mnt/backup/host1

Push backups remotely

init / ssh://root@destination:/mnt/backup/host1

Pull backups remotely

init ssh://root@source:/ /mnt/backup/host1

When using a push backup setup you invoke run on the source machine with the source volume as parameter

run /

When using a pull backup setup you invoke run on the destination machine with the destination volume as parameter.

run /mnt/backup/host1

hence the ambiguity you've been pointing out.

btrfs-sxbackup only maintains individual backup jobs and has no intent of providing comprehensive management.

eg. you could run or schedule multiple jobs at once using run /mnt/backup/*

from btrfs-sxbackup.

Thank you. I think the choice of a fixed name/path /.sxbackup for the local container is a bit unfortunate. It doesn't provide enough flexibility. But thanks anyway.

from btrfs-sxbackup.

enough flexibility for?

from btrfs-sxbackup.

I am mounting my root fs as a subvolume (called '@'), and would like to keep my local snapshots in a subvolume outside of @, at the same level (parent of 5, if I remember correctly). Can this be achieved with sxbackup?

from btrfs-sxbackup.

yes, you can move .sxbackup after init and amend .btrfs-sxbackup accordingly.

however, this may imply breakage of some features relying on this convention (which are not implemented yet and you may not require, see enhancement issues)

all core operations should remain intact.

from btrfs-sxbackup.