A Bytemark Style Backup Server [Permalink]
20-06-2014 12:24 UTC
Bytemark provide a remote backup space with each old-style VM and dedicated host, but no such offering is made for BigV machines. Instead, the procedure is to add an "archive" grade disk at £2/month/50GiB, which acts like a normal disk.
In Symbiosis, my normal approach here was to mount the disk at /var/backups and disable the remote part of the backup procedure.
By the time I had several machines, each using this technique or similar, I began to wonder if there was a better way. Each of the 50GiB archive disks was only a few percent utilised, and I wondered about consolidating them into one centralised "Backup Machine".
I wanted this machine to look and act as much like a Bytemark backup server as possible, to minimise transition pain. This is how I achieved just that.
I fired up the BigV console, set up a new machine and imaged it with Debian Wheezy. I gave it a reasonable amount (100GiB) of archive grade storage to accomodate all of my machines. The machine specified here would cost £14/month.
$ bigv vm new --vm-name backup --vm-cores 1 --vm-memory 1 --vm-discs sata:25,archive:100 --vm-distribution wheezy
The imager will set up two partitions on /dev/vda (the sata storage) for root and boot. It will leave /dev/vdb untouched, so we will configure this ourselves.
We need to install the servers that will allow the server to serve the backup spaces:
# apt-get install rsync nfs-common nfs-kernel-server samba
To allow rsyncd to run you need to set
Next we configure the archive disk. For flexibility, I used LVM on the disk. This makes things simple if we want to expand or shrink the partitions, add more disks to the space, or change the size of the disk. Here I just chose to use the entire disk for one partition, and create an ext4 filesystem on it. I chose ext4 due to its robustness, reliability and maturity, but the lvm setup could be used to allow you to easily and quickly test which filesystem works best for you.
# pvcreate /dev/vdb
# vgcreate archivedisks /dev/vdb
# lvcreate -l 100%VG -n backups archivedisks
# mkfs.ext4 /dev/mapper/archivedisks-backups
Now we need to create the mount point for it and make it mount on boot:
# mkdir -p /store/backups
# mount /store/backups
Add the following line to your /etc/fstab:
/dev/mapper/archivedisks-backups /store/backups ext4 errors=remount-ro,rw,nodev,nosuid,noexec 0 1
And that's all of the prep done. The next thing you need is to get these Backup space scripts
and untar them.
There are two scripts, both need to be run as root. `makespace` takes a unix username as its single argument (the backup space name), and creates the files. `updatespaces` updates the configurations and makes them live.
The backup spaces can be found at /store/backups/backupspacename. Just like with Bytemark's backup spaces, they can be accessed using rsync, nfs or samba. rsync and samba live in their .rsync_root/ and .samba_root/ directories, relative to nfs.
/store/backups/backupspacename/.hosts.allow is a file containing the ACL for the backup space. the space is not password protected, but can only be accessed by a set of IPs, comma separated, on a single line in .hosts.allow. For example:
188.8.131.52, 184.108.40.206, 2000::1:2:3:4
When the file is changed, updatespaces must be run. This file should be owned by root and have the permissions 644. This means it is readable when the space is NFS mounted, but not writable. This is a feature I have added and is not present on Bytemark's spaces. I have done this because the ACLs for Bytemark's spaces are stored in a separate system, and so I have hacked this in here.
Once you have completed the steps above, you should be able to access the spaces using rsync, nfs or samba, as per Bytemark's Technical Documents.
In Symbiosis, the last step to add the server as the backup space is to add the file /etc/symbiosis/dns.d/backup.name with the following contents: