Friday, August 27, 2010

UCI OSS Backup Evaluation

Category: Amanda, Backup, Bacula — SkyHi @ Friday, August 27, 2010

by Harry Mangalam
<harry.mangalam@uci.edu>
version 0.5, 23 Oct 2009

1. Introduction and Constraints

UCI, like many UC campuses, is facing the dual squeeze of decreasing IT budgets, and increasing licensing fees for our institutional Backup Systems. We also are facing somewhat more requirements from clients as more data is being gathered or generated, analyzed, and archived. In view of these pressures, the Office of Information Technology (OIT) is evaluating what our requirements are, and what Backup solutions can be used to more economically address our needs. We are evaluating both Proprietary and Open Source Software (OSS) approaches and it may be that the optimal solution is a combination of the 2.

Any Backup approach is guided by at least 2 issues:

The value of the data (or the cost of replacing it).
The cost of backing it up.

Much of the most valuable institutional data is stored on high-cost, high-reliability, highly-secured central servers. This makes backup fairly easy and most such devices have inherent or included data redundancy or data protection, making decisions about what backup system to use much easier (in some cases, there is no choice at all since the proprietary nature of the storage allows only the vendor’s implementation).

The situation is somewhat different for a university, which brings in much of its support $ in the form of overhead on grants. Such faculty-initiated grants brought in ~$328M in external funding last year for UC Irvine alone. Those grants were being composed on and still reside substantially on personal Laptops and Desktops scattered around the campus. The vast majority of them are backed up sporadically, if at all. I’ve had personal experience in trying to rescue at least 5 grants that were lost to disk crashes or accidental deletion days before the submisison date. That is valuable data and it would be exceptionally useful to be able to provide backup services to such users, even disregarding the somewhat less critical primary data from their labs. At UCI, this includes about 400 faculty who write for external grants on a regular basis. Any Backup system should minimally cover these people and therefore the scalability and Mac/Windows client compatibility of any such system is quite important.

Below is a summary of our current backup systems, EMC Networker and EMC Retrospect.

2. Networker Client Load

We currently use Networker to back up ~230 clients (mostly other servers) to 3 backup servers, with storage requirements as described graphically below:

and statistically here:

Sum       109326.2 ........ total GB
Number    227 ............. # clients
Mean      481.61 .......... GB / client
Median    155.9 ...........     "
Min       0.2 ............. GB on smallest client
Max       4651.2 .......... GB on largest client
Range     4651 ............ diff between 2 above
Variance  523643.27 ....... among all clients
Std_Dev   723.63 ..........        "
SEM       48.02 ...........        "
Skew      2.43 ............        "
Std_Skew  14.99 ...........        "
Kurtosis  6.97 ............        "

We currently use about 1/4 of an FTE to administer the Networker system after setup. The IAT recharge rates for this service is listed here, but in summary, it’s $20/mo/system plus $.39/GB for storage and a $40 charge for file restores.

3. Retrospect Client Load

Retrospect is a disk-only based system,

We currently pay $620/yr for this license and currently have 59 clients (18 Macs, rest Windows).

We currently charge $87.50/user/year with a 50GB limit on storage, with self-service file restores.

4. Open Source Backup Software Evaluation

There are perhaps 50 OSS Backup systems, but most of them are too limited in their features or maturity to be considered. Only 3 seem to rise to the level of possibility, tho for different things:

Amanda - A good, neutral description from BackupCentral. Zmanda provides commercial suport and additional code goodies.
Bacula - A good neutral description from BackupCentral. Bacula Systems provides support.
BackupPC - A good neutral description from BackupCentral.

Amanda, Bacula, and BackupPC share these characteristics:

