This document describes how one person set up Amanda (v. 2.4.4p1) to run on a Dell PowerEdge 2650 server starting from a stock Redhat 9 install. The server has a Qualstar TLS-5433 SAIT changer attached via an Adaptec 39160 SCSI controller. This document assumes that you have everything physically hooked up correctly. This document is not intended to be a guide to getting Amanda to work with your tape changer. It's intended to show the steps I took to get it working with -my- configuration. The hope is that by reading this, you will avoid some of the same mistakes that I made. A side benefit might be that the real experts who write the Amanda documentation can get an outsider's view of which parts were clear, and which were confusing. Table of Contents ----------------- 0. Preparation 1. Pre-compilation setup 2. Install Prerequisites 3. Compilation 4. amanda.conf 5. chg-scsi.conf 6. Setting up clients 7. disklist 8. Testing your setup 9. Finding out what Amanda did 10. Setting up your crontab 11. Where do you go from here? 12. Troubleshooting ################## # 0. Preparation # ################## Read the following documentation (from untarred amanda src tarball unless otherwise specified): - docs/INSTALL - docs/FAQ - docs/TAPE.CHANGERS - The Amanda chapter of O'Reilly's Unix Backup and Recovery Please do this. I didn't, and learned the hard way. This is one case where you really should read the docs through before starting. It's especially important to read everything BEFORE you start, because much of the documentation is for people with single tape drives, and you'll end up doing work that has to be re-done for a changer setup unless you know beforehand how the changer setup differs from the basic setup. ############################ # 1. Pre-compilation setup # ############################ 1a - set up the user Create a user named 'amanda'. Make this user a member of the 'disk' group (first time around I thought it would be smart to make an 'amanda' group as well - bad idea, wasn't able to give the user permission to use the /dev files for the changer and tape drive when amanda was in the amanda group unless I made it world-writable, not what I wanted. disk group allows current permissions on /dev devices to be sufficient. This is especially important because even though in Linux you can be a member of multiple groups, it's the primary group that really drives the permissions/access) 1b - Find your devices Amanda wants the non-rewinding version of the tape drive. So, my devices are: /dev/nst0 - non-rewinding tape drive /dev/sg1 - The medium changer device As to how to find these...I confess, I simply used the 'mt' (magnetic tape) program standard on Unix systems, and did: bash-2.05b$ mt -f /dev/nst0 status SCSI 2 tape drive: File number=3, block number=0, partition=0. Tape block size 512 bytes. Density code 0x40 (DLT1 40 GB, or Ultrium). Soft error count since last status=0 General status bits on (81010000): EOF ONLINE IM_REP_EN bash-2.05b$ You'll know when it's wrong, because it will look like this: bash-2.05b$ mt -f /dev/nst1 status /dev/nst1: No such device or address bash-2.05b$ Once you locate the tape drive you need to locate the changer. There is a program called 'mtx' to control changers, but it has to be downloaded and installed from http://mtx.sourceforge.net/. Then, you can issue a very similar command: # mtx -f /dev/sg0 status The trick is that it seems to give good-looking data from devices that aren't changers (a very convincing report came back from sg0, so I thought that it was the changer for a bit, I think it was actually a disk drive hanging off of the internal RAID controller instead!) The good output is obvious once you see it: bash-2.05b$ mtx -f /dev/sg1 status Storage Changer /dev/sg1:1 Drives, 34 Slots ( 1 Import/Export ) Data Transfer Element 0:Full (Storage Element 3 Loaded):VolumeTag = A0000002 Storage Element 1:Full :VolumeTag=A0000000 Storage Element 2:Full :VolumeTag=A0000001 Storage Element 3:Empty Storage Element 4:Full :VolumeTag=A0000003 Storage Element 5:Full :VolumeTag=A0000004 Storage Element 6:Full :VolumeTag=A0000005 Storage Element 7:Full :VolumeTag=A0000006 Storage Element 8:Full :VolumeTag=A0000007 Storage Element 9:Full :VolumeTag=A0000008 Storage Element 10:Full :VolumeTag=A0000009 Storage Element 11:Empty Storage Element 12:Empty Storage Element 13:Empty etc.... I'm sure there's a much more scientific process, but I don't profess to be familiar with how linux assigns SCSI devices to /dev entries, and this got me moving on, so I was content with this method. 1c - Set up the ports and services Amanda requires that you configure some ports and services. On Redhat 9 this happens in two places - /etc/services, and the /etc/xinetd.d/ directory. /etc/services needs the following entries: amanda 10080/udp amandaidx 10082/tcp amidxtape 10083/tcp You'll find that Redhat 9 already has these in their file, as well as some other Amanda-related entries, but check to be sure. The xinetd setup was difficult because all the docs cover the older, inetd system, and it was hard to find the proper xintd.d entries. However, a significant amount of Googling helped me fill in the blanks. Here are the entries that you need (edit as root - one of the few times you should edit/create files as root as opposed to the amanda user in this document): # /etc/xinetd.d/amanda service amanda { socket_type = dgram protocol = udp wait = yes user = amanda group = disk server = /usr/local/libexec/amandad } # /etc/xinetd.d/amidxtape service amidxtape { socket_type = stream protocol = tcp wait = no user = amanda group = disk server = /usr/local/libexec/amidxtaped } # /etc/xinetd.d/amandaidx service amandaidx { socket_type = stream protocol = tcp wait = no user = amanda group = amanda server = /usr/local/libexec/amindexd } Add these files, very straightforward (once you know what their contents should be!) Note some of these values might be different if you chose different compile-time options for the user and the prefix. Force xinetd to re-read its config. 'kill -HUP pid-of-xinetd' ought to do it. ############################ # 2. Install prerequisites # ############################ Amanda is nice in that it doesn't have much in the way of prereqs, at least on a RH 9 system. Ensure that you have a good tar program (the GNU tar with RH 9 is good, Amanda definitely wants a current gnutar as the tar program). Only thing I needed to install was gnuplot, and it's optional. Apparently, amplot uses gnuplot to create graphical representations of how your Amanda software is doing - I confess to not having tried it yet, but I did install it. ################################ # 3. Obtain and compile Amanda # ################################ I grabbed the tarball from amanda.org and untarred it. I configured the software with the following command as the amanda user: ./configure --with-user=amanda --with-group=disk --with-config=CIS The first two params are required. The third is basically what you want to call your default configuration - by that, your default series of backups. I only plan on having one regular series of backups running, so I simply named it CIS after our department (Computer and Information Sciences). The default is DailySet1, which I did not like, so I did this instead. Amanda's configuration is actually per-config...to make that a little clearer, if I had two series of backups, there'd be two amanda.conf files, in two separate subdirs of your amanda install. So, this name will also be the name of a directory where your config lives, so keep that in mind when you choose the name. Wherever you see CIS in this document, you should replace it with the name of your own config. One flag missing here is the prefix - I liked the default of /usr/local. Amanda will go into various directories under the prefix, including sbin, libexec, lib, etc/amanda, var/amanda/gnutar-lists, and man. And actually, not all of these are created automatically - we'll create some of them later. At any rate, if you want a different prefix, change this. Of course, there are other flags and options - ./configure --help is your friend - but this is a document about -my- install. :-) At this point, it compiled fine, then it was a matter of running 'make'. Once that was done, I did an 'su' to root, and ran make install. Everything up to this point is very straightforward; it gets more complicated from here. ################## # 4. amanda.conf # ################## First, create the config directory. Switching back to the amanda user, I created the /usr/local/etc/amanda/CIS directory. I copied /usr/local/src/amanda-2.4.4p1/examples/* to this directory (clean it up later - there's a lot here you won't end up needing). The comments are pretty good in amanda.conf which is helpful. Editing the file, here are the parameters that I set/changed: (if it's not mentioned here, I kept the default) org "CIS" mailto "fran@cis.uab.edu" dumpuser "amanda" netusage 3000Kbps I really have no idea what to set this to, but the default of 600Kbps seems awfully conservative. All of the machines I plan to back up are 100Mbit minimum and several are Gigabit links to the backup server, so I raised this to 3000Kbps and we'll see what happens...I plan to adjust after seeing how it does for a few weeks. dumpcycle 1 week runspercycle 7 These last two mean that I plan to back up every night, and that I want a full dump once a week. tapecycle 10 tapes I will only need 7 tapes per cycle (at least as long as each night fits on one tape, which at ~ 1.3Gig per tape with hardware compression is the case for me for the forseeable future) but the comments in the file suggest a few extra for errors, and well, we bought 10, so I set it to 10. runtapes 1 1 tape per night is my expectation. tpchanger "chg-scsi" tapedev "0" changerfile "/usr/local/etc/amanda/CIS/chg-scsi.conf" Ok, here's where it starts to get interesting. Because I didn't read the TAPE.CHANGERS document first, I put tapedev "/dev/nst0" at first. Turns out that the chg-scsi script provides for a neat shortcut - If tapedev is set to a single integer, it looks for that config # in the chg-scsi.conf file (Detailed later). For now, just note that config 0 is the one that I've set as my tape device. I also indicate in this section that chg-scsi is the changer "glue script" that I want to use - after reading TAPE.CHANGERS, that seemed the most likely candidate. It billed itself as a script that attempts to drive changers that are their own SCSI devices and understand SCSI commands, and the TLS-5433 certainly is in that category, so I went with that. I also indicate the path to the config in the changerfile param. chg-scsi.conf is one of the files that got copied over from the examples/ directory - we'll edit that one in a moment. tapetype "SONY-SAIT" This one was a challenge for me. The string assigned to this param refers to a definition further down in amanda.conf that contains specs on the tapes you plan to use. amanda.conf ships with lots of pre-defined ones for all the common tape formats. However, I couldn't find a tapetype definition for my SAIT tapes, I guess because they are very new, I think they debuted in May of this year. Via some google searches, I learned that you can generate your own tapetype definition with a helper script called "amtapetype" that ships with amanda in the tape-src/ subdir. I forget if I had to run a 'make' here now or if it did it as part of the initial compile, but either way, it's straightforward. The command to run is: (load up a tape into the tape drive first - I did this via the menu on the tape changer device itself, but only because I hadn't yet discovered 'mtx' yet - I bet that it could issue a load command to do the same thing) # ./amtapetype -e 500g -t SONY-SAIT -f /dev/nst0 (this runs a LONG time, see below) The -e is VERY IMPORTANT - it's an estimate of the tape size. I have 500Gig tapes so 500g is the value. the -t is just a label for the output. The -f is the non-rewinding tape device. The first time I ran this, I didn't use the -e. 25 hours later, it was still running. What Amanda does here is write the entire tape, rewind, and write it again. If it has no idea how long the tape is, it takes a rather conservative approach. With the -e, it's speedier, though that's a relative term. It took 10.5 hours. Granted, 500Gig tapes are huge. Anyway, at the end, it threw this to STDOUT (so make sure you don't lose your console window during those 10 hours, or redirect the output)... define tapetype SONY-SAIT { comment "Sony S-AIT [produced by amtapetype]" length 487680 mbytes filemark 0 kbytes speed 29186 kps } I cut and pasted this into amanda.conf, and got rid of all the other tapetype defs. The tape drive advertises itself as capable of 30MB/second, so I was glad to see the speed close to this. The length was close too, not sure why it's slightly less than rated capacity, but it's not enough to concern me. Going back to amanda.conf now, we see how I got: tapetype "SONY-SAIT" labelstr "^CIS-[0-9][0-9][0-9]$" Later on, we're going to use a program to put Amanda labels onto the tapes (written to the front of the tape, not actual labels). I wanted mine to be of the form CIS-000, CIS-001, etc....to allow for plenty of tapes. The purpose of this param is because Amanda examines the labels on the tapes to know whether or not it's got the right tape for what it wants to do. amrecover_do_fsf yes amrecover_check_label yes amrecover_changer "/dev/null" To be honest, I haven't yet tried to recover, still perfecting backup, so these are probably wrong and will be changed once I try to recover. holdingdisk hd1 { comment "main holding disk - /dumps/amanda" directory "/dumps/amanda" # where the holding disk is use 50Gb # how much space can we use on it # a non-positive value means: # use all space but that value chunksize 2000Gb # size of chunk if you want big dump to be # dumped on multiple files on holding disks # N Kb/Mb/Gb split images in chunks of size N # The maximum value should be # (MAX_FILE_SIZE - 1Mb) # 0 same as INT_MAX bytes } Ok, the holding disk is where Amanda stages the backups. This system only has 73G of disk space, so I gave 50G to Amanda. I had to create the directory "/dumps/amanda" (and when creating directories or files, be careful to do it as the amanda user to get the right permissions). I didn't pay too much attention to chunksize - apparently this was a problem when systems couldn't handle files > 2G, but on RH 9 this isn't an issue. I used 2000Gb on the advice of the O'Reilly book. infofile "/usr/local/etc/amanda/CIS/curinfo" # database DIRECTORY logdir "/var/log/amanda/CIS" # log directory indexdir "/usr/local/etc/amanda/CIS/index" # index directory Ok, these caused me some heartache so listen up. infofile, despite the name, is a DIRECTORY. And you need to create it and the others. So create that directory. I liked keeping as much as possible under /usr/local/etc/amanda/CIS but that's not a requirement for these. Also create the logdir and indexdir directories. The one exception I made was for logs, which I put with the rest of the system logs, under /var/log. define tapetype SONY-SAIT { comment "Sony S-AIT [produced by amtapetype]" length 487680 mbytes filemark 0 kbytes speed 29186 kps } This is the definition that I discussed above. I'm not sure why they were down towards the bottom of the document instead of above where you set the tapetype, but I left my definition right where the others were. # dumptypes Almost the entire rest of the amanda.conf file is dealing with dumptypes. I didn't edit any of these, because I want to stick with defaults until I have a better grasp of how I want Amanda to behave. The idea here is that you can set up different dump types with different parameters such as whether or not you want compression, whether it should use 'tar' or 'dump', what it's priority should be, etc... but there are lots of defaults so I am content with them for now. define interface eth2 { comment "1000 Mbps ethernet" use 5 mbps } Finally at the bottom there are some settings related to your network interfaces, to help prevent Amanda from choking all bandwidth. I kept the local one as-is, but changed the name of le0 to eth2 (eth2 happens to be the one we are using in this server) and I changed the use to 5mbps. It's a Gigabit ethernet link, it shouldn't be an issue. However, I must make the caveat that the bandwidth throttling settings I've changed...I really have no idea what I am doing. :-) Also keep in mind that this value simply says that if bandwidth is already that high, don't start new backups. However, Amanda won't try to slow down the already-running backups, so if you have one backup that exceeds this, oh well. Alright! We're finally done amanda.conf! I hope this saves you time, because I had to make several passes over this conf to get things happy. #################### # 5. chg-scsi.conf # #################### The TAPE.CHANGERS document is a little weird, in that it kind of has the "theory/API" stuff up front, and the "practical" stuff in back. Just slog through it, you'll be better off for it. Once I did that, it was clear that chg-scsi was my best shot, so I went for it. Here is how I edited /usr/local/etc/amanda/CIS/chg-scsi.conf, first in full, and then I will break it down into it's parts... number_configs 1 eject 1 # Tapedrives need an eject command sleep 5 # Seconds to wait until the tape gets ready cleanmax 10 # How many times could a cleaning tape get used changerdev /dev/sg1 #emubarcode 1 havebarcode 1 tapestatus /var/log/amanda/CIS/tapestatus labelfile /usr/local/etc/amanda/CIS/labelfile scsitapedev /dev/nst0 # # Next comes the data for drive 0 # config 0 drivenum 0 dev /dev/nst0 # the device that is used for the tapedrive 0 startuse 0 # The slots associated with the drive 0 enduse 9 # statfile /usr/local/etc/amanda/tape-slot # The file where the actual slot is stored t is stored cleancart 33 # slot where the cleaning cart for drive 0 is located cleanfile /usr/local/etc/amanda/tape-clean # The file where the cleanings are recorded usagecount /usr/local/etc/amanda/backup/totaltime # This is the end Ok, so that's it. Much more manageable than amanda.conf and I didn't change as much. I set number_configs to 1, because that's how many I have. I set my changerdev to the device. This part was interesting: #emubarcode 1 havebarcode 1 I couldn't tell from the docs what they really wanted here, so at first I put both. My changer has a barcode reader, so I guess the emubarcode is for those that don't have one (of course, in hindsight, why would you need to emulate if if you had it? :-) If you have both, it complains, so I really should remove the emubarcode line altogether, but I wanted to point out that I don't know what emubarcode does, or if it works, because I do have an actual barcode reader on my changer. This may affect how some of the later setup steps act for others. Make sure to create (use 'touch' command) the files indicated in tapestatus (notes which tape is in the drive at the moment, I believe) and labelfile (this is an interesting file we'll discuss shortly). I indicated my scsitapedev, and then it was time to set up the actual config section for config 0. Remember back in amanda.conf when we set our tapedev "0"? This is what it is referring to. Ok, so for the values that I changed in this section: dev /dev/nst0 startuse 0 enduse 9 Ok, I have 10 tapes I want to use (remember we indicated that in amanda.conf). They will live in slots 0-9 of the changer. Now, my changer internally refers to it's slots as 1A01-1A11 for the first 11, 3A01-3A11 for the next 11, etc...but these slot numbers are more of a logical concept, so it spans over the physical as if they were one big magazine. I really have 3 magazines of 11 slots, but as far as chg-scsi is concerned, these are slots 0-32 as best I can tell. statfile /usr/local/etc/amanda/tape-slot Again, 'touch' this file cleancart 32 This is the slot where the cleaning cartridge lives, if there is one. I put mine in the last slot of the last magazine, so 32 by the logical mapping. I have no idea what it actually does with it. cleanfile /usr/local/etc/amanda/tape-clean When Amanda cleans, it stores that info in this file. 'touch' it. usagecount /usr/local/etc/amanda/backup/totaltime Amanda keeps track of how long the drive has been used in this file. 'touch' it. Ok, we're done with chg-scsi.conf ######################## # 6. Set up your tapes # ######################## This was one of the less-well-documented tasks but the O'Reilly book helped a bit. What it boils down to is that you need to write the Amanda label to all of the tapes, and then create mappings between the Amanda label and the barcode labels (if you have them like I do) so that when the barcode reader returns 000000001, Amanda knows this corresponds to it's own label of CIS-001. So, to do this, stick the barcode labels on your tapes as appropriate and then load your tapes in their slots you indicated previously (for me, slots 0-9 logically, or 1A01-1A10 in the physical magazine on the carosel.) Before we start, let's 'touch' the /usr/local/etc/amanda/CIS/tapelist file - Amanda stores the list of tape labels here. Now, lets write Amanda labels to the tapes. Now that they are loaded, issue this command as the amanda user: # amlabel CIS CIS-000 slot 0 This is where all sorts of problems crop up. First I had a path problem - amlabel is installed in /usr/local/sbin. Fixed my $PATH. This is also where I learned that the amanda user didn't have permission to access the /dev/sg1 changer device (because on my first attempt, I put amanda in the amanda group as the primary group and the disk group as the secondary group. Since /dev/sg1 is set chown root:disk and chmod 660, I thought this would be sufficient - it's not. Apparently, it has to be your -primary- group (verified with using the 'newgrp' command and then seeing things work). To make life easier, just put amanda in the disk group. Anyhow, if you get Permission Denied errors on the device, check that amanda is in the disk group, and that the disk group is the group associated with /dev/sg1, and that the group has write permissions. Same thing can happen for the tape drive itself, /dev/nst0. The amlabel script needs access to both. Ok, if you've set everything up right, what should happen is that amlabel will go grab the tape that's in slot 0, insert it to the tape drive, attempt to see if it already has a label (it won't, you might get a warning, that's ok), then will rewind it, label it with CIS-000, and exit. Yay, you just saw Amanda successfully control your changer for the first time! Be patient with it - there were several times that I did not think it was working when it was - it often paused for 20 seconds before moving the changer and such. Repeat for all remaining tapes: # amlabel CIS CIS-001 slot 1 # amlabel CIS CIS-002 slot 2 # amlabel CIS CIS-003 slot 3 etc....all the way to # amlabel CIS CIS-009 slot 9 Now it's time to build the inventory of your tapes... Remember how I said that labelfile was an interesting parameter up in the chg-scsi.conf file? This is where Amanda maps barcode labels --> Amanda labels. (And it writes it in some weird format, so don't attempt to read it - you'll think it's not working, but it really is - just watch the byte count of the file go up.) To initialize this file, run the following command: # amtape CIS show This tidbit of info was buried in TAPE.CHANGERS. What it does is it goes through all of your tapes one by one, scanning the barcode, reading the Amanda labels, and building the labelfile. I believe this is useful because when it comes time to search for a specific tape, Amanda can make use of the barcode reader to find it faster. I have not progressed far enough to test that yet. When the operation completes, your tapes and changer are ready to use with Amanda! ######################### # 7. Setting up clients # ######################### All clients (yes, even the server) need to be configured. They need their ports and services configured. Since the server is also a client, you don't need to set up the ports and services, since you already did it for it's "server side", but on remote clients you'll need to add the same entries to /etc/services and /etc/xinetd.d as we did for the server above. Remember to restart xinetd. Next you need to set up the amanda user on the client. I created a user named amanda. Then, create a file ~amanda/.amandahosts. This is similar to an .rhosts file in that it gives permission for the Amanda server to run dumps. The file has one line: keep.cis.uab.edu amanda Just the FQDN of the server (an IP works as well), and the dumpuser. Remember to create that file on every client. There are also other files that need to be present.on every client: /etc/dumpdates and /etc/amandates. These are where the client's 'tar' and 'dump' programs store info on what they have done, so that they know which level of backup to perform next. Might as well check for their existence and create them now. ############### # 7. disklist # ############### Ok, we're getting close! Now, go back to the server (since the client is the server in my example, I didn't have far to go :-) Edit the file /usr/local/etc/amanda/CIS/disklist to store the list of all the places that you want to back up. It takes the form: keep.cis.uab.edu /usr/local root-tar The first part is the hostname, the second is the filesystem you want to back up (can either be a directory name like here or a disk like /dev/sda1 - read up on all the options) and the third part is the dumptype (remember those from amanda.conf?) This one says I want to back up /usr/local on targethost using a dumptype of root-tar (which more or less is one that should be used for root filesystems where files don't change much, because it is set to low priority, and it uses 'tar' instead of 'dump'. One note here that tripped me - 'dump' can't do incremental dumps on partial filesystems. Meaning, if /dev/sda1 is mounted at /usr, you can use 'dump' to backup /usr, but not /usr/local since it's only a portion of the filesystem. I don't know why this is, but it's by-design, because you can read about it on the web and in the dump docs. The tricky part is that you don't notice right away because the first dump is always a full dump, and that works fine. But then on the second dump, Amanda starts failing....took me a while to learn why. Anyhow, for my test, I just picked /usr/local on the server itself (since like I said, my first client was the server itself). It's a very small area (~ 50Megs) so tests can run quickly. Eventually, my disklist will grow to cover all the filesystems of all the machines I want to backup, but for now, this will do. Also note that once you start doing multiple backups from the same client machine, the disklist can take additional parameters to specify which spindle of the disks they are on (you don't want two dumps going at the same time off of the same disk) as well as some control over which interface is being used (no idea what that's about). For now, we're done with the disklist. ######################### # 8. Testing your setup # ######################### We're -finally- ready to test! Here's where we learn about a very important part of Amanda - the amcheck program. This program looks at your disklist, makes sure everything on the server is working, contacts all the clients, makes sure they are all ready to go, and then if there's any problems, it lets you know. The idea is that you would set this to run in the afternoon while you are still at work, so if there's a problem, you can fix it before the overnight dump. So let's see how it works. As the amanda user run: # amcheck CIS This will run for a while, and give you some output about the status. Give it 2-3 minutes, it has to load a tape and read it, and then talk to all of the clients. If you have a problem with the tape or if the clients aren't ready, amcheck will tell you about it. When things go well, he output looks like: bash-2.05b$ amcheck CIS Amanda Tape Server Host Check ----------------------------- Holding disk /dumps/amanda: 63687596 KB disk space available, that's plenty amcheck-server: slot 3: date 20031222 label CIS-003 (exact label match) NOTE: skipping tape-writable test Tape CIS-003 label ok Server check took 36.872 seconds Amanda Backup Client Hosts Check -------------------------------- Client check: 1 host checked in 0.015 seconds, 0 problems found (brought to you by Amanda 2.4.4p1) bash-2.05b$ This is an invaluable tool! Get in the habit of RUNNING AMCHECK ANY TIME YOU CHANGE YOUR AMANDA CONFIG. I didn't, and I lost hours tracking down a problem that it eventually detected and told me about. Once you have that working, and it's reporting no errors, there's one last setting to change. In amanda.conf, find the global dumptype record: define dumptype global { comment "Global definitions" # This is quite useful for setting global parameters, so you don't have # to type them everywhere. All dumptype definitions in this sample file # do include these definitions, either directly or indirectly. # There's nothing special about the name `global'; if you create any # dumptype that does not contain the word `global' or the name of any # other dumptype that contains it, these definitions won't apply. # Note that these definitions may be overridden in other # dumptypes, if the redefinitions appear *after* the `global' # dumptype name. # You may want to use this for globally enabling or disabling # indexing, recording, etc. Some examples: # index yes record no } See how I've set "record no"? During testing, we don't want the clients to record their dumps and tars to their /etc/amandates and /etc/dumpdates files. Otherwise, when it comes time to do the real backups, they won't get off to a fresh start. So this turns that off for testing. Ok, now it's time to let Amanda do it's thing: # amdump CIS This does a LOT behind the scenes, which is very well documented in the O'Reilly chapter, but more or less, it's going out to clients, pulling back data, and writing it to tape if all went well. It takes a while to run, depending on the size of the areas you indicated in your disklist. You can sort of follow along by looking at the files in the /var/log/amanda/CIS/directory - one called amdump and one called log are there when amdump is actively running. (This is a good time to mention that Amanda is good at managing/rotating/tossing logs at the appropriate times). Eventually, the command should return. Congratulations, Amanda is working! ################################## # 9. Finding out what Amanda did # ################################## Great! So what did it do? Check your email (the address you indicated in amanda.conf). You'll have something like: From: amanda@keep.cis.uab.edu To: sysadm@keep.cis.uab.edu Subject: CIS AMANDA MAIL REPORT FOR December 22, 2003 Date: Mon, 22 Dec 2003 16:59:56 -0600 These dumps were to tape CIS-001. The next tape Amanda expects to use is: CIS-002. STATISTICS: Total Full Daily -------- -------- -------- Estimate Time (hrs:min) 0:00 Run Time (hrs:min) 0:03 Dump Time (hrs:min) 0:00 0:00 0:00 Output Size (meg) 49.7 49.7 0.0 Original Size (meg) 49.7 49.7 0.0 Avg Compressed Size (%) -- -- -- Filesystems Dumped 1 1 0 Avg Dump Rate (k/s) 84288.1 84288.1 -- Tape Time (hrs:min) 0:00 0:00 0:00 Tape Size (meg) 49.7 49.7 0.0 Tape Used (%) 0.0 0.0 0.0 Filesystems Taped 1 1 0 Avg Tp Write Rate (k/s) 7407.2 7407.2 -- USAGE BY TAPE: Label Time Size % Nb CIS-001 0:00 49.7 0.0 1 NOTES: planner: Adding new disk keep.cis.uab.edu:/usr/local. taper: tape CIS-001 kb 50944 fm 1 [OK] DUMP SUMMARY: DUMPER STATS TAPER STATS HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -------------------------- --------------------------------- ------------ keep.cis.uab /usr/local 0 50910 50910 -- 0:0184271.3 0:077406.9 (brought to you by Amanda version 2.4.4p1) Wow! Look at all of that. The O'Reilly book has a good section on reading this sort of thing, but the general idea is that it dumped 49.7Megs from 1 filesystem, it was a full dump, it took 3 seconds (that's what a $30,000 tape library system gets for you :-), and some notes on what the planner did and such. Very imformative. If there was a problem, it would be prominently displayed towards the top of the email - I learned many times the hard way. :-) Of course, this report gets more interesting with more areas being backed up. Once you have success with this, create a couple of files under /usr/local (or whatever area you chose to dump), edit some files under there, etc... in other words, simulate changes. Then run amdump again: # amdump CIS When it's done, the email should now show that it did an incremental dump this time. It should be a much smaller amount of data. Do this as many times as necessary to convince yourself that it's working. When you are all done testing, we need to do a couple of things to cleanup. First, go and set record back to "yes" in the amanda.conf global dumptype, as well as enabling the "index yes" for indexing: define dumptype global { comment "Global definitions" # This is quite useful for setting global parameters, so you don't have # to type them everywhere. All dumptype definitions in this sample file # do include these definitions, either directly or indirectly. # There's nothing special about the name `global'; if you create any # dumptype that does not contain the word `global' or the name of any # other dumptype that contains it, these definitions won't apply. # Note that these definitions may be overridden in other # dumptypes, if the redefinitions appear *after* the `global' # dumptype name. # You may want to use this for globally enabling or disabling # indexing, recording, etc. Some examples: index yes record yes } Then, we have to make Amanda "forget" what it's been doing. The way to do that is the following recipe (from O'Reilly book): - Remove the files in the infofile and indexdir directories (those were set in amanda.conf) - Remove the tapelist file - Remove all amdump.* files in the configuration directory - Remove all log.* files in the log directory - Run 'amrmtape