We provide a remote backup space with each legacy VM and dedicated host, but for BigV servers, we suggest adding an “archive” grade disc per server. This presents as a normal disc on which you store backups.
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 BigV servers, 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 accommodate 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
You can also do this from the BigV web panel if you’re not a fan of the command line. Just pick 1GiB RAM and ensure you add archive storage separately to your included SATA allowance of 25GiB.
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 now need to install the services that will allow the server to host the backup spaces. Login to your server as root, and then:
# apt-get install rsync nfs-common nfs-kernel-server samba
Now edit the rsync configuration file (/etc/default/rsync) and ensure that
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:
# mkdir -p /store/backups
…and make it mount on boot by adding the following line to your /etc/fstab:
/dev/mapper/archivedisks-backups /store/backups ext4 errors=remount-ro,rw,nodev,nosuid,noexec 0 1
# mount /store/backups
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:
126.96.36.199, 188.8.131.52, 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.
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:
That’s it! The only thing left to mention is that disc space quotas are not implemented, so you’ll have to keep an eye on disc utilisation. Let me know if you find this useful!