All have Commercial support available now or imminently.
The OSS version is of course, free for unlimited number of servers and clients.
All can backup to disk.
All have Open Source versions (altho Amanda and Bacula have $ versions that have additional, non-OSS goodies provided.
All can support MacOSX, Windows, *nix clients via some combination of rsync, samba, semi-proprietary protocol (Bacula protocol is OSS, but only Bacula uses it it)
All can support 10s-100s of clients per server.
None currently have support for the NDMP protocol (tho Bacula and Zmanda are planning it)
None support transparent Bare Metal Restore
None support duplicate on backup
None natively support Snapshots altho all can be implemented on Solaris to provide a number of ZFS features such as: snapshots, filesystem compression, slightly better I/O, etc. However, while Solaris is certainly stable, there are still aspects of ZFS that seem to be causing problems. (To ease a transition from Linux to Solaris, Nexenta is a free distribution of Solaris packaged as Ubuntu).

4.1. Amanda/Zmanda

useful for separate instances of backup servers servicing sets of clients (star config)
store to tape or disk; can use Barcode writers, readers to generate, process labels
Amanda uses std unix text-based config files; seems to be more easily configurable than Bacula, tho less so than BackupPC (configured by Web GUI or text files)
very flexible backup scheduling mechanism
uses open & common storage protocols (tar, dump, gzip, compress, etc)
very secure by on-wire & and on-disk encryption
CLI or GUI available.
mature (16yr), extremely well-reviewed C++ source code. Zmanda says that they are re-writing it in Perl for easier maintenance and to encourage more external contributions.
very large user base
Zmanda extension for backing up MySQL.
uses own internal datastructures, so no additional DB instance required.
Zmanda-supplied technical PDF about current and near-future options (NDMP, others)
Commercial support costs are as described here.

4.2. Bacula

Commercial support available
store to tape or disk
allows multiple servers to service multiple clients simultaneously, allowing a much larger single instance
uses SQLite, MySQL or PostgreSQL as DB (all well-supported & understood), but additional complexity, and DB is therefore a critical link.
published storage code, but not as widely used as Amanda
Commercial support costs are as described here.

4.3. BackupPC

Zmanda will be providing commercial support for BackupPC very soon, probably ~$10/client for large academic institutions.
store only to disk, not tapes; therefore not useful for long-term archiving, unless willing to buy appropriately large hardware.
support for client restores
UCI-written support for client self-registration.
rsync support depends on Perl implementation of rsync so it lags the most recent rsync features by a few revisions.
supports file de-dupe via hard links, but hard links limit the storage to 1 filesystem (but XFS, ext4 support up to >= 1-8 EB).
uses file tree, not DB, as the data structure; simpler but more primitive.
uses no proprietary or application-specific client software; therefore very simple to implement and robust for restores.
supports encrypted data transfer for MacOSX, Lin, but not (easily) for Windows (encryption requires use of ssh public key from server and ssh remote execution of windows executables).

4.4. Some Feature Comparisons

Nice Table of Feature Comparisons among OSS Backup packages and proprietary Backup packages

4.5. Crude Measures of popularity

Via Google-linking (a very crude measure; very sensitive to key words)

Amanda/Zmanda: 411,000 google links; 460 pages linking to zmanda.com; 252 linking to amanda.zmanda.com
Bacula: 402,000 google links; 468 pages linking to www.bacula.org.
BackupPC: 267,000 google links; 5,070 pages link to backuppc.sourceforge.net; 3,140 pages link to backuppc.sf.net

And for some comparison:

Vertitas: 255,000 for veritas backup software; 5,510 linking to http://www.symantec.com (all products)
Networker: 66,500 for EMC networker; 2,370 linking to emc.com (all products)

Google Trends indicates that the Search Volume Index is decreasing rapidly for Veritas, is holding constant for EMC Networker, Bacula and BackupPC, but Bacula is ~3x the value of BackupPC, which is itself 2x EMC Networker. Veritas has decreased to just above BackupPC. Zmanda only started in 2006, and does not have much of an index built up, but it show significant spikes in News Reference Volume. "amanda backup" has been decreasing from 2004 and remains about 1/2 of BackupPC and 1/6 of Bacula.

5. Future Projects

I would like to see the automatic backup of all of our faculty’s Desktops/Laptops (\~1000) to shield against catastrophic loss of recent data, but I’m not sanguine about the chances for this due to funding issues, unless we go with a pure OSS solution, which would be considerably better than nothing at all.

5.1. Details

At 10GB per faculty, this would mean a storage server of ~20TB (now a medium-sized file server), and at 1% data changing per day, that means that on the order of 100GB a day would have to be transferred for incremental backups. At 7 MB/s (a decent transfer rate over 100Mb), transmission time is only ~4 hrs, easily done in a night, in parallel sessions. Measured on an Opteron backup server (doing server-side compression & file deduping via hardlinking), it takes about 25% of a CPU to handle 1 backup session, so a 4-core machine could theoretically handle ~16 simultaneous backups, if the bandwidth can supply it with enough data. Our test backup server is currently single-homed, but has 5 interfaces, so could easily be multi-homed. If we use OSS Backup software, it will cost \~$10K for hardware to provide 1000 very valuable PCs or laptops with at least protection against catastrophic loss.

6. Considerations for any such decision

Please feel free to expand on (or critique) these points.

6.1. Clients

what features of current clients are actually used? (Do you need a wiki or calendaring function in your backup software? - why pay for unused features?)
how many clients currently served?
- how many would you like to serve?
OS distribution of clients
minimum backup cycle
how much data per client per cycle
- max data accepted, if such a limit
do clients need to be able to initiate their own backups?
client email notification of problems or email just to admin?
mechanism of backup (rsync or propr.)
compressed on client or server (open or propr.)
client upgrades done from server, or client involvement
preferred client registration (self or admin registration?)
support of mobile client IP’s or static IP only?
local nets only or internet support (backup/restore in Europe?)
special application backups required? MS Exchange, RDBMSs, CMSs
does timing of backup have to be client-adjustable or just at night or doesn’t matter?
typical client ethernet type and number of hops to server
need to support secure backup over wireless?
can open files be backed up? Win/Lin/Mac ⁺
do you need to back up encrypted filesystems and if so, how many features will work with such filesystems?
are clients cluster aware? Can they back up to a cluster or one of a set of distributed servers? ⁺
if the software backs up Windows servers, is it SharePoint-aware? Exchange-aware? ⁺
if the software backs up Windows servers, can it do hot reinserts into Active Directory? For example, can it restore a single security group deleted from a domain controller or a single mailbox on an Exchange server? ⁺
can users recover files themselves? If so, are they properly restricted to only recovering files they own? ⁺

6.2. Server & Admin

what features of the server are actually used. (why pay for unused features?)
how many servers are required per 100 clients?
what is the FTE setup, configuration, and support requirements for the server & each type of client?
do servers stage-to-disk before writing to tape? ⁺
if multiple servers, are they synchronized or independent?
type of server required (OS, CPUs, RAM, used for other services?)
is there an institutional inability to deal with a particular platform?
how many net interfaces per server are typically being used?
data format on server (open, propr.)
storage (tape / tape robot, disk, hierarchical)
type of server admin interface used, preferred (native GUI, Web, CLI)
database, other support software required (OSS, propr.)
how are server upgrades done?
does a feature of the backup server require or obviate a specific filesystem type?
can you have (do you need) standby servers?
how much of the system can be tested at once to see if it fits our situation? Will the PS vendors allow us to set up a multi-server installation over the course of 3 months to verify their claims?
what is the complexity of the system? For a particular feature, is the complexity required to implement or support it worth the effort?
is the software database server-aware? For example, can it backup Oracle databases without having to take the databases offline? ⁺
Does it support direct fiber/fiber-aware backups? ⁺

6.3. Backup Protocol

what kinds of backups are required (disaster recovery, archival, incremental, snapshots)
network protocol used, preferred
encryption requirements (client-side? server side?)
type of data compression used, preferred - format, block-level de-duping? file-level de-duping?, with HW accel or just software?
is dedupe technology required? Versus just buying more storage media? If needed, what level is needed? (compression of individual files, hard links to files, proprietary dedupe technology, target or source-based dedupe, etc)
does the software deduplicate to tape? Or does it reconstitute the data, then write it to tape? ⁺
does the de-duplication component (if the backup software has one) write both the deduplicated data and the de-duplicate table to physical tape? (This obviates the need to have the same backup server to reconstitute the data.) ⁺
if using rsync, which version? Version 3x has significant advantages over 2x. ⁼

Contributions:

⁺ contributed by Scott Talkovic

⁼ contributed by Scott Beardsley

6.4. Cost, Cost Efficiency, & Legal Concerns

what is the cost per user for the system?
what is the coverage of the various systems at different price points?
what is the tradeoff of moving up one curve and down another? (for example, the cost of using inefficient dedupe technology and compensating with more storage, vs using efficient, but proprietary dedupe technology)
do the constraints on the variants of dedupe, compression, encryption conflict
what is the institutional cost of using technology that does not cover all clients equally vs the cost of not covering them at all?
what features in the proprietary software will actually be used? (Since we have such systems, we should be able to document this at least for Networker and Retrospect)
what is cost and timing of scaling? If we have to provide backups for a new department suddenly, what is the $ cost and the time lag?
if it’s possible to go out of compliance, what is the cost of doing so?
what legal recourse is there if the system fails in some way?

7. Feedback and Suggestions

We are still in a preliminary mode for this evaluation, but if you have suggestions, queries, or would like to be notified of the final result and sent any documentation of the process, please let me know.

7.1. Contributed Suggestions

While your open source solutions are good how easy are they for the end user to restore and what about reporting? [Someone] turned me onto Crashplan which is definitely not open source, [but] is a pretty good and robust product. It’s very simple for the end user. It provides daily reports to the admin & user on backups, super simple for restores, allows for individual or group quotas, incremental backups can occur during certain hours or continuous real-time backups. Stores to disk. Data is encrypted & compressed before sending. Identical files across any directory or client are stored only once. Users can back up data to other sites as well or others using Crashplan software for additional redundancy. Runs on Linux/Mac/Windows platforms. Unsure how well it scales. Supposed to handle thousands of connections and terabytes of data. Server is free while the client is expensive ($70/client [for < 5 clients]) but allows backups from anywhere.

Steve Carlyle <Steve.Carlyle@uci.edu>

8. Resources

8.1. Books

The O’Reilly book Backup & Recovery: Inexpensive Backup Solutions for Open Systems is a good overview of some important considerations for a backup system. UC people can read it in its entirety here via O’Reilly Safari

Note that O’Reilly itself uses a combination of commercial and Open Source tools.

8.2. Web sites

Curtis Preston, the author of the above book runs a backup-related site called BackupCentral, which is a very good info clearing house / blog on all things backup.

The slightly irritating, but fairly entertaining Curtis Preston in a 44m video about various backup and dedupe schemes.

SearchDataBackup is another backup-related site.

8.3. Whitepapers

Of variable quality, some sponsored by vendors.

Backup on a Budget (PDF) - by the ubiquitous Curtis Preston. Reiteration of many of his points, especially pointed to the fact that for many organizations, backup is not rocket science, people are the most expensive thing you pay for, and that backup to clouds may be useful (but mostly in rare occassions).

8.4. Useful(?) individual pages

Comments about IBM’s Tivoli Storage Manager

8.4.1. fwbackups

Via TechRepublic’s 10 outstanding Linux backup utilities. Very short list, with some interesting choices. fwbackups is a very slick little program writ in Python/GTK that can work on all platforms (but GTK on Windows requires the whole GTK lib). It’s not an enterprise system, but if you have a Personal Linux box to back up it’s pretty straightforward, and can use rsync/ssh to encrypt over the wire. However, it does require your own shell login and dedicated dir space on a server.

Boxbackup is not in the running for an enterprise backup system, but is interesting for near-realtime backup for a small group of clients.

9. Latest version

The latest version of this document should always be here.

REFERENCE
http://moo.nac.uci.edu/~hjm/UCI_OSS_Backup_Evaluation.html

http://moo.nac.uci.edu/~hjm/UCI_OSS_Backup_Evaluation.html

How to install and configure Bacula

Category: Backup, Bacula — SkyHi @ Friday, August 27, 2010

Bacula is an on-linebased back up tool. Which is used to backup files from different servers into back up server where the bacula is running. For setup this backup tool across network first you have to install bacula server package on backup server machine where you are storing your backup contents ,and install bacula client daemon on all other servers from where we are going to backup data.

Bacula has five main components.

1.Director daemon

This daemon co-ordinate all working of backup,and through its configuration file we can specify all these things.

2.File daemon

This daemon works in all clients from that client we are backup data. Director daemon connect to this daemon after authentication and backup the files from this client.

3.Storage daemon

This daemon is for store the backup data from client in to hard disk of backup server,usually this daemon and director daemon works in the same backup server. director works as intermediate between the file daemon and storage daemon.

4.Console daemon

This is a terminal to control all works.This console connect to director daemon and using its commands we can define all things related with backup .

5.Catalog Database

The database used here is for store all information related to the backup, including the file indexing.Commonly used database for bacula is Mysql.

This figure shows how the different bacula daemon configuration files were linked together.

Install and Configure Bacula Server

You can install bacula from rpm packages or from Source compilation. Here we are focusing on the source method,which is tested and is working fine.
* Download latest version of bacula from bacula.org site .
Here we are using following versions

1. bacula-3.0.3.tar.gz (http://sourceforge.net/projects/bacula/files/bacula/3.0.3/bacula-3.0.3.tar.gz/download)

2. depkgs-18Feb09.tar.gz or later versions (http://sourceforge.net/projects/bacula/files/depkgs/18Feb09/depkgs-18Feb09.tar.gz/download)

This two packages are used to setup a bacula,In which you have to install depkgs-18Feb09.tar.gz first to solve remaining dependency problems before starting bacula-3.0.3.tar.gz. You should not hesitate to install depkgs-18Feb09.tar.gz ,it contains different packages ,in which you can install “mtx and qwt”. you need not install sqlite database because mysql is the default database.

tar -xzf depkgs-18Feb09.tar.gz
cd depkgs
make qwt
make mtx
gmake mtx-instal

Then Enter in to the bacula source directory and Use the following configurations settings to install bacula (Or You can use system default configuration)

 CFLAGS="-g -O2" \
./configure \
--sbindir=/usr/local/bacula/bin \
--sysconfdir=/usr/local/bacula/bin \
--with-pid-dir=/usr/local/bacula/bin/working \
--with-subsys-dir=/usr/local/bacula/bin/working \
--enable-smartalloc \
--with-mysql \
--with-working-dir=/usr/local/bacula/ \
 --with-dump-email=user.name=@????.se \     #The mail addresses is to mail all activities of your backup in to your inbox.
--with-job-email=user.name@????.se \
--with-smtp-host=localhost \
--enable-bat \
--with-qwt=/usr/local/qwt-5.0.2/        #path to qwt source folder( usually it is inside depkg folder that you are installed previously)

make

make install

make install-autostart   #only supported for the officially supported systems (Redhat/Fedora...).This will put all startup script into the /etc/init.d/ folder and corresponding syslinks , so automatically start corresponding daemon at  startup.
make distclean  # type this to clear all configuration settings if you are starting ./configure from beginning.

Now you are successful completed the installation of bacula server , then type

Then we have to setup the Database to store the catalog information.Most commonly used database is Mysql,and setup the corresponding users,databases and privileges for the bacula application.

/etc/init.d/mysqld start

Bacula installation has included some scripts to complete the initial database and other server setups, these scripts are under your bin folder of the installed directory.

cd /bin

./grant_mysql_privileges -u root -p

 Create database

./create_mysql_database -u root -p
./make_mysql_tables -u root -p
 
 create a directory called working under /usr/local/bacula/bin/
Afrer installation of bacula. navigate to installed folder and run bacula by typing
 ./bacula start
 
 
 This will start all three daemons ( bacula-dir,bacula-sd and bacula-fd)
And then check ports where these daemons are listening.
 
 default case:

daemon    |  port
===================
bacula-dir   9101
bacula-fd    9102
bacula-sd    9103

make sure that the above mentioned ports are added and opened in the csf.conf file of the server or in some other firewall settings
 
 
 After successful installation to start the sample backup from same system where you installed all three daemons . Follow this simple tutorial :
http://www.bacula.org/en/rel-manual/Brief_Tutorial.html#TutorialChapter
To administrate  bacula it  provide a console or terminal named as bconsole . Using this console we can do all work from back end.
NB: For installation from source package, after detar you should read the README and INSTALL files. Most of the time this will helps you to complete installation.
Install and Configure Bacula Client
CFLAGS="-g -O2" ./configure  --bindir=/usr/local/bacula/bin --sysconfdir=/usr/local/bacula/bin --with-pid-dir=/usr/local/bacula/bin/working --with-subsys-dir=/usr/local/bacula/bin/working --enable-smartalloc --with-working-dir=/usr/local/bacula/ --with-dump-email=user@yourdomain.com --with-job-email=user@yourdomain.com  --with-smtp-host=localhost  --with-qwt=../depkgs/qwt-5.0.2/(here path to qwt source) --enable-client-only
 
  If your system is 64-bit(To know it use the command arch ) then add –libdir=/usr/local/lib64
make

make install

make install-autostart-fd     //It helps start client daemon at start up.

create a directory called working under /usr/local/bacula/bin/
start the file daemon using
 /etc/init.d/bacula-fd start

 add a new “client”and “job” in to the bacula-dir.conf
and set the password in the in the conf’s as shown in the above figure (Use above tutorial also)
Use Follwing configuration checking if you have any problems with the bacula setup
 
 a) Client bacula-fd daemon listening to 9102
b) Edit bacula-fd.conf ,Change the Director name and password to Director name and client resource password in the  bacula-dir.conf
    file of the Server.
c) Add server hostname to the /etc/hosts of the client system, inorder to ensure correct resolution.

