Bacula has been around a long time. I think it should be added to the list. See Bacula.org

http://www.opbyte.it/grsync/

cc: https://github.com/n1trux/awesome-sysadmin#backups

See: https://badgen.net/github/stars/micromatch/micromatch

http://luckybackup.sourceforge.net/

Solution comes preinstalled in most popular Linux distro: MX-Linux

Creates filesystem snapshots using rsync+hardlinks, kind of as TimeShift, but for data files.

Project "LuckyBackup is almost frozen", but author said: "I will not stop supporting this project"

To this day, this is the best collection of structured database about backups ( at least what I know of ) but to make it even more useful, a simple web search function could be implemented.

A bit like https://gsl.dome9.com/, a static page, with inline json, and js filters rendered into a table, with a somewhat good front-end guy it should be a piece of cake, and then github pages can host it as well, job done.

I personally happy to help with the GitHub Actions, and GitHub pages side of it, even the data conversion from md to json or yaml, but the js is beyond me ...

Déjà Dup is missing from the list

https://wiki.gnome.org/Apps/DejaDup

It's a simple, easy to use wrapper for Duplicity and was once incorporated with Ubuntu. It's nothing special but the ease of use for many home users is significant. Mission: "aim to convert people who don't currently have backups into people that do."

https://www.linux.com/topic/desktop/total-system-backup-and-recall-deja-dup/ (a bit dated but ok)

I use and recommend BackInTime for backups with a GUI but it seems to be dying, which is why I checked on this one and scanned your list. My other backup tools are Borg and Timeshift.

You have:

borg review,dedup,encrypted,python,authenticated

I may be misunderstanding, but you want "incremental" with this, also? Borg does so-called "forever-incremental" backups, as does bup.

Ah, I also see you have:

bup review,dedup,incremental,error-correction

But bup can also encrypt when used with encbuf.

https://freefilesync.org/

(I may investigate more later and close this issue in favor of a pull request)

According to this post:
https://blog.liw.fi/posts/2017/08/13/retiring_obnam/
obnam is unmaintained, or at least soon unmaintained.

Thanks for your list! I was looking for just the thing. I'm trying to determine what to invest in personally before exporting to an organization I administrate and the quick overview here is fantastic.

While reviewing, I thought some new tags that could be added to this list are the following.

• concurrent/simultaneous backups, or multiple sources to one backup repo
• supports an ignore file/source

http://x-ryl669.github.io/Frost/

While researching backup solutions, I found that there are fundamental differences in the way the backups themselves are stored.

A prime concern for me is compatibility and being able to read/restore backups with minimal tooling. From this perspective, backup solutions seem to fall into two broad categories:

• restic, borg, bup: the backup is a git repo, it cannot be read without the software that created it
• rsnapshot, backintime: the backup is just a folder structure with copies of the files inside, readable like any other folder structure (however: no deduplication, native encryption etc.)

Do you think there's a good way to incorporate these into your list? Approproate tags might be plaintext and git, and possibly others.

I used it for a lot of time.
It suppports S3-sompatible storages, authenticated, compressing, incremental backups, dedup, gpg (with manual settings, but works), ssh support

https://github.com/bit-team/backintime

Awesome list, thanks for doing this massive amount of work!

I'd like to suggest a project that was missed - https://github.com/wamdam/backy2

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.

the TODO currently states:

In the future we plan to provide benchmarks using fakedatafs and a table to sort by the tag categories.

i have looked in the latter, and it seems to me the simplest solution would be to have one page per backup software and use some sort of page metadata to enumerate which tags apply to which page. this would probably imply the use of a static site generator.

having one page per software would also allow those page to feature benchmarks and other data about the tools.

i haven't reviewed the SSG alternatives in detail, but here's the one i thought would be worth mentioning:

• Jekyll: Ruby, builtin to Github pages, which avoids committing HTML to git, but tags are not well supported which forces committing HTML to git in the end
• Hugo: Go, requires publishing rendered pages into git, has taxonomies which could be used for this, but requires a template supporting those, not sure about filtering/sorting
• Ikiwiki: Perl, doesn't support github pages out of the box, crude support for tags, which are pages you link to, limited filtering support

Also note that Gitlab pages support any arbitrary SSG, not just Jekyll, which may make deployment easier because it doesn't require committing rendered content into git - it's just part of the regular CI system.

Hi,

rdiff-backup is back now. I am going to implement it on our system. I'll provide more updates later, but I think you can remove the tag unmaintained.

Hope this helps. By the way, you guys have a great list.

Thank you.

Some of us need offline storage. Tapes / DVD to a safe in a different building gives disaster recovery.
Sometimes it can't be sent over the network to another server either.