totikom

Backing up via snapborg allows you to see file structure, because actually it is a file-based backup. snapper here allows me to separate snapshot creation from actual backups.

I guess we disagree about the point of backups then.

We just use different threat models.)

For me, the main threat is disk failure, so I want to get new disk, restore system from backup and continue as if nothing happened.

Surely, if your hardware or OS configuration changes, you should not backup /usr, /etc and other folders.

However, the proposed workflow could be adapted to both scenarios: a single snapborg config backs up snapshots from a single subvolume, so I, actually, use two configs: one for /home excluding /home/.home_unbacked and another one for / excluding /var and some other directories. This two configs have different backup schedule and different retention policies, so in case of hardware/OS change, I'll just restore only /home backup without restoring /.

btrbk requires, that destination disk is also formatted as btrfs.

I didn't want to have such constrain.

Snapshots are made atomically, so this workflow allows you to separate snapshot creation from actual backing up.

As subvolumes are dynamically sized, you can create as many subvols as you like and backup those, that need it.

Thanks. :3

BcacheFS also supports snapshots, so I think that it should be relatively easy to port snapper to it. Probably, it is already done, but I haven't checked.