d) Also check the ports 9102 to listen server request and 9103 to contact server storage daemon by typing

telnet server-hostname 9103 (from client )
telnet client-hostname 9102  (from server)

========================================================================================
Above procedure is the standard installation steps ; You can download and use the documentation (*.gz) package from bacula.org for more details.
========================================================================================

SET UP WEB BASED INTERFACE TO MONITOR BACULA( php and perl based)

—————————————————————————————————————-
( Install this package in your backup server where your bacula-server is installed)

1.Bweb web based comprehensive admin tool

Bweb developed up on perl,so in order to install bweb we need to install some perl dependencies files.
you can use cpan.
You can install this tool just following the INSTALL file under bacula-gui-XXX/bweb/. This file is more than enough to complete the installation of bweb.

2. bacula-gui-3.0.3.tar.gz

Download this package to setup web interface .

Detar this package and Read README to complete installtaion [in this package You need not type ‘make or make install’ , just

1./configure --with-bacula=(path to bacula source folder)

Then copy the bacula-web from this source folder and place it in your document root of the apache.

NB: This gui was only tested with php 4.3.4 and php-5.0.4,later. you may get blank page while you are using later versions.check the error log and correct it (may be some permission error ). If you have any problem to install php 4.3.4 with your latest apache 2.2.* then go for apache 2.0.* versions.

Here we tested the following versions.
1.Install pear DB by typing “#pear install DB ”
2.apache 2.0.63
3.php-4.3.4

After installation web-servercopy copy folder bacula-web to its document root , then type : http://system-ip:/bacula-web

Some Error Fixes:

————————————

1.If your configuration of server and clients seems to be correct, but you still receiving this error

eg:”: Fatal error: bsock.c:135 Unable to connect to Client: server.client.com-fd on server.client.com:9102. ERR=Interrupted system call ”

* Please check the firewall configurations,whether ports 9102 not blocked at client server and 9101or 9102 are not blocked at server .
* To check this telnet to destination port. If the system is installed with csf ,then check the TCP IN and OUT allowed ports.

REFERENCES

http://www.sparksupport.com/blog/how-to-install-and-configure-bacula

Zmanda The 15-Minute Backup Solution

Category: Amanda, Backup, Bacula — SkyHi @ Friday, August 27, 2010

Secure Network Backups in a Heterogeneous Environment in the Time it Takes to Have Pizza Delivered (All Using Open Source Software!)

This setup below was performed using Amanda 2.5.1p2. To learn how to set up:

- the latest version of Amanda 3.x with new configuration tools

- the new Volume Shadow Copy Service (VSS) based Zmanda Windows Client Community Edition

Please register on Zmanda Network and read Setting-Up an Open Source Backup Software Amanda Community in About 15 Minutes white paper available in the Resources section.

Today’s businesses rarely run on just one operating system. Linux users and administrators often have strong preferences for one distribution over another; web designers might lean towards the Mac; legacy software and hardware can include various UNIX operating systems. Despite the complexity of modern business computing environments, a system administrator is expected to find a reliable backup solution.

Even in the case where users are expected to keep important files on networked resources, for true intellectual data security, desktop machines and laptops will also be backed up. The price of hard disk storage is continuously falling, bringing terabytes of storage within reach, and increasing the amount of data that can potentially be lost. (The amount of data that you have will always expand to fit the storage available; as the golden rule states.) We live in a global and e-commerce economy, where businesses run around the clock and crucial business data changes commensurately.

The Challenge

For our 15-minute challenge, you will backup two Linux systems (each running a different Linux distribution) and one Windows system, using freely downloadable open source software.

Our scenario is as follows:
The user "pavel" works with sensitive information. We need to make an encrypted backup of his home directory, /home/pavel, which resides on a Fedora Core Linux system called Iron. Our webmaster needs the webserver's document home backed up, the /var/www/html directory on a SUSE Enterprise Linux system called Copper. Our manager works solely on a Windows XP system called Uranium, and keeps all of his work in the MyDocuments folder, so we will need to add //Uranium/MyDocuments to our backup configuration.

The Solution: Amanda

Amanda is open source backup software that is flexible, secure and scalable to dynamic computing environments. Amanda can save you from expensive proprietary backup software and those custom backup scripts that have a propensity to break at the worst times. Dating back to 1991, Amanda has been used successfuly in environments from one standalone machine to hundreds of clients. Amanda is so thoroughly documented, from community wikis to published system administration texts, that it might be hard to discern just how easy an Amanda backup can be.

This article will show you how, in about 15 minutes, you can:

1. Install and configure the Amanda backup server.

2. Prepare three different clients for backup.

3. Set backup parameters.

4. Verify the configuration.

5. Verify the backup.

We will install and configure Amanda backup server software on Quartz, which is running Red Hat Enterprise Linux. We will install and configure Amanda backup client software on Copper and on Iron. The Windows XP client, Uranium, will be backed up with Amanda server software running in conjunction with Samba on the backup server, Quartz.

Client	Filesystem	OS	Compression	Encryption
Copper	/var/www/html	SLES9	Yes	No
Iron	/home/pavel	FC4	Yes	Yes
Uranium	//uranium/MyDocuments*	WINXP	Yes	No
* using Samba (i.e. without installing any software on the Windows system)

Amanda gives you the capability to use disk storage as backup media. Configuring, initiating and verifying a backup will complete the backup cycle, all in less than the time it takes for a pizza to be delivered!

Prerequisites

The basic Amanda setup consists of an Amanda server, the Amanda client or clients that are to be backed up, and the backup storage media such as a tape or hard disk device. An intermediate holding area for caching data is not absolutely necessary, but will improve performance significantly and is considered part of a basic setup.

Before we begin, please review the introduction to Amanda. Then, note the following prerequisites:

tar 1.15 or later and xinetd are installed on Quartz, Iron and Copper.
Quartz is able to send mail to the root user.
The systems are all on the same network and available.
You have root access, and root access through SSH is enabled and working.
The directories to be backed up exist.
The Amanda 2.5.1p2 backup_server RPM should be available on Quartz, and the backup_client RPM should be available on Iron and Copper. Amanda binary and source RPM packages and source tarballs are freely available from Zmanda.
Quartz, the backup server, is running Samba client software. Samba is also freely available open source software.

To support the encrypted backup of /home/pavel on Iron, the following packages should be installed and available on Iron:

sharutils (for the tool uuencode)
gpg

Also note that this article assumes a fresh install of Amanda. If you have an existing Amanda installation, additional steps are needed to ensure the proper upgrade to the latest Amanda release, (2.5.1p2 and later).

TIP: You can copy and paste all of the examples here, making appropriate modifications for your environment.

Order Pizza

Call your favorite pizza delivery place, set your stopwatch and...

Install and Configure the Amanda Backup Server

1. Log in as root on Quartz, the Red Hat Enterprise Linux 4 server.

2. Install the Amanda 2.5.1p2 amanda-backup_server RPM. Installing the package also creates a user named amandabackup who belongs to the group disk.

[root@quartz server]# rpm -ivh amanda-backup_server-2.5.1p2-1.rhel4.i386.rpm

warning: amanda-backup_server-2.5.1p2-1.rhel4.i386.rpm: V3 DSA signature: NOKEY, key ID 3c5d1c92
Preparing...                ########################################### [100%]
Jan 5 2007 12:12:55: Preparing to install: Amanda Community Edition - version 2.5.1p2
Jan 5 2007 12:12:55: Checking for 'amandabackup' user...
Jan 5 2007 12:12:55:
Jan 5 2007 12:12:55: The Amanda backup software is configured to operate as the
Jan 5 2007 12:12:55: user 'amandabackup'. This user exists on your system and has not
Jan 5 2007 12:12:55: been modified. To ensure that Amanda functions properly,
Jan 5 2007 12:12:56: please see that the following parameters are set for that
Jan 5 2007 12:12:56: user.:
Jan 5 2007 12:12:56:
Jan 5 2007 12:12:56: SHELL:          /bin/sh
Jan 5 2007 12:12:56: HOME:           /var/lib/amanda
Jan 5 2007 12:12:56: Default group: disk
Jan 5 2007 12:12:56:
Jan 5 2007 12:12:56: Checking ownership of '/var/lib/amanda'... correct.
Jan 5 2007 12:12:57:
Jan 5 2007 12:12:57: === Amanda backup server installation started. ===

1:amanda-backup_server ########################################### [100%]

Jan 5 2007 12:13:05: Updating system library cache...done.
Jan 5 2007 12:13:21: Installing '/etc/amandates'.
Jan 5 2007 12:13:21: The file '/etc/amandates' has been created.
Jan 5 2007 12:13:21: Ensuring correct permissions for '/etc/amandates'.
Jan 5 2007 12:13:21: '/etc/amandates' Installation successful.
Jan 5 2007 12:13:22: Checking '/var/lib/amanda/.amandahosts' file.
Jan 5 2007 12:13:22: Checking for '/var/lib/amanda/.profile' and ensuring correct environment.
Jan 5 2007 12:13:23: Setting ownership and permissions for '/var/lib/amanda/.profile'
Jan 5 2007 12:13:23: === Amanda backup server installation complete. ===
Amanda installation log can be found in '/var/log/amanda/install.log' and errors (if any) in '/var/log/amanda/install.err'.

3. The Amanda services are started by the extended internet daemon, xinetd, which is why you must have xinetd installed on every Amanda server and client. In any text editor, create one xinetd startup file, /etc/xinetd.d/amandaserver , with content as follows.

For the /etc/xinetd.d/amandaserver file, on Quartz:

# default: on
#
# description: Amanda services for Amanda server and client.
#
service amanda
{
        disable         = no
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = amandabackup
        group           = disk
        groups         = yes
        server          = /usr/lib/amanda/amandad
        server_args     = -auth=bsdtcp amdump amindexd amidxtaped
}

4. Restart xinetd on Quartz.

[root@quartz xinetd.d]# service xinetd reload
Reloading configuration: [ OK ]

5. Note the time. Only about five minutes should have passed!

Install and Configure Three Different Amanda Clients

Installation of Amanda Client RPM on Iron (FC4)

1. Log in as root on Iron, your Fedora Core 4 client.

2. Install the Amanda 2.5.1p2 backup_client RPM. Installing the package also creates a user named amandabackup who belongs to the group disk.

[root@iron client]# rpm -ivh amanda-backup_client-2.5.1p2-1.fc4.i386.rpm
warning: amanda-backup_client-2.5.1p2-1.fc4.i386.rpm: Header V3 DSA signature: NOKEY, key ID 3c5d1c92
Preparing...                ########################################### [100%]
Jan 5 2007 10:17:16: Preparing to install: Amanda Community Edition - version 2.5.1p2
Jan 5 2007 10:17:16: Checking for 'amandabackup' user...
Jan 5 2007 10:17:16:
Jan 5 2007 10:17:16: The Amanda backup software is configured to operate as the
Jan 5 2007 10:17:17: user 'amandabackup'. This user exists on your system and has not
Jan 5 2007 10:17:17: been modified. To ensure that Amanda functions properly,
Jan 5 2007 10:17:17: please see that the following parameters are set for that
Jan 5 2007 10:17:17: user.:
Jan 5 2007 10:17:17:
Jan 5 2007 10:17:17: SHELL:          /bin/sh
Jan 5 2007 10:17:17: HOME:           /var/lib/amanda
Jan 5 2007 10:17:17: Default group: disk
Jan 5 2007 10:17:17:
Jan 5 2007 10:17:17: Checking ownership of '/var/lib/amanda'... correct.
Jan 5 2007 10:17:17:
Jan 5 2007 10:17:17: === Amanda backup client installation started. ===

   1:amanda-backup_client   ########################################### [100%]

Jan 5 2007 10:17:21: Updating system library cache...done.
Jan 5 2007 10:17:30: Checking '/var/lib/amanda/.amandahosts' file.
Jan 5 2007 10:17:31: Checking for '/var/lib/amanda/.profile' and ensuring correct environment.
Jan 5 2007 10:17:31: Setting ownership and permissions for '/var/lib/amanda/.profile'
Jan 5 2007 10:17:31: Checking for '/var/lib/amanda/.profile' and ensuring correct environment.
Jan 5 2007 10:17:31: Setting ownership and permissions for '/var/lib/amanda/.profile'
Jan 5 2007 10:17:31: === Amanda backup client installation complete. ===
Amanda installation log can be found in '/var/log/amanda/install.log' and errors (if any) in '/var/log/amanda/install.err'.

3. In any text editor, create an xinetd startup file, /etc/xinetd.d/amandaclient, with content as follows.

# default: on
#
# description: Amanda services for Amanda client.
#
service amanda
{
        disable         = no
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = amandabackup
        group           = disk
        groups          = yes
        server          = /usr/lib/amanda/amandad
        server_args     = -auth=bsdtcp amdump
}

4. Restart xinetd on Iron.

[root@ironxinetd.d]# service xinetd reload
Reloading configuration: [ OK ]

5. Become the amandabackup user and append the line "quartz.zmanda.com amandabackup amdump" to the /var/lib/amanda/.amandahosts file on Iron. This allows Quartz, the Amanda backup server, to connect to Iron, the Amanda client.

Note that you should use fully qualified domain names when configuring Amanda.

-bash-3.00$ echo quartz.zmanda.com amandabackup amdump >> /var/lib/amanda/.amandahosts
-bash-3.00$ chmod 700 /var/lib/amanda/.amandahosts

6. Save the passphrase as a hidden file in the home directory of the amandabackup user. Protect the file with the proper permissions.

As the user amandabackup:

-sh-3.00$ chown amandabackup:disk ~amandabackup/.am_passphrase
-sh-3.00$ chmod 700 ~amandabackup/.am_passphrase

7. Create a script that enables encryption on the client Iron.

As root create a file /usr/sbin/amcryptsimple:

#!/usr/bin/perl -w
use Time::Local;
my $AMANDA='amandabackup';
$AMANDA_HOME = (getpwnam($AMANDA) )[7] || die "Cannot find $AMANDA home directory\n" ;
$AM_PASS = "$AMANDA_HOME/.am_passphrase";
$ENV{'PATH'} = '/usr/local/bin:/usr/bin:/usr/sbin:/bin:/sbin';
$ENV{'GNUPGHOME'} = "$AMANDA_HOME/.gnupg";
sub encrypt() {
   system "gpg --batch --disable-mdc --symmetric --cipher-algo AES256 --passphrase-fd 3 3<$AM_PASS";}
sub decrypt() {
    system "gpg --batch --quiet --no-mdc-warning --decrypt --passphrase-fd 3 3<$AM_PASS";
}
if ( $#ARGV > 0 ) {
    die "Usage: $0 [-d]\n";
}
if ( $#ARGV==0 && $ARGV[0] eq "-d" ) {
   decrypt();
}
else {
   encrypt();
}

7. Change the owership and the permissions on the file /usr/sbin/amcryptsimple you just created:

[root@iron sbin]# chown amandabackup:disk /usr/sbin/amcryptsimple
[root@iron sbin]# chmod 750 /usr/sbin/amcryptsimple

9. This completes configuration of the Amanda client on Iron.

Installation of Amanda Client RPM on Copper (SLES9)

1. Log in as the root user on Copper, your SUSE Linux Enterprise Server 9 client.

2. Install the Amanda 2.5.1p2 backup_client RPM. Installing the package also creates a user named amandabackup who belongs to the group disk.

copper:/ # rpm -ivh amanda-backup_client-2.5.1p2-1.sles9.i586.rpm
warning: amanda-backup_client-2.5.1p2-1.sles9.i586.rpm: V3 DSA signature: NOKEY, key ID 3c5d1c92

Preparing... ########################################### [100%]

Jan 5 2007 07:20:21: Preparing to install: Amanda Community Edition - version 2.5.1p2
Jan 5 2007 07:20:21: Checking for 'amandabackup' user...
Jan 5 2007 07:20:21:
Jan 5 2007 07:20:21: The Amanda backup software is configured to operate as the
Jan 5 2007 07:20:21: user 'amandabackup'. This user exists on your system and has not
Jan 5 2007 07:20:21: been modified. To ensure that Amanda functions properly,
Jan 5 2007 07:20:21: please see that the following parameters are set for that
Jan 5 2007 07:20:22: user.:
Jan 5 2007 07:20:22:
Jan 5 2007 07:20:22: SHELL:          /bin/sh
Jan 5 2007 07:20:22: HOME:           /var/lib/amanda
Jan 5 2007 07:20:22: Default group: disk
Jan 5 2007 07:20:22:
Jan 5 2007 07:20:22: Checking ownership of '/var/lib/amanda'... correct.
Jan 5 2007 07:20:22:
Jan 5 2007 07:20:22: === Amanda backup client installation started. ===

   1:amanda-backup_client   ########################################### [100%]

Jan 5 2007 07:20:26: Updating system library cache...done.
Jan 5 2007 07:20:26: Checking '/var/lib/amanda/.amandahosts' file.
Jan 5 2007 07:20:27: Checking for '/var/lib/amanda/.profile' and ensuring correct environment.
Jan 5 2007 07:20:27: Setting ownership and permissions for '/var/lib/amanda/.profile'
Jan 5 2007 07:20:27: Checking for '/var/lib/amanda/.profile' and ensuring correct environment.
Jan 5 2007 07:20:27: Setting ownership and permissions for '/var/lib/amanda/.profile'
Jan 5 2007 07:20:27: === Amanda backup client installation complete. ===
Amanda installation log can be found in '/var/log/amanda/install.log' and errors (if any) in '/var/log/amanda/install.err'.

3. In any text editor, create an xinetd startup file, /etc/xinetd.d/amandaclient, with content as follows.

5. Restart xinetd on Copper.

copper:/ # /etc/rc.d/xinetd restart
Reload INET services (xinetd). done

6. Become the amandabackup user and append the line "quartz.zmanda.com amandabackup amdump" to the /var/lib/amanda/.amandahosts file on Copper. This allows Quartz, the Amanda backup server, to connect to Copper, the Amanda client.
Note that you should use fully qualified domain names when configuring Amanda.

-bash-3.00$ echo quartz.zmanda.com amandabackup amdump >> /var/lib/amanda/.amandahosts
-bash-3.00$ chmod 700 /var/lib/amanda/.amandahosts

7. This completes configuration of the Amanda client on Copper. If you check your watch, you should find that only about ten minutes have passed!

Configurations Required to Backup Windows Client Uranium

· Configuration done on backup server Quartz:

1. The file /etc/amandapass must be created manually, owned by the amandabackup user and have permissions of 700. The amandapass file contains share name to user name, password and workgroup mapping.

As the root user:

[root@quartz /]# echo //uranium/MyDocuments zmanda%amanda Workgroup >> /etc/amandapass

2. Change the ownership and permissions on this file:

[root@quartz etc]# chown amandabackup:disk /etc/amandapass
[root@quartz etc]# chmod 700 /etc/amandapass

· Configuration done on Windows client Uranium:

The directory getting backed up must be shared from Windows and must be
accessible by the Windows user zmanda with the password amanda.

Set Backup Parameters

1. On Quartz, as the amandabackup user, create the Amanda configuration directory.

[root@quartz etc]# su - amandabackup
-bash-3.00$ mkdir /etc/amanda/DailySet1

2. Copy the /var/lib/amanda/example/amanda.conf file to the /etc/amanda/DailySet1 directory. The amanda.conf file is the most important file for configuring your Amanda setup.

-bash-3.00$ cp /var/lib/amanda/example/amanda.conf /etc/amanda/DailySet1

3. The sample amanda.conf distributed with Amanda is over 700 lines long and is extensively commented. For more information, search for amanda.conf on the Amanda wiki. We will focus on just a few lines and make minimal modifications.

Open /etc/amanda/DailySet1/amanda.conf with any text editor and edit it to suit your environment.

· The following lines control some details specific to your organization and to your tape configuration.

org "YourCompanyName"                          # your organization name for reports
mailto "root@localhost"                        # space separated list of operators at your site
tpchanger "chg-disk"                           # the tape-changer glue script
tapedev "file://space/vtapes/DailySet1/slots" # the no-rewind tape device to be used
tapetype HARDDISK                              # use hard disk intead of tapes (vtape config)

· We add the following lines to specify the size of the virtual tapes:

define tapetype HARDDISK {
length 100000 mbytes
}

· We add the following lines to support the encrypted backup of /home/pavel on Iron:

define dumptype encrypt-simple {
root-tar
comment "client simple symmetric encryption, dumped with tar"
encrypt client
compress fast
client_encrypt "/usr/sbin/amcryptsimple"
client_decrypt_option "-d"
}

. Go to the “define dumptype global” section in the amanda.conf file and add the “auth "bsdtcp"” line right before the last “}” bracket. This is done to enable “BSDTCP” authentication.

