Open-Source Backups Using Amanda
Listing 2. A Brief Example of the .amandahosts File
localhost amanda localhost.localdomain amanda foo amanda foo.localdomain amanda
If you run a firewall, initially it can be somewhat of a challenge to work out the rules that allow Amanda access. The Amanda server contacts the clients on port 10080. At this point, the Amanda client forks the amandad process and seek random UDP ports on the Amanda server. In turn, the server opens a couple of ports to the client for the data and messages. If indexes are enabled, they also need an additional port open on the server, TCP 10082.
The random ports can be addressed in multiple ways. Beginning with Amanda version 2.4.2, a compile option, --with-portrange=xxx,yyy, directs Amanda to use the given port ranges to connect clients and servers. The selected port range needs to be opened on both the client and server ends of the firewalls. If you plan on running amrecover on the client end, you should plan on opening TCP ports 10083 and 10082 on the server, in addition to UDP port 10080 on both the server and client machines. All to these are in addition to the ports defined with --with-portrange.
Amanda has the ability to work with most tape devices and libraries. The tricks are defining the proper tape type in the amanda.conf file and selecting and defining the proper changer scripts (Listing 3). A single tape drive is by far the least complicated method and simply by defining the type of drive and tape type in the amanda.conf file you are on your way. If a tape library or stacker is available, the configuration is a multiple-step process consisting of defining the tape changer program in amanda.conf (cgh-multi, chng-scsi and chg-zd-mtx are three examples of configurations) and providing a changer file directly within amanda.conf. With the Amanda server running on a Linux platform, you need the sg (scsi -- generic) module compiled into the kernel. You also need the mtx program if you are running any of the mtx-based changer scripts. Amanda seeks a valid header on tapes, and without it amcheck and/or amdump fails. Use the amlabel tool to label the tapes, along with the regular expression defined in the amanda.config file, for example:
/usr/sbin/amlabel DailySet DailySet1
Listing 3. The Defined Tape Changer in amanda.conf and an Example CHANGER.conf File
# At most one changerfile entry must be defined; #select the most # appropriate one for your configuration. #If you select man-changer, # keep the first one; if you decide not to use a tape # changer, you may # comment them all out. changerdev "/dev/sg1" runtapes 1 # number of tapes to be used in a / #single run of amdump tpchanger "chg-zd-mtx" # the tape-changer / #glue script tapedev "/dev/nst1" # the no-rewind tape / # device to be used changerfile "/var/lib/amanda/CHANGER" The CHANGER.conf file changerdev=/dev/nst1 havereader=1 offline_before_unload=1 OFFLINE_BEFORE_UNLOAD=1 poll_drive_ready=10 Max_drive_wait=99 unloadpause=20 driveslot=0
When dealing with multiple computing groups or business departments, you may determine that a separate backup scheme for each group is required. This is accomplished easily using Amanda with separate backup configurations. An example of this would be two backup environments, one for each of two projects being funded independently and therefore requiring that you account for the time and resources spent on each. Environment one is labeled DailySet-BigFunds and environment two is labeled DailySet-LilFunds. For the DailySet-BigFunds project, you have a large tape library that houses ten tapes. DailySet-LilFunds provides you with a single DLT IV drive whose tapes must be changed daily. To keep these two projects separate but housed on the same backup server, you would set up the separate directories in /etc/amanda as DailySet-BigFunds[number of runs] and DailySet-LilFunds[number of runs]. Each of the mentioned directories would contain an amanda.conf file and a disklist of the included filesystems to be backed up. This pattern allows mutually exclusive backups to be performed on separate tape devices. If and when configuration changes must be made, you need to make them only to the relevant files. This is handy in an educational environment where you often have multiple groups with varied hardware and backup media.
Here we are with the software installed, the tape and library devices working and the tapes all labeled, loaded and ready to go. So, who do we call to begin our virtually hands-off backups? None other than crontab, which helps make our backups as hands-off as possible (Listing 4). It is recommended that your crontab contain two entries for each Amanda run that will take place. The first entry should be an amcheck to check the tape drive, tape header and each Amanda client to ensure that the backup operation is carried out as planned. A good idea is to have this mailed back to a system account that is checked often enough so that any problems can be corrected prior to run time. The second entry per job in the crontab should be the amdump command itself, which allows Amanda to begin the backups without user intervention.
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Secure Server Deployments in Hostile Territory, Part II
- Hacking a Safe with Bash
- KDE Reveals Plasma Mobile
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- General Relativity in Python