totikom
@totikom@lemmy.ml
- Comment on Backups made easy: btrfs + snapper + snapborg 1 week ago:
Backing up via snapborg allows you to see file structure, because actually it is a file-based backup.
snapperhere allows me to separate snapshot creation from actual backups. - Comment on Backups made easy: btrfs + snapper + snapborg 1 week ago:
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,/etcand other folders.However, the proposed workflow could be adapted to both scenarios: a single
snapborgconfig backs up snapshots from a single subvolume, so I, actually, use two configs: one for/homeexcluding/home/.home_unbackedand another one for/excluding/varand 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/homebackup without restoring/. - Comment on Backups made easy: btrfs + snapper + snapborg 1 week ago:
btrbkrequires, that destination disk is also formatted as btrfs.I didn’t want to have such constrain.
- Comment on Backups made easy: btrfs + snapper + snapborg 1 week ago:
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.
- Comment on Backups made easy: btrfs + snapper + snapborg 1 week ago:
Thanks. :3
- Comment on Backups made easy: btrfs + snapper + snapborg 1 week ago:
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.
- Submitted 1 week ago to selfhosted@lemmy.world | 19 comments
- Submitted 1 week ago to technology@lemmy.world | 2 comments