# index yes
# record no
# split_diskbuffer "/raid/amanda"
# fallback_splitsize 64m
auth "bsdtcp"

4. As the root user, create a cache directory to use as a holding disk.

[root@quartz ~]# mkdir -p /dumps/amanda
[root@quartz ~]# chown amandabackup:disk /dumps/amanda
[root@quartz ~]# chmod 750 /dumps/amanda

5. Create the virtual tapes. Dedicated directories are used as “virtual tapes” called vtapes. You work with vtapes in the same way that you work with physical tapes. Vtapes can even simulate tape changers, as you will see in our example.

For security reasons, limit access to the vtapes directory to the amandabackup user.

As the root user:

[root@quartz ~]# mkdir -p /space/vtapes
[root@quartz ~]# chown amandabackup:disk /space/vtapes
[root@quartz ~]# chmod 750 /space/vtapes

As the amandabackup user:

-bash-3.00$ touch /etc/amanda/DailySet1/tapelist
-bash-3.00$ mkdir -p /space/vtapes/DailySet1/slots
-bash-3.00$ cd /space/vtapes/DailySet1/slots
-bash-3.00$ for ((i=1; $i<=25; i++)); do mkdir slot$i;done
-bash-3.00$ ln -s slot1 data

6. Test the virtual tape setup.

