In Fire We Trust

Disclaimer: The techniques described in this document can help you, but they are not boud too. There could be errors, omissions or pure mistakes. Before using the information otlined here please check it. I accept no responsibility for whatsoever real or fictional damage/loss of profit/fallen houses/martians due to use or misuse of the information found here.

History

• 08.11.2007 - Initial version

Motivation
On the topic of backup and archiving there a few points of view which are both correct in some degree and light. Most often the following ones are mentioned:

• Backup often and regularly
• Backup when needed and have good plan for recovery
• Real men don’t do backups! They let the internet mirror it!

Well i am from the first type of people. I insist my data to be archived, backed up and secure. And for the purpose i had to have a backup strategy. Today i will tell you how this site is backed up. What is used and how it is interconnected.
It has to be noted that the system is not the best but it works fairly good and is ideal for my personal needs.

Purpose
We are targeted in creating a fully automated system that will do regular backups for us. Additional targets are speed, versatility, minimal volume of transfered data, easy recovery from backups, security.

What is used
Nothing strange or esoteric. Debian based systems (both the host and the archiving machine), rsnapshot, ssh, rsync, diff, cp, du, perl.
The base of the system revolves around rsync, rsnapshot is just a wraper around it. Everything can be achieved with rsync. Additionally we will need cron and some knowledge about the ways of security and workings of SSH.
The most attention should be spent on securing the system therefore configuring ssh.

Setting up rsnapshot
This is the easiest part of our work. I’ve chosen rsnapshot due to the fact that information is transmitted with rsync meaning that only differences get transferred, it uses a rotating scheme for the archives, and probably the most important - uses hardlinks to unchanged files to save space.
After the installation of rsnapshot you have to define periods/targets, archival points and some commands.

/etc/rsnapshot.conf

# where the backups will be stored
snapshot_root   /home/webbackup/
# few commands we will need
cmd_cp          /bin/cp
cmd_rm          /bin/rm
cmd_rsync       /usr/bin/rsync
# alas here we can't add additional options to the command line
cmd_ssh         /usr/bin/ssh
cmd_logger      /usr/bin/logger
cmd_du          /usr/bin/du
cmd_rsnapshot_diff      /usr/bin/rsnapshot-diff
# defining a target and cound of stored copies
interval        whgeto  10
# logs and so
verbose         2
loglevel        3
logfile         /var/log/rsnapshot.log
lockfile        /var/run/rsnapshot.pid
# some of the data is useless for sync
exclude log/*
exclude phptmp/*
# and finaly the points we will archive
backup  root@getoto.net:/var/www/       getoto.net/web/
backup  root@getoto.net:/var/lib/mysql/ getoto.net/sql/

After defining what will be archived and how many copies will be used it is time to automate the task. This is achieved by adding a record in the cron system.

0 */6   * * *   webbackup    /usr/bin/rsnapshot whgeto

This translates to … every 6 hours execute as user webbackup the command …

This completes the configuration of rsnapshot. Now we have to secure the access to the machine and limit it to certain commands.

Setting up SSH
After the system is setup for regular archiving we need to grant it access to the target machine and limit it accordingly. We want to achieve the following. Access without a password (key only), possible from single address, which can execute strictly defined commands.

All this can be achieved the following way:

• Generate a key to be used for the operation - the key itself is passwordles. We chose a smaller key so access will be faster, and of course we will additionally secure it.
  

  ssh-keygen -t rsa -b 1024 -f ~/keys/backup && chmod 600 ~/keys/backup

  
  This way in the folder ~/keys we will generate RSA key with length 1024 bytes and change the rights so only the owner can read/modify it. The last step is the most important because if the rights are incorrect the key won’t be used.
• Add the public part of the key to the list of authorized keys on the target host. It is enough the public part of the key to be added to the /root/.ssh/authorized_keys file
• We enter the target machine (the one which will be archived) once using the key. The purpose is to add the signature of the target machine to our known hosts or otherwise the backup procedure will fail.
• We edit the file ~/.ssh/config - this is a file in which various aspects of the operation of the ssh client can be controled on the base of which host we are connecting to. Mine has the following content:
  

  # which host we are talking for
  Host getoto.net
  # we will use IPv4 (v6 is not supported here)
  AddressFamily inet
  # we will use batch mode (noninteractive)
  BatchMode yes
  # we will use this key for authorization
  IdentityFile /home/webbackup/keys/backup
  # and require only version 2
  Protocol 2

  This way we force ssh to use our key (specifically generated) when connecting to the host which will be backed up.
  With this we end the configuration of the archiving host.

• We edit the file /root/.ssh/authorized_keys - here we will limit the rights of the connecting host. In this file we will limit the access only form a certain place and allow it to execute only certain commands.
  /root/.ssh/authorized_keys
  

  command="/root/.ssh/authprogs.pl",from="11.22.33.44" ssh-rsa AAAAB3NzaC1 ...

  
  This way we limit the access with this key only from ip 11.22.33.44 and the only command that can be executed (wanting or not) is /root/.ssh/authprogs.pl

  The program authprogs.pl is a script taken from http://www.hackinglinuxexposed.com/. It’s purpose is to allow us to execute multiple commands on the host. Reason for it is that ssh allow only one command in this format.
  The script itself needs a simple config defining conecting hosts and allowed commands
  

  # host
  [11.22.33.44]
  # commands that can be executed
          # Backups
          rsync --server --sender -logDtprR --numeric-ids . /var/www
          rsync --server --sender -logDtprR --numeric-ids . /var/lib/mysql

  
  This way we effectively jumped over the limits of ssh
• Testing - run rsnapshot manually with the target defined. It will hang a bit and after that you will have your firs archive in the series.
  

  garota:~# ls -l /home/webbackup/
  drwxr-xr-x 3 1005 1005 4096 2007-11-08 12:00 whgeto.0
  drwxr-xr-x 3 1005 1005 4096 2007-11-08 11:39 whgeto.1
  drwxr-xr-x 3 1005 1005 4096 2007-11-08 11:07 whgeto.2
  garota:~# ls -l /home/webbackup/whgeto.1
  drwxr-xr-x 4 1005 1005 4096 2007-11-08 11:36 getoto.net
  garota:~# ls -l /home/webbackup/whgeto.1/getoto.net/
  drwxr-xr-x 3 1005 1005 4096 2007-11-08 11:36 sql
  drwxr-xr-x 3 1005 1005 4096 2007-11-08 11:10 web

Conclusion
Well i hope this helped you at least a bit. You now should have automated and secure backup system. For me at least it is doing a fine job.

Useful links

• authprogs.pl
• http://www.snailbook.com/faq/restricted-scp.auto.html
• http://www.hackinglinuxexposed.com/articles/20030115.html
• http://pkeck.myweb.uga.edu/ssh/
• http://sial.org/howto/openssh/