Lars Wirzenius stunned everyone on the 13 August 2017 with his decison to retire obnam, his very popular and useful backup program as of the end of this year! His decision threw a lot of obnam users into a state of disarray and anxiety about what they could use for backup for the foreseable future - myself included. But at least Lars told us with plenty of time to make decisons and change our backup strategy. So thank you Lars for all of your work on obnam, and thanks for giving us plenty of time to look at other solutions.
So I've been looking at borgbackup, restic, and zbackup.
The first thing that I looked at was the latest commit date to see if they are actively maintained and still alive.
- borgbackup - August 16, 2017,
- restic - August 13, 2017,
- zbackup - February 6, 2016. So that's 18 months ago, its beginning to sound decidedly iffy to me!
The second thing that I looked at was its availability and version number on my distro, Debian 9. For this I used 'rmadison' as 'rmadison foo'
borgbackup | 1.0.9-1~bpo8+1 | jessie-backports | source, amd64, arm64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, ppc64el, s390x
borgbackup | 1.0.9-1 | stable | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
borgbackup | 1.0.10-3 | unstable | source, hurd-i386
Next up is restic
restic | 0.3.3-1 | stable | source
restic | 0.3.3-1+b2 | stable | amd64, arm64, armel, armhf, i386, ppc64el
restic | 0.7.1-1 | testing | source, amd64, arm64, armel, armhf, i386, ppc64el
and finally zbackup
zbackup | 1.4.4-1~bpo8+1 | jessie-backports | source, amd64, arm64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, ppc64el, s390x
zbackup | 1.4.4-1 | unstable | source, kfreebsd-amd64, kfreebsd-i386
zbackup | 1.4.4-1 | unstable-debug | source
zbackup | 1.4.4-2 | stable | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
zbackup | 1.4.4-2 | testing | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
What this is showing us is the speed of development, and the ease at which its Debian maintainers can build it to work within the Debian infrastructure. So with all that I now know about 'zbackup' I'm excluding it from any future usage or testing.
So next up is 'borgbackup'. This backs up, uses deduplication, and compression - meaning that the database of backed up files is squashed to fit more in the space available (very simplisticlly). But what it doesn't do is backups every n hours, meaning that it can only do one-a-day backups, which I find unacceptable. So just for future reference, this is my borg backup script called "borgup" -
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | #!/bin/bash
# 2017-08-14
REPOSITORY=/mnt/backc/borgback
# Setting this, so you won't be asked for your repository passphrase:
export BORG_PASSPHRASE='abc123'
# or this to ask an external program to supply the passphrase:
# export BORG_PASSCOMMAND='pass show backup'
# Backup all of /home and /var/www except a few
# excluded directories
/usr/local/bin/borg create -v --stats --compression lz4 \
$REPOSITORY::'{hostname}-{now:%Y-%m-%d}' \
/home/boudiccas \
/var/www \
--exclude '/home/*/.cache' \
# --exclude /home/Ben/Music/Justin\ Bieber \
# --exclude '*.pyc'
# Use the `prune` subcommand to maintain 7 daily, 4 weekly and 6 monthly
# archives of THIS machine. The '{hostname}-' prefix is very important to
# limit prune's operation to this machine's archives and not apply to
# other machine's archives also.
/usr/local/bin/borg prune -v --list $REPOSITORY --prefix '{hostname}-' \
--keep-daily=7 --keep-weekly=4 --keep-monthly=12 --keep-yearly=2
|
If you really do want to do n backups then this might help borg-cron-helper with its latest commit being on August 13, 2017. Using that program I was able to get n backups, but doing so broke the compression. So all in all I'm left feeling rather frustrated by borgbackup.
Next up to the plate is restic which allows backup, deduplication but no compression. So here is my configuration script for restic, called "resticup" -
1 2 3 4 5 6 7 8 9 10 11 | #!/bin/bash
# 2017-08-16
RESTIC_REPOSITORY=/mnt/backc/restic-back
/usr/local/bin/restic -r $RESTIC_REPOSITORY -p ~/bin/restinpeace.txt backup /home/boudiccas --exclude '/home/*/.cache'
/usr/local/bin/restic -r $RESTIC_REPOSITORY -p ~/bin/restinpeace.txt forget --keep-hourly 4 --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --keep-yearly 10
/usr/local/bin/restic -r $RESTIC_REPOSITORY -p ~/bin/restinpeace.txt snapshots
|
(You'll have to forgive my rather warped sense of humour at times, my restic password file isn't called 'restinpeace.txt' but it just felt right whilst I was obscuring the real name!)
What this configuration script does - it backs up my home directory to my backc drive in the directory called 'restic-back' and in the process calling the password from its relevant file and also excludes my .cache files, which in the main aren't very useful.
Its next active line is telling restic to drop from its memory all hourly backups except for the last one when they total 4. Hour 4 then becomes day 1, day 2, etc, and then after 8 daily backups, 7 are forgotten, and one becomes week 1. Etc, and so on, ad inifintitum.
The last active line is telling restic to output details of its 'snapshots' as every backup is called a snapshot of its source files.
My script is called from cron using this stanza -
30 06,12,18 * * * /home/boudiccas/bin/resticup>>/home/boudiccas/logs/restic.txt 2>&1
So after 2 days of backups this is what is showing for each backup system -
borg-backup 130.52gb restic-backup 150.50gb
They are both backing up \home which is currently at 218.93gb, so either I have a lot of cache files, which is perfectly possible as borgbackup does generate quite a few as part of its backup, or else something else is happening. Now it is very likely that I have misunderstood something about either of these two backup solutions, or just got it plain wrong. so if I am in error please let me know.
Thinsg that I haven't done - testing the mounting of the backup to help in extracting single files, or testing the restoreability (horrible made-up word) of either of the two programs.
Things that I do like - the borgbackup documentation is very good (worth 9 out of 10 on any scoreboard). Its clean, very easy to read and understand, and it gives a sample config script to help get you started. Whereas the restic documentation isn't quite as concise but does show you how to set it up to backup from Amazon S3, but falls down on not having a sample config script to help get you started using restic.
Based on all of this, I'm going to be using 'restic' for my backups from now on (although that may change in the future).
Comments
comments powered by Disqus