-bash-3.00$ ammt -f file:/space/vtapes/DailySet1/slots status
file:/space/vtapes/DailySet1/slots
status: ONLINE

7. Just as with physical tapes, the virtual tapes now need to be labeled. (Please note that the output below has been truncated.)

bash-3.00$ for ((i=1; $i<=9;i++)); do amlabel DailySet1 DailySet1-0$i slot $i; done
changer: got exit: 0 str: 1 file://space/vtapes/DailySet1/slots
labeling tape in slot 1 (file://space/vtapes/DailySet1/slots):
rewinding, reading label, not an amanda tape (Read 0 bytes)
rewinding, writing label DailySet1-01, checking label, done.
...
changer: got exit: 0 str: 9 file://space/vtapes/DailySet1/slots
labeling tape in slot 9 (file://space/vtapes/DailySet1/slots):
rewinding, reading label, not an amanda tape (Read 0 bytes)
rewinding, writing label DailySet1-09, checking label, done.

-bash-3.00$ for ((i=10; $i<=25;i++)); do amlabel DailySet1 DailySet1-$i slot $i; done
changer: got exit: 0 str: 10 file://space/vtapes/DailySet1/slots
labeling tape in slot 10 (file://space/vtapes/DailySet1/slots):
rewinding, reading label, not an amanda tape (Read 0 bytes)
rewinding, writing label DailySet1-10, checking label, done.
...
changer: got exit: 0 str: 25 file://space/vtapes/DailySet1/slots
labeling tape in slot 25 (file://space/vtapes/DailySet1/slots):
rewinding, reading label, not an amanda tape (Read 0 bytes)
rewinding, writing label DailySet1-25, checking label, done.

8. Now we need to reset the virtual tape changer back to the first slot.

-bash-3.00$ amtape DailySet1 reset
changer: got exit: 0 str: 1
amtape: changer is reset, slot 1 is loaded.

9. Create an /etc/amanda/DailySet1/disklist file in the Amanda configuration directory. The disklist contains the fully qualified backup client names, the directory or directories to be backed up and the dumptype.

copper.zmanda.com /var/www/html comp-user-tar
iron.zmanda.com /home/pavel encrypt-simple
quartz.zmanda.com //uranium/MyDocuments comp-user-tar

10. As the user amandabackup, append the following lines to the /var/lib/amanda/.amandahosts file to allow the backup clients to connect back to the server when doing restores. Specify fully qualified domain names.

iron.zmanda.com root amindexd amidxtaped
copper.zmanda.com root amindexd amidxtaped
quartz.zmanda.com root amindexd amidxtaped
quartz.zmanda.com amandabackup admump

11. Create a cron job that will execute amdump and initiate your backups automatically. As the amandabackup user, run crontab -e,and add the following line to run backups Monday through Friday at 1am.

0 1 * * 1-5 /usr/sbin/amdump DailySet1

Verify Your Configuration

1. On Quartz, as amandabackup, run the amcheck tool to verify that you can successfully perform a backup.

-bash-3.00$ amcheck DailySet1
Amanda Tape Server Host Check
-----------------------------
Holding disk /dumps/amanda: 16714488 KB disk space available, using 16612088 KB
slot 1: read label `DailySet1-01', date `X'
NOTE: skipping tape-writable test
Tape DailySet1-01 label ok
NOTE: conf info dir /etc/amanda/DailySet1/curinfo does not exist
NOTE: it will be created on the next run.
NOTE: index dir /etc/amanda/DailySet1/index does not exist
NOTE: it will be created on the next run.
Server check took 4.259 seconds
Amanda Backup Client Hosts Check
--------------------------------
Client check: 3 hosts checked in 27.097 seconds, 0 problems found
(brought to you by Amanda 2.5.1p2)

Run a Backup

1. On Quartz, as amandabackup, run amdump to start the DailySet1 backup.

-bash-3.00$ amdump DailySet1

2. Amanda will email a detailed status report from the amandabackup user to you, the root user on Quartz.

From amandabackup@quartz.zmanda.com Fri Jan 5 13:04:20 2007
Date: Fri, 5 Jan 2007 13:04:19 -0800
From: Amanda user
To: root@quartz.zmanda.com
Subject: YourCompanyName AMANDA MAIL REPORT FOR January 5, 2007

These dumps were to tape DailySet1-02.
The next tape Amanda expects to use is: a new tape.
The next new tape already labelled is: DailySet1-02.

STATISTICS:
Total Full Incr.
-------- -------- --------

Estimate Time (hrs:min)    0:00
Run Time (hrs:min)         0:00
Dump Time (hrs:min)        0:00       0:00       0:00
Output Size (meg)           3.5        3.5        0.0
Original Size (meg)        11.8       11.8        0.0
Avg Compressed Size (%)    29.7       29.7        --
Filesystems Dumped            3          3          0
Avg Dump Rate (k/s)       292.8      292.8        --
Tape Time (hrs:min)        0:00       0:00       0:00
Tape Size (meg)             3.7        3.7        0.0
Tape Used (%)               0.0        0.0        0.0
Filesystems Taped             3          3          0
Chunks Taped                  0          0          0
Avg Tp Write Rate (k/s) 8509.1     8509.1        --

USAGE BY TAPE:

Label Time Size % Nb Nc
DailySet1-02 0:00 3744K 0.0 3 0

NOTES:
planner: Forcing full dump of copper.zmanda.com:/var/www/html as directed.
planner: Forcing full dump of iron.zmanda.com:/home/pavel as directed.
planner: Forcing full dump of quartz.zmanda.com://uranium/MyDocuments as directed.
taper: tape DailySet1-02 kb 3744 fm 3 [OK]

DUMP SUMMARY:
                                       DUMPER STATS               TAPER STATS
HOSTNAME     DISK        L ORIG-KB OUT-KB COMP% MMM:SS   KB/s MMM:SS   KB/s
-------------------------- ------------------------------------- -------------
copper.zmand -r/www/html 0    7640    2336   30.6    0:03 910.6   0:00 8680.7
iron.zmanda. /home/pavel 0    3530    1024   29.0    0:07 149.1   0:00 12486.1
quartz.zmand -yDocuments 0     960     384   40.0    0:03 101.0   0:00 4295.3
(brought to you by Amanda version 2.5.1p2)

3. You can also run the tool amadmin with a find argument for a quick summary of what has been backed up.

-bash-3.00$ amadmin DailySet1 find
Scanning /dumps/amanda...

date                host              disk                  lv tape or file file part status
2007-01-05 13:04:03 copper.zmanda.com /var/www/html          0 DailySet1-02    2   -- OK
2007-01-05 13:04:03 iron.zmanda.com   /home/pavel            0 DailySet1-02    3   -- OK
2007-01-05 13:04:03 quartz.zmanda.com //uranium/MyDocuments 0 DailySet1-02    1   -- OK

Success!

In just about 15 minutes, we installed and configured a secure, heterogeneous network backup, verified our configurations and ran a backup. We did it with freely downloadable open source software that you can install from binaries or compile for your unique needs. The pizza, which should be getting delivered right about now, will be that much more enjoyable with the clear conscience and peace of mind that comes with knowing that your data is secure.

Recovery

Based on feedback received on our forums we are adding a section that shows the ability to do a restore.

1. On Copper, as root, create the "/etc/amanda" directory.

copper:~ # mkdir /etc/amanda

copper:~ # chown amandabackup:disk /etc/amanda

2. As amandabackup, create a file "/etc/amanda/amanda-client.conf" and insert the lines below in to the file.

# amanda.conf - sample Amanda client configuration file.
#
# This file normally goes in /etc/amanda/amanda-client.conf.
#
conf "DailySet1" # your config name

index_server "quartz.zmanda.com" # your amindexd server

tape_server "quartz.zmanda.com" # your amidxtaped server

#tapedev "/dev/null" # your tape device
# auth - authentication scheme to use between server and client.
# Valid values are "bsd", "bsdudp", "bsdtcp" and "ssh".
# Default: [auth "bsdtcp"]

auth "bsdtcp"

# your ssh keys file if you use ssh auth

ssh_keys "/var/lib/amanda/.ssh/id_rsa_amrecover"

3. As root run "amrecover" to initiate the data recovery process.

copper:/etc/amanda # amrecover
AMRECOVER Version 2.5.1p2. Contacting server on quartz.zmanda.com ...
220 quartz AMANDA index server (2.5.1p2) ready.
Setting restore date to today (2007-01-08)
200 Working date set to 2007-01-08.
200 Config set to DailySet1.
501 Host copper is not in your disklist.
Trying host copper.zmanda.com ...
200 Dump host set to copper.zmanda.com.
Use the setdisk command to choose dump disk to recover
amrecover>

4. The list of commands below will demonstrate a recovery of a set of different files and directories to the "/tmp" directory.

amrecover> listdisk
200- List of disk for host copper.zmanda.com
201- /var/www/html
200 List of disk for host copper.zmanda.com
amrecover> setdisk /var/www/html
200 Disk set to /var/www/html.
amrecover> ls
2007-01-05-13-04-03 tar-1.15/
2007-01-05-13-04-03 .
amrecover> cd tar-1.15
/var/www/html/tar-1.15
amrecover> ls
2007-01-05-13-04-03 scripts/
2007-01-05-13-04-03 doc/
2007-01-05-13-04-03 configure
2007-01-05-13-04-03 config/
2007-01-05-13-04-03 COPYING
2007-01-05-13-04-03 AUTHORS
2007-01-05-13-04-03 ABOUT-NLS
amrecover> add scripts/
Added dir /tar-1.15/scripts/ at date 2007-01-05-13-04-03
amrecover> add configure
Added file /tar-1.15/configure
amrecover> add doc/
Added dir /tar-1.15/doc/ at date 2007-01-05-13-04-03
amrecover> lcd /tmp
amrecover> extract
Extracting files using tape drive chg-disk on host quartz.zmanda.com.
The following tapes are needed: DailySet1-02
Restoring files into directory /tmp
Continue [?/Y/n]? y
Extracting files using tape drive chg-disk on host quartz.zmanda.com.
Load tape DailySet1-02 now
Continue [?/Y/n/s/t]? y
./tar-1.15/doc/
./tar-1.15/scripts/
./tar-1.15/configure
./tar-1.15/doc/Makefile.am
./tar-1.15/doc/Makefile.in
./tar-1.15/doc/convtexi.pl
./tar-1.15/doc/fdl.texi
./tar-1.15/doc/freemanuals.texi
./tar-1.15/doc/getdate.texi
./tar-1.15/doc/header.texi
./tar-1.15/doc/stamp-vti
./tar-1.15/doc/tar.info
./tar-1.15/doc/tar.info-1
./tar-1.15/doc/tar.info-2
./tar-1.15/doc/tar.texi
./tar-1.15/doc/version.texi
./tar-1.15/scripts/Makefile.am
./tar-1.15/scripts/Makefile.in
./tar-1.15/scripts/backup-specs
./tar-1.15/scripts/backup.in
./tar-1.15/scripts/backup.sh.in
./tar-1.15/scripts/dump-remind.in
./tar-1.15/scripts/restore.in
amrecover> quit
200 Good bye.

5. We can now verify that the files have been recovered successfully by running run the following command.

For more information about Amanda, please visit http://amanda.zmanda.com.