Backup System Guide

Andy Wild December 2003

Operation of the backup system

The backup system for Zeus is implemented using Amanda. Amanda takes care of indexing the backups, remote restore operations, and automatic control of incremental dump levels. The advanced scheduling capabilities of Amanda are essentially disabled in the current configuration, as they are not appropriate for a small site like this.

Amanda server runs on Poseidon, and has access to a tape drive of 15Gb raw capacity, and an IDE holding disk. A full dump of all disks is performed every Sunday night, with incrementals taken though-out the rest of the week. The incrementals are held on the holding disk until Sunday night, when they are automatically committed to tape before the full dump begins. As a result each tape written has a full dump for that week, together with the previous weeks incrementals. To keep this system working smoothly ensure the tape is changed during the day on Sunday. You shouldn't give Amanda the next scheduled tape during the week because it will happily use it and perform full dumps during the week.

Common tasks

Virtually all administration of the system is done as the user 'backup' on Poseidon. Assume you should use this user unless otherwise specified.

Adding disks to be backed up

Edit the file /etc/amanda/DailySet1/disklist

If you add a new disk to the disklisk during the week no backups will be performed until Sunday night. This is because Amanda will not perform full dumps without having the expected tape available, and it cannot perform incremental dumps until a full dump has been done.

Removing disks to be backed up

backup@poseidon> amadmin DailySet1 delete [host] [disk]

then edit the file /etc/amanda/DailySet1/disklist and remove the entry for the disk you no longer care about.

Commissioning a new tape drive

First load a tape into the drive then:

backup@poseidon> mt -f /dev/nst0 status
backup@poseidon> amtapetype -c -e 20g -f /dev/nst0

Check that hardware compression is off then:

backup@poseidon> amtapetype -e 20g -f /dev/nst0

Commissioning a new tape

First load the tape into the drive then:

backup@poseidon> mt -f /dev/nosst0 erase
backup@poseidon> amlabel DailySet1 HISS??

Where ?? is the next available tape number.

Restoring selected files

It is possible to restore files from a remote machine using the tool amrecover. I will give only an example of using this tool - see the man page to more information. It is possible for a user on remote machine to abuse the system by impersonating root and requesting copies of the shadow password file (or any other file!) for any machine currently backed up. It prevent this I decided to disallow remote restores by default. To enable to use of amrecover when desired edit the /etc/amandahosts on poseidon and uncomment the relevant lines.

root@zeus> amrecover -s poseidon -t poseidon -d /dev/nosst0
amrecover> sethost zeus
200 Dump host set to zeus.
amrecover>setdisk /usr/home
Scanning /mnt/hda1/backup_data...
  20031209: found Amanda directory.
  20031210: found Amanda directory.
  20031211: found Amanda directory.
  20031212: found Amanda directory.
200 Disk set to /usr/home.
amrecover> cd acw43
amrecover> add public_html
Added dir /acw43/public_html at date 2003-12-12
Added dir /acw43/public_html at date 2003-12-08
Added dir /acw43/public_html at date 2003-12-11
amrecover> lcd /usr/home
amrecover> extract
amrecover> exit
200 Good bye.

If you want to restore an old copy of a file use the setdate command from within amrecover.

Restoring directly from tape

In situations were amrecover will not work you should use amrestore on poseidon. This allows you to extract the tar archives from the tape. For example to restore the /cvs directory from zeus:

backup@poseidon> amadmin DailySet1 find zeus cvs
Scanning /mnt/hda1/backup_data...
  20031209: found Amanda directory.
  20031210: found Amanda directory.
  20031211: found Amanda directory.
  20031212: found Amanda directory.

