TODO: Add information on README files to be included with backups.
Back to Backup Strategy.
See also sample backup scripts, Recovering a service from backup, Backing up a host.
For instructions on setting up the backup server itself, see Building the Backup Server.
How to backup a service to the backup server
The following steps are performed by the backup administrator. They need to be done for each specific service that is to use the backup server.
We create an example account for the mailing list service backup.
- On the backup server create the service specific (e.g. list server, Wiki, SkillsBase) backup account. Prefix the service account name with "bu-" to denote this as an account dedicated to backing up the service (rather than providing the service).
vole:~# adduser --ingroup backup bu-list
Adding user bu-list...
Adding new user bu-list (1002) with group backup.
Creating home directory /home/bu-list.
Copying files from /etc/skel
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for bu-list
Enter the new value, or press return for the default
Full Name : Mail lists backup
Room Number :
Work Phone :
Home Phone :
Is the information correct? [y/n] y
This is where the backup files will go in the name of the bu- user. So the xxx service administrator will rsync tar files here using the bu-xxx account.
- Prepare a backup directory.
vole:~# mkdir /var/openskills-backup/bu-list
vole:~# chown bu-list:backup /var/openskills-backup/bu-list
vole:~# chmod 2755 /var/openskills-backup/bu-list
We use chmod 2755 to set the permissions such that only bu-list (in this case) can write to the backup directory, but anyone can list and read. The leading 2 means that files written to the directory are set to the group of the directory, in this case "backup".
We can make the backup files visible in this way because any sensitive data is encrypted, and the more copies we have of backup data the better.
- Create a new .ssh directory and make this read-only for the new user.
vole:~# su - bu-list
bu-list@vole:~$ chmod 750 .
bu-list@vole:~$ mkdir .ssh
bu-list@vole:~$ chmod 700 .ssh/
Configure the service server to backup to the backup server
This must be done by the individual service administrator on the OpenSkills server running the subject service. Needless to say, this server should not be backup.openskills.org.
- Ensure that there is a /var/openskills-backup/ directory. If not:
# mkdir /var/openskills-backup
# chown root:backup /var/openskills-backup/
# chmod 2750 /var/openskills-backup/
- Create a directory for the service to be backed up:
# mkdir /var/openskills-backup/bu-lists
# chown root:backup /var/openskills-backup/bu-lists/
# chmod 775 /var/openskills-backup/bu-lists/
- Create a backup script (see sample backup scripts). This script will gather together all the key files used to provide a given service. It must be possible to recreate the entire service on a completely new machine given only these files.
- Change the group of the file to backup
- Make the script file visible to the owner and the group
# vim /usr/local/bin/daily-backup-lists
# chgrp backup /usr/local/bin/daily-backup-lists
# chmod 770 /usr/local/bin/daily-backup-lists
- Allow a user to run (and edit) the backup script (e.g. patrick). To do this, add the designated backup user to the group backup:
# addgroup patrick backup
Note that if another service uses the same account, the key will need to be added to the authorized_keys2 file rather than overwriting it.
- We use either scp or rsync to transfer the backup information to the backup server, and both these use SSH as the underlying transport. (Note that rsync may require setting "-e ssh" in order to use SSH). By default, SSH demands authentication in the form of the password for the remote (backup server) account. Obviously, having to supply a password everytime means that the automatic batch job will not work very well(!) - so, we create an SSH key in the .ssh/ directory of the account that will be running the backup script. This key *may* have a passphrase, and if it does this passphrase must be specified when the script is run, or put in a file nominated within the script or assigned to an environment variable. For now, specify no password (we may need to review this policy). Once the key is created, it must be copied to the .ssh/ directory of the home directory of the backup account on the backup server. So, as the account that will be running the backup script:
$ ssh-keygen -t dsa
$ scp .ssh/id_dsa.pub firstname.lastname@example.org:.ssh/authorized_keys2
- Test the script Make sure usa a shell that you logged after you added your account to the backup group in order to pick up the new permission.
The "31 12 * * *" means run the script at 31 minutes past the 12th hour on every month-day in every month on every day-of-the-week. All OpenSkills servers should have their clocks set to UTC (~GMT). Choose an hour between 1 and 13 so we can say that from 14:00 GMT onwards, it's OK to rsync the backup from the backup server.
- Setup crontab to run the script.
- Use crontab -e to configure crontab to run the backup script
$ crontab -e
- The entry should look something like this:
# list backup
31 12 * * * /usr/local/bin/daily-backup-lists
Back to Backup Strategy
See also Building the Backup Server