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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script