3 ms·

The "simpleness" in Snebu comes from using standardized tools such as find and tar, file storage using LZOP, and the backup catalog in a standard SQLite3 DB, al

The "simpleness" in Snebu comes from using standardized tools such as find and tar, file storage using LZOP, and the backup catalog in a standard SQLite3 DB, allowing manual recovery of files. However Restic and Borg do have the advantage of writing directly to cloud backups or "dumb" backend data stores such as sftp targets, or API-accessed cloud targets (although Restic doesn't compress and Borg has issues with multiple hosts going to the same repository, they do still have their use cases). Whereas Snebu is more of the use case that would be solved by more complicated to manage tools such as Bacula, Amanda, or commercial backup solutions but with lower setup and administrative requirements.

deleted 6y ago
[deleted]
Aachen 6y ago
> Restic doesn't compress I didn't actually know that, that's kinda weird. It doesn't seem to be vital to deduplication, looking at https://github.com/restic/restic/pull/2441 https://github.com/restic/restic/pull/2441, they just didn't originally implement it and are now wondering how to best introduce this breaking change (can be forwards compatible, but of course not backwards), trying to get it right in one try, keeping the format "robust", adding other breaking changes while they're at it... wonder if this will happen any time soon. To be honest, though, 98% of the time large files (anything over a few hundred kilobytes) is in a format that compresses to a certain extent. Pictures, audio, even text documents and spreadsheets are compressed these days. One person mentions huge XML files which sounds like they really should have been using a different tool (not a text file for starters, if you're not going to read through those gigabytes of text anyway), but there are other use cases like somewhat sparse database tables or disk images or so. Then again, if you have the space for those original files, doubling the space for a reserve copy is usually not a deal breaker, and Restic also deduplicates within and between files so if something were to be very redundant and compressible it is also likely to be caught by that algorithm. I'm not against increasing the complexity to add it, and breaking compatibility of course---it's a clear downside of Restic to not have this---but I also don't really get anyone who considers it a deal breaker (and only to an extent those that find it a big deal). Either way, thanks for pointing this out, I didn't know (and made an incorrect assumption since it seems so standard) and it's good to know about.

deleted 6y ago

[deleted]

Aachen 6y ago

> Restic doesn't compress I didn't actually know that, that's kinda weird. It doesn't seem to be vital to deduplication, looking at https://github.com/restic/restic/pull/2441 https://github.com/restic/restic/pull/2441, they just didn't originally implement it and are now wondering how to best introduce this breaking change (can be forwards compatible, but of course not backwards), trying to get it right in one try, keeping the format "robust", adding other breaking changes while they're at it... wonder if this will happen any time soon. To be honest, though, 98% of the time large files (anything over a few hundred kilobytes) is in a format that compresses to a certain extent. Pictures, audio, even text documents and spreadsheets are compressed these days. One person mentions huge XML files which sounds like they really should have been using a different tool (not a text file for starters, if you're not going to read through those gigabytes of text anyway), but there are other use cases like somewhat sparse database tables or disk images or so. Then again, if you have the space for those original files, doubling the space for a reserve copy is usually not a deal breaker, and Restic also deduplicates within and between files so if something were to be very redundant and compressible it is also likely to be caught by that algorithm. I'm not against increasing the complexity to add it, and breaking compatibility of course---it's a clear downside of Restic to not have this---but I also don't really get anyone who considers it a deal breaker (and only to an extent those that find it a big deal). Either way, thanks for pointing this out, I didn't know (and made an incorrect assumption since it seems so standard) and it's good to know about.