date       host disk lv tape or file                               file status
2003-11-18 zeus /cvs  1 HISS03                                        9 OK
2003-11-19 zeus /cvs  1 HISS03                                       26 OK
2003-11-20 zeus /cvs  1 HISS03                                       43 OK
2003-11-21 zeus /cvs  1 HISS03                                       60 OK
2003-11-22 zeus /cvs  1 HISS03                                       76 OK
2003-11-23 zeus /cvs  1 HISS03                                       89 OK
2003-11-24 zeus /cvs  0 HISS03                                      107 OK
2003-11-25 zeus /cvs  1 HISS04                                        5 OK
2003-11-26 zeus /cvs  1 HISS04                                       22 OK
2003-11-27 zeus /cvs  1 HISS04                                       38 OK
2003-11-28 zeus /cvs  1 HISS04                                       53 OK
2003-11-29 zeus /cvs  1 HISS04                                       69 OK
2003-11-30 zeus /cvs  1 HISS04                                       86 OK
2003-12-01 zeus /cvs  0 HISS04                                      107 OK
2003-12-02 zeus /cvs  1 HISS01                                        4 OK
2003-12-03 zeus /cvs  0 HISS01                                       27 OK
2003-12-04 zeus /cvs  1 HISS02                                        4 OK
2003-12-05 zeus /cvs  1 HISS02                                       21 OK
2003-12-06 zeus /cvs  1 HISS02                                       37 OK
2003-12-07 zeus /cvs  1 HISS02                                       52 OK
2003-12-08 zeus /cvs  0 HISS02                                       75 OK
2003-12-09 zeus /cvs  1 /mnt/hda1/backup_data/20031209/zeus._cvs.1    0 OK
2003-12-10 zeus /cvs  1 /mnt/hda1/backup_data/20031210/zeus._cvs.1    0 OK
2003-12-11 zeus /cvs  1 /mnt/hda1/backup_data/20031211/zeus._cvs.1    0 OK
2003-12-12 zeus /cvs  1 /mnt/hda1/backup_data/20031212/zeus._cvs.1    0 OK

Here you have a choice of tar files to restore. Lets go with the level 0 backup on tape HISS02, and the level 1 incremental still on the holding disk. This will give us the most recent backup. Load tape HISS02 now.

backup@poseidon> mt rewind
backup@poseidon> amrestore /dev/nosst0 zeus cvs 20031208
amrestore:   0: skipping start of tape: date 20031208 label HISS02
amrestore:   1: skipping zeus._usr_local.20031204.1
amrestore:   2: skipping zeus._var_yp.20031204.1
amrestore:   3: skipping athena._etc.20031204.1
amrestore:   4: skipping zeus._cvs.20031204.1
[... snip ...]
amrestore:  74: skipping zeus._root.20031208.0
amrestore:  75: restoring zeus._cvs.20031208.0
amrestore:  76: skipping zeus._sys.20031208.0
amrestore:  77: skipping poseidon._cvs.20031208.0
amrestore:  78: skipping zeus._home_ftp.20031208.0
amrestore:  79: skipping zeus._societies.20031208.0
amrestore:  80: skipping zeus._usr_home.20031208.0
amrestore:  81: reached end of tape: date 20031208
backup@poseidon> amrestore /mnt/hda1/backup_data/20031212/zeus._cvs.1
amrestore:   0: restoring zeus._cvs.20031212.1
backup@poseidon> ls -l zeus*
-rw-r-----    1 backup   backup   38881280 Dec 12 18:10 zeus._cvs.20031208.0
-rw-r-----    1 backup   backup     286720 Dec 12 18:10 zeus._cvs.20031212.1
backup@poseidon> file zeus._cvs.20031208.0
zeus._cvs.20031208.0: GNU tar archive
backup@poseidon> mkdir cvs; cd cvs
backup@poseidon> tar -xf ../zeus._cvs.20031208.0
backup@poseidon> tar -xf ../zeus._cvs.20031212.0

Configuring Poseidon

The tape drive is a OnStream DI-30 IDE device. To support this drive ensure you enable in the kernel (or as modules) these features:

Ensure the version of the osst module is 0.9.13 or greater. Earlier versions will allow the backups to proceed as normal but restoring files fails! The drive can then be accessed through the device nodes /dev/nosst0 (non rewinding) and /dev/osst0 (rewinding). For more info see [2].

Configuring Clients

The configuration of clients (machines that get backed up) is simple. First install the amanda-client package then edit /etc/amandahosts to grant poseidon access. It should look something like this:

 localhost backup backup

Future Expansion

There will surely come a time when too much data is being dumped weekly to fit on a single tape. There are a number of ways to deal with this situation. I would suggest changing the dumpcycle configuration parameter from 7 days to 14 days, but continue to feed Amanda a tape every week. Amanda should attempt to load balance backups, performing full backups of the largest file systems on alternate Sundays. This is just one possible solution. Onstream, the manufacturers of the tape drive, went bankrupt in April 2003, which may make finding replacement or additional tapes difficult.


  1. Amanda homepage
  2. osst driver for DI-30 tape drive

Valid HTML 4.01! Valid CSS!