my notes

[sbuller]

I went through the links you provided here (thank you), and thought I'd share my notes. I make no promises of any sort of consistency; the things that stuck out to me are no doubt related to my individual requirements and views. I mostly stuck to items from the existing list that didn't have any tags besides 'review'.

I noted a couple properties that I summarize here for brevity in the later list:
dbsrc - backup a database by properly dumping its data, rather than simply copying its files.
repo - rather than creating separate archives (tarball or similar), the program operates on a repository/store. Highly correlated with (proper) dedup.

Arqinator - just a reader for backups produced by the proprietary Arq
backshift - dedup, compression, expiration, python, source in svn*
backup - ruby, dbsrc, remote dst, no-dedup, no-incremental, sync, notification
backup2l - heirarchical incremental tarballs, https://github.com/gkiefer/backup2l, shell script
backuppc - perl, file-dedup (not block dedup), admin interface/daemon, client/server
Backups-Done-Right - proposal, no code
bareos - client/server, fork of bacula, incremental
boxbackup - c++, client/server, continuous
btar - c, complicated build around tarballs
btrbk - perl, btrfs, encryption
burp - c, client/server, compression, dedup, librsync deltas, configurable retention
chop-backup - c, 'beta', not active
dar - pre-github scm, differential, compression, encryption, checksums, multi-archive
ddar - dedup, repo*, unmaintained, c/python
deltaic - python, single author, low activity, script over lvm thin pools
duplicity - librsync, active, encryption, incremental tarballs
fwbackups - gui, tar, rsync, maintenance only
frost - dedup, compression, encryption, single dev, low activity, c++, no built in xfer**
hashbackup - dedup, compression, encryption, unpruned repo, proprietary/no source
kebab - inactive (2015)
knoxite - golang, single dev, encryption, dedup, backend sharding, repo, missing docs
obnam - repo, dedup, encryption, sftp, python, c?, repo, single tier pruning strategy
ori - not targeted at backup, p2p, slow development, c++
pukcab - repo, dedup, compression, ssh, retention schedules, web interface (client/server?), single dev, moderately active, '[enthusiast grade]'
rdedup - dedup, encryption, compression, rust, moderate activity, beta
scat - decentralized storage, dedup, erasure codes, checksums, multiple copies, toolbox approach
rsnapshot - hard link dedup, perl, active
shield - dbsrc,
snaprd - single dev, golang, pruning, hardlink dedup
snebu - client/server, compression, file-level dedup, data expiration, c, single dev, low activity
s3git - golang, dedup, distributed, inactive
storeBackup - 'CVS' level inactivity
ugarit - fossil required to view source, no recent release, dedup
unison - no snapshots just synchronization
urBackup - client/server, web ui, file dedup, c, commercial version
veb - golang, abandoned
zbackup - dedup, compression, encryption, c++, sporadic development
zpaq - repo, dedup, compression, checksum, revision control by zip file? 😱

* this is a thing I care about—projects on github are much easier to evaluate for maturity and activity

** The degree to which designs take a local or remote approach varies significantly. For my purposes I want to have remotes that pull data from an intermediary which has access to the source data, and so not having any built in facility for managing remote backends isn't necessarily worse than anything else. Ideally (I think) I'd have a client on the remotes which could see only encrypted data, but could selectively download (shard), and prune old data using limited unencrypted metadata. But that's neither here nor there.

[fd0]

Nice, thanks for leaving your notes! I'm not sure what to do with this issue. Leave it open? Close it?

[sbuller]

I'm not sure either. Your choice.

[fd0]

I'll leave it open, it's a bit easier to find.

[cfcs]

Thank you, this is very useful.

I wish I was better at JavaScript and could navigate the jungle of fancy toolkits to generate tables, in order to hack together an interface for this list that would let you sort on multiple tags + hide irrelevant projects (blacklisting by tag). If someone feels confident making something like that, that'd be incredibly nice too IMHO. See #13

Some thoughts on your notes:

• For dbsrc I imagine it'd be optimal for restic's content-defined chunker if the tool produces the same output on every execution (either the same order when new records are added, or newest-last). Perhaps we should have a tag for that property, and in any case we should probably split out tools that only deal with extracting data from applications to the ones that result in concrete backup files.
• I'm a bit wary of adding tags like moderate activity since that leaves us with the responsibility of monitoring progress and updating our tags accordingly.
  • inactive is not necessarily a bad thing - only if there are bugs :-)
• Backups-Done-Right - proposal, no code - perhaps we should move things that do not have executable code to a different section, since it's pretty useless when evaluating which tool to use for your backups (which I imagine is the main purpose of this listing, apart from getting an overview of state-of-the-art).

[cfcs]

PS: I think we should leave this open until we incorporate the comments somehow; this is useful research, and if we close the issue it will be much harder to find.

[tobypeschel]

Thanks for posting these notes, very useful alongside the main list.

[marcosviniciusb]

Hello @sbuller, I respect your opinion and reaffirm that really a GUI that would allow you to manage several servers like Bacula Enterprise would be great, but generally this type of solution costs a lot of money and only big companies can afford it.

On the other hand, I see that having a functional, lightweight backup program with important back-end backup features working on multi-platform is far more important than a GUI.
We have several GUI backup softwares that do not work as well as Restic.

As for your need to manage multiple servers, I say that you can solve the problem with a shell script running Restic (I'm working on a simple shell script for Restic that saves the task log and in case of error send an email from warning via curl, which could also be a call to an SMS or Telegram API, but I decided to use email as a warning because our support management platform converts email into ticket.
With this ready script, you can use Ansible to maintain, update, manage, and update this script on tens or thousands of servers in an automated and centralized way.

[jtagcat]

Nice, thanks for leaving your notes! I'm not sure what to do with this issue. Leave it open? Close it?

Maybe add it to the wiki and reference the wiki in the readme?

[jtagcat]

Can anyone help me compare Restic to Bup (and Borg)?