I've got a couple of VPS boxes over at RansomIT including the server that run this site1. One of those boxes is a cheap little VPS with 512MB of RAM that costs me $5 a month. I need to back up this box, my usual go to for personal servers is Crashplan but Crashplan needs 1GB of RAM.
So I thought, why not sync2 the contents of the small server over to more powerful server (with 8GB of RAM) that can run Crashplan.
Create a backup user on the source server
I'm going to create a 'backups' account on the source server, add an SSH key and add the backups account into the sudoers group3.
sudo useradd --system --shell /bin/bash --home-dir /home/backups --create-home backups
sudo su backups
cd
ssh-keygen
# Accept the defaults
mv id_rsa.pub authorized_keys
less ~/.ssh/id_rsa
# Copy the private key and press Q to quit
exit
sudo visudo
Add to the sudoers file
# Allow backups to run rsync as root without a password
backups ALL=NOPASSWD:/usr/bin/rsync
Create our backups script on the destinaton server
Copy the ssh private key (id_rsa) to the destination server.
mkdir backups
cd backups
vim backups.id_rsa
sudo chown root:root backups.id_rsa
sudo chmod 400 backups.id_rsa
# SSH into the source server, this is both so we get the servers host key
# added and also a a bit of a 'hello world' sanity check.
sudo ssh -i backups.id_rsa backups@source.example.com
exit
vim nightly-backups.sh
I've based my backups script on the one in the Arch Wiki
#!/bin/bash
# -a Archive mode (keep file permissions etc...)
# -A preserve ACLs
# -X keep extended attributeds
# Backup www.example.com
rsync -aAX \
-e "ssh -i /home/michael/backups/backups.id_rsa" \
--rsync-path="sudo rsync" \
--exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} \
--delete \
backups@www.example.com:/ \
/home/michael/backups/www.example.com/
And link the script to crontab
# The script needs to be owned by root or it won't execute.
sudo chown root:root nightly-backups.sh
sudo chmod 774 nightly-backups.sh
sudo vim /etc/crontab
# rsync servers back here 01:15 every day.
15 1 * * * root /home/michael/backups/nightly-backups.sh
The reason I've got the backup job also running as root on the destination server is we are keeping the file permissions and some files will be owned by root (from the source server) so we need to be root on the destination server to overwrite them when they change.
It's not the best backup solution but it's simple and effective.
-
I'm an extremely satisfied customer and I'd be happy to recommend them. If you are looking for reasonably priced and reliable servers in Oceania with excellent customer service RansomIT are great. ↩
-
I wouldn't recommend just syncing a server as a backup solution, if you get hit by cryptolocker and you sync your files then your backups are encrypted too. But in this case the synced copy is getting backed up by Crashplan which handles all of the file revisions and retention time frames. ↩
-
On the Unix and Linux stackexchange Martin von Wittich makes a good point that this could be run as root. He is correct, my choice to use a seperate account is not that it directly increases security but I feel it's neater and it doesn't lead to sprawl.
For example say another job also needs to ssh in as root, if there is already an SSH key it would so easy to use the same key pair rather than generate a new one and append it to the authorized_keys. But then if you want to disable the backups you need to work out what other services are using that key pair.
I've seen Windows environments where twenty or thirty different services were running as the domain administrator account, many of these service did need administrative access, things like backups, inventory systems and anti-virus. But it meant that the domain admin password couldn't be changed (for example when staff left) without breaking things. It took a lot of work to find all of the things that were using the account and migrate them to their own accounts so we could change (and disable) the domain admin account. ↩
