[an error occurred while processing this directive]
Andy Wild December 2003
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.
Virtually all administration of the system is done as the user 'backup' on Poseidon. Assume you should use this user unless otherwise specified.
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.
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.
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
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.
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 /usr/home/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 [...yawn...] amrecover> exit 200 Good bye. root@zeus>
If you want to restore an old copy of a file use the setdate command from within amrecover.
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
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 .
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 poseidon.jcn.srcf.net backup
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.
[an error occurred while processing this directive][an error occurred while processing this directive]