Encrypted "Capsule" Backups Using Amanda
There are two schools of thought in backup - encrypt at source and encrypt media. Both have their upsides and downsides
- Encrypt at source
- Pros: The backup is unusable to anyone not in possession of the right keys anywhere en-route or in storage.
- Cons: Integration of cryptography in backup software is not bug-free and you may suddenly lose access to old backups due to format incompatibilities. You also need to solve the problems of keeping keys, pass-phrases, etc for each encrypted domain in the system.
- Encrypt media
- Pros: It just works and can be totally independent of the backup system
- Cons: The backup is vulnerable when the media is mounted (and keys active) as well as vulnerable en-route. If you do not trust your links an encrypted VPN is a must.
Frankly, for the needs of a small home office (actually a couple of them) as well as a very heavily computerized household the "encrypt media" is enough. I would never use it in an enterprise setting, but at home, where I am ROOT, well I can get away with that level of security.
Setting up amanda
If you intend to use a different backup system, skip to the next section.
Setting up amanda is somewhat of a dark art. While not as much of a witches brew as let's say split DNS or routing protocols on a Linux platform it tends to scare people off and make them go for "easier" backup solutions.
- You are not in control of what happens when. You just relinquished it. If you have devised a nice schedule which says "full backup each Saturday", "incremental on Mondays", etc - you can forget that idea.
- You are not in control of your backup size for this run. You just relinquished it. Same as with the schedule - it may be small, it may be big, you know its maximum size, but you do not know exactly how big it will be today.
The reason for these is that amanda will compute a combination of levels it considers optimal for each run. You can control how this happens (somewhat) by changing priorities and forcing full backups for particular volumes, but you will never be in full control. In fact it is better that you are not, because if you leave amanda to do its knitting it will try to fit more than one full backup for every volume within a backup cycle. This way if you have a media failure, not all is lost - you can use the other full run in the same cycle and restore whatever you have in terms of surviving incrementals on top of it. It will also constantly adjust when full and incrementals are happening based on their size and the amount of changed data between runs.
Setting up Amanda
Install both amanda server and client packages on the server you intend to use to backup your network.
apt-get install amanda-client amanda-server
You now need to define your backup run. This is the painful part. Once done you are likely to keep it (and only change it and tweak it) for years. Mine has survived with minimal modifications 4 changes in backup technologies and 15 years of use. It has saved me after the Cirrus Logic Maxtor IDE controller fubar (that deep-sixed my main house RAID array) as well as after numerous fubars mostly of the "fat fingers" variety.
Thankfully, the Debian guys have done quite a lot of the work over the years. We can grab one of the files they have supplied for us and modify it to get the results we need. We will try to use their "include" and "template" methodology as much as possible so that we do not modify the files shipped by the various packages unless needed.
A fresh "pristine" install on Debian jessie has nothing under /etc/amanda - most of the stuff we are interested in is /usr/share/amanda/common/
First of all we need to create a new run definition. Amanda run definitions are directories under /etc/amanda
chown backup:backup /etc/amanda/DailyBackup01
The file which is the closest to our needs is the amanda-changer.conf. We will grab it, copy it to /etc/amanda/DailyBackup01/ as amanda.conf and start adding stuff to it.
- 04 Mar 2017