I hope to find some specialists on this question here, maybe @dalto for having already mentioned it?
I’m looking into an external backup system for my btrfs volumes. I’ve already tried btrbk, which gives me satisfaction, but I’ve also seen snapborg (I use borgbackup via vorta elsewhere, so I’m very satisfied).
My question concerns snapborg. What exactly does snapborg do compared to btrbk? It copies sub-volumes in a btrfs backup or not (because when I mount my backup, I don’t see my sub-volume, which I call @, but only the tree @ contains), whereas btrbk copies the sub-volume in read-only mode to the external media.
So I’m wondering: what’s the advantage of using snapborg over btrbk?
Space saving due to deduplication, compression, incremental backup or not at all? Does restoration involve creating an empty sub-volume into which you just copy the tree structure (in which case it takes longer than recovering a backup with the send-receive option, moreover a simple rsync can do that …)?
the advantage of keeping the contents of the sub-volume on a Borg repository external to the disk?
a convenient backup solution revolving around a single snapper software rather than a multiplication of tools, snapper for one use, btrbk for another (e.g. backup of subvolumes on external media? ).
… so far, not really convinced by snapborg, because of these grey areas
I have actually never heard of snapborg. However, I just took a look at that and it looks pretty cool.
I will have to try it out sometime to see how well it works but it looks like it lets you take your snapper snapshots into borg selectively.
The advantages of this over a purely btrfs solution are that btrfs snapshots live inside the btrfs filesystem. You can replicate them to another disk or remote machine but those still must be btrfs.
On the other hand, borg is filesystem agnostic. You can store borg backups anywhere. You could even replicate them to a cloud storage location if you wanted to.
That being said, you could achieve the same thing by simply doing borg backups of your data directly. This tool just lets you use your snapshots as the source and shares some config with snapper.
Btrfs snapshot replication also has these same benefits. If you are already replicating your snapshots to a remote target, I don’t see much benefit here.
Yeah, if you aren’t replicating your snapshots, this is a huge advantage.
I’m not even able to exple restore my system after saving the subvolume in borg.
i even rotted my system :-), fortunately a good btrbk backup on usb key has fortunately restored everything intact in a few minutes (btrfs send-receive, then a new snapshot of the backup once on my system). Incidentally, I’ve seen that you shouldn’t play around with changing the properties of a snaphot, and that it’s not a good practice (e.g. for incremental snapshots, where you have to identify the last parant ie btrbk).
So the question remains, how do you restore from snapborg?
I’d imagine, for example, by mounting the backup anywhere:
e.g. /home/falke/office/mounting_backup
and also mount the system (let assumed @endevour) sub-volume created empty
sudo mount /dev/sda2 -o subvol=@endeavour /home/falke/Bureau/restore_backup
then paste all mount point files under /home/falke/Bureau/restore_backup and finally unmount all previous mountages.
I think it is intended to be used in addition to a “normal” snapshotting routine. You could, for example, have snapborg backups that capture more snapshot history than your timeline retention settings are configured to save. Maybe you keep two monthly snapshots on the local disk, but the Borg device keeps 24 for example.
With this kind of setup, almost always the “normal” snapshots" will be more appropriate for snapshot restoration. The Borg stuff would be useful for situations like “Oh I had that one file a couple months ago”, or “Let me see how I used to have this config set up last year”. Whole hog restoration is still possible, but in most cases it would be easier and better to use the snapshots on the disk for that.
snapborg has an issue open for this if you want to chime in with your opinion or ideas:
Personally I agree with the author’s comment here:
I think adding an automated restore functionality would be quite complicated and dangerous to implement. But maybe adding a wrapper around commands like borg mount or borg extract could be provided. However, I’m not sure what the benefits of that would be over doing something like
borg list <borg_repo>
choose an archive/snapshot to restore from
borg mount ... or borg extract ... this exact archive
ok, just useful for picking up a few files here and there, but not for restoring a system (or even data). Indeed, snapshots under snapper have my username or group name, those under snapborg are root, a pain to see them in snapper you have to change the rights, but also to restore them, you have to change the rights back to root (when you’ve changed them to see them in snapper) … I’m not sure that borg keeps symbolic links either…
No, you can restore an entire data set. I use borg as part of my backup strategy.
Borg can backup and restore symbolic links.
You shouldn’t have to change the ownership of the files in the snapshots. If you do, things will be wrong once you try to restore them which should be expected. Better to simply not change them in the first place.