tarsnap VS casync

Tarsnap for configs and critical stuff (password database, emails).

Someone does :)

https://tarsnap.com

> Tarsnap uses a prepaid model based on actual usage:

> Storage: 250 picodollars / byte-month of encoded data

Colin Percival's tarsnap

In past threads, people have mentioned enjoying my Tarsnap (https://github.com/Tarsnap/tarsnap) code. I personally think that the spiped (https://github.com/Tarsnap/spiped) code is even better.

I prefer Vorta myself ( https://github.com/borgbase/vorta ) as it also has incremental and encrypted backups, as well as being a fraction of the price, but tarsnap seems to still be in very-slow development: https://github.com/Tarsnap/tarsnap , so I'd say from a quick look it's still trustworthy.

Each server also upload their configs and « important » data (my mails and git repos) to tarsnap 3. Tarsnap storage is not as cheap as B2, so I try not to upload too much data there, but it's reliable and easy to use. It was also my first backup solution, and barely cost me 10$ a year so I keep it as a secondary backup.

Not foolish! The Tarsnap client code is open source, but the license file prohibits anyone from using the code: https://github.com/Tarsnap/tarsnap/blob/master/COPYING

> Redistribution and use in source and binary forms, without modification,

Yes. For the curious,

https://github.com/Tarsnap/tarsnap/graphs/contributors

For arbitrary state changes however, it's better to use something like casync. Note that there are a lot of tunables, implicit and explicit; for package indexing I would particularly think about "how is the index sorted" and "what is the desired chunk size".

If you just want something practical to play with, see casync. Even if it doesn't fit your workflow, or if you think you can do better, chances are you're best off building on top of it or adding patches to it, not starting from scratch.

You probably want casync.

Obligatory link to casync, which implements this better than most alternatives.

(personally, I think more people need to be aware of casync for the update storage/distribution problem. It isn't perfect for every use case, but it's good enough that you're probably better off wrapping/forking it rather than reimplementing it badly from scratch)

Does something like casync (https://github.com/systemd/casync or https://github.com/folbricht/desync) serve any purpose or provide any advantage to propagating rpm changes over rsync?

Software that comes to mind for syncing lots of small files: git (and other source versioning tools), casync (https://github.com/systemd/casync) and a go implementation (https://github.com/folbricht/desync). Not really an answer and I can't think of a way to shoehorn that into your workflow, but maybe it leads you down a useful road.

Casync – A Content-Addressable Data Synchronization Tool\ (15 comments)