snap-sync VS linux-timemachine

- https://github.com/qubidt/snap-sync

You might be interested in snap-sync. It is a bash script which accomplishes btrfs backups using snapper under the hood. So no need to use btrbk (but you get all the same functionality).

I've been using snapper and snap-sync for automated snapshots and backups to an external drive. Recently, snap-sync is no longer maintained, and it may not be able to do some more things that I want to do, such as:

I was actively using snap-sync to back up my files to a local hard drive. Unfortunately, snap-sync will be retired soon.

I use snapper for snapshots and snap-sync for backing up said snapshots on an external drive.

Yeah, I use snapshots for backups using snap-sync, which is a convenience script around btrfs send. Personally I use it to back up onto an external HDD, but it can also do remote backups over SSH. I'm just not sure if remote backups are incremental or not.

On my laptop I make extensive use of openSUSE's snapper and the snap-sync script to sync to two external USB drives. Lastly, I wrote a script to clean/expire snapshots on the external volumes.

Snapshots aren't proper backups by themselves; they don't protect you from disk failure or the entire filesystem somehow being corrupted. It is possible to use them as backups; personally I use a command-line script called snap-sync to do this. This has the advantage of retaining the incremental nature of snapshots (though the incrementality will be on your backup media, so the first snapshot of a 100GB filesystem you put on your backup drive will take up 100GB of space), plus it integrates nicely with Snapper which is the snapshot utility I use.

> I am concerned about the longevity of my archives

If you're concerned about archival longevity, and I for one certainly are, then maybe consider not to compress at all. Both compression and encryption add to obscurity and loss of redundancy in the backup. Using a widely understood file system and a very obvious arrangement of the data (for me that means: directories with dates, below a tree of files that mimics their original locations) will be a huge plus should the data have to be recovered at some point in the future.

Personally I am using a slightly adapted version of https://github.com/cytopia/linux-timemachine for this task. You do get de-duplication for the file transfer, but each file is written as it was on the target. You'll get a timestamped directory for each time a backup was run. Like MacOS' timemachine, the script uses hard links to de-duplicate identical files across different timestamped directories so the overall space requirement for that incremental backup you did an hour or a day later can be very small.

I can certify that this setup, while it does not occupy the least conceivable amount of storage area, is very amenable to be searched and trivial to use for recovery. much better in this regard than any kind of compressed archive format which are always a pain in terms of searchability and so on.

And for file version history and to protect against accidental deletion i use linux-timemachine which backs up over SSH to the same server and keeps versioned incremental backups. This backup also includes my entire /home folder so all apps, appdata and config is contained here.

Linux-TimeMachine: https://github.com/cytopia/linux-timemachine

If you only want to backup specific folders i like the tool linux-timemachine which uses rsync and hardlinks to create incremental backups based on a input and output folder.

You know, another option might be to just rely on something external to your machine if you're worried enough. When I'm dealing with personal machines (usually servers) that are important to me, I usually use Backblaze B2. You could maybe even try using open source variants of Time Machine designed for Linux machines or Borg Backup...though, to be fair, I've never really tried using them for backing up my entire system ( "/" ) partition (https://github.com/cytopia/linux-timemachine).

linux-timemachine