Mbitzg · August 29, 2015 14:20
diff --git a/Linux-backup.txt b/Linux-backup.txt
 I've been looking for the best Linux backup system, and also reading lots of HN comments.
 Instead of putting pros and cons of every backup system I'll just list some deal-breakers which would disqualify them.
 Also I would like that you, the HN community, would add more deal breakers for these or other backup systems if you know some more and at the same time, if you have data to disprove some of the deal-breakers listed here (benchmarks, info about something being true for older releases but is fixed on newer releases), please share it so that I can edit this list accordingly.

 Bacula (from the Why section on Burp):
 Too complex to configure
 Stores catalog separate from backups, need to backup catalog
 Doesn't deduplicate
 Relies on clock accuracy
 Can't resume an interrupted backup
 Retention policy

 Snebu:
 Doesn't do encryption

 Obnam:
 Really slow for large backups (from a benchmark between obnam and attic)
 To improve performance:
 lru-size=1024
 upload-queue-size=512
 as per: http://listmaster.pepperfish.net/pipermail/obnam-support-obnam.org/2014-June/003086.html

 Burp:
 Client side encryption turns off delta differencing

 Bup:
 Can't purge old backups
 Doesn't encrypt backups (well, there is encbup)

 Tarsnap:
 Slow restore performance on large backups? (Sorry Colin aka cperciva)
 This was a really strong candidate until I read some comments on HN about the slow performance to restore large backups.
 If this has changed in a recent version or someone has benchmarks to prove or disprove it, it would be really valuable.

 Duplicity:
 Slow restore performance on large backups?
 This was also a really strong candidate until I read some comments on HN about the slow performance to restore large backups.
 If this has changed in a recent version or someone has benchmarks to prove or disprove it, it would be really valuable.

 backup2l:
 No support for encryption

 Arq:
 Just included here because I knew someone would mention it in the comments.
 It's Mac OS X only. This list is for Linux server backup systems.

 Other contenders (of which I don't have references or information):
 HashBackup
 ZBackup
 ZPaq
 BTRFS send/receive 

 Also Tarsnap scores really high on encryption and deduplication but it has 3 important cons:
 - Not having control of the server where your backups are stored
 - Bandwith costs make your costs unpredictable
 - The so called Colin-Percival-gets-hit-by-a-bus scenario

 Attic has some really good comments on HN and good blog posts, doesn't have any particular deal-breaker (for now, if you have one please share with us), so for now is the most promising.
	I've been looking for the best Linux backup system, and also reading lots of HN comments.
	Instead of putting pros and cons of every backup system I'll just list some deal-breakers which would disqualify them.
	Also I would like that you, the HN community, would add more deal breakers for these or other backup systems if you know some more and at the same time, if you have data to disprove some of the deal-breakers listed here (benchmarks, info about something being true for older releases but is fixed on newer releases), please share it so that I can edit this list accordingly.

	Bacula (from the Why section on Burp):
	Too complex to configure
	Stores catalog separate from backups, need to backup catalog
	Doesn't deduplicate
	Relies on clock accuracy
	Can't resume an interrupted backup
	Retention policy

	Snebu:
	Doesn't do encryption

	Obnam:
	Really slow for large backups (from a benchmark between obnam and attic)
	To improve performance:
	lru-size=1024
	upload-queue-size=512
	as per: http://listmaster.pepperfish.net/pipermail/obnam-support-obnam.org/2014-June/003086.html

	Burp:
	Client side encryption turns off delta differencing

	Bup:
	Can't purge old backups
	Doesn't encrypt backups (well, there is encbup)

	Tarsnap:
	Slow restore performance on large backups? (Sorry Colin aka cperciva)
	This was a really strong candidate until I read some comments on HN about the slow performance to restore large backups.
	If this has changed in a recent version or someone has benchmarks to prove or disprove it, it would be really valuable.

	Duplicity:
	Slow restore performance on large backups?
	This was also a really strong candidate until I read some comments on HN about the slow performance to restore large backups.
	If this has changed in a recent version or someone has benchmarks to prove or disprove it, it would be really valuable.

	backup2l:
	No support for encryption

	Arq:
	Just included here because I knew someone would mention it in the comments.
	It's Mac OS X only. This list is for Linux server backup systems.

	Other contenders (of which I don't have references or information):
	HashBackup
	ZBackup
	ZPaq
	BTRFS send/receive

	Also Tarsnap scores really high on encryption and deduplication but it has 3 important cons:
	- Not having control of the server where your backups are stored
	- Bandwith costs make your costs unpredictable
	- The so called Colin-Percival-gets-hit-by-a-bus scenario

	Attic has some really good comments on HN and good blog posts, doesn't have any particular deal-breaker (for now, if you have one please share with us), so for now is the most promising.