Chris Cruft

Interesting commands:

# su amanda -c “amadmin CCH1 find –sort b”

Show all available backups

# su amanda -c “amstatus CCH1″

Show running/last status

# find /var/log/amanda -type f -mtime +25 -exec rm {} \;

Prune old debug files (>> tapecycle)

# find /var/lib/amanda/CCH1/oldlog/log.* -type f -mtime +25 -exec rm {} \;

Prune old log files (>> tapecycle)

# amreport CCH1 -l /var/lib/amanda/CCH1/log.20060207.0 -f /tmp/t; view /tmp/t

Show status of last run

# su amanda -c “amcheckdb CCH1″

Check tape list against DB

# su amanda -c “amoverview CCH1″

Show summary of recent runs

# su amanda -c “amplot /var/lib/amanda/CCH1/log.*”

Plot summary of runs

# su amanda -c “amtoc -t -f - /var/lib/amanda/CCH1/log.20060208.0″

Show contents of tape run

# su amanda -c “amadmin CCH1 due triumph /home”

Show next level 0 dump

# su amanda -c “amadmin CCH1 disklist triumph /home”

Show config for DLE

# su amanda -c “amadmin CCH1 tape -days 5″

Show next tape required

# su amanda -c “amcheck CCH1″

Show config for DLE

Wow.  This is a more complex subject than it should be.  For starters, there are two kinds of excludes -one an expression defined directly in the amanda configuration file and the other a file on the amanda client holding a list of expressions.  Secondly, all exclude expressions must be relative to the disklist entry.  Thirdly, there is no real way to test the validity of the expressions.

My approach is to define a new dumptype (root) that has an exclude list file.  This dumptype is applied to all root filesystem DLEs.  Here is the exclude file:

Screen clipping taken: 31/01/2006, 16:40

Note that I put the exclude file in the /etc/amanda directory, not in the configuration directory.  My logic is that regardless of which host or configuration is used to perform the backup, these exclusions remain valid.

Lately, the nightly amdump runs have been reporting a strange error:

planner: triumph.hapgoods.com._etc.0: disk triumph.hapgoods.com:/etc not in database, skipping it.

planner: triumph.hapgoods.com._usr.0: disk triumph.hapgoods.com:/usr not in database, skipping it.

I had shuffled my disk space around several months ago and /etc and /usr were no longer being backed up separately -instead they are now backed up with the root filesystem.  But why was amanda constantly reminding me of this fact?

I looked on the web and could find almost no references to this error -and the references I did find showed that most people ignored it.  I was ignoring it as well, until today when I browsed the amanda holding disk and found dumps from several months ago.  Since the autoflush parameters enabled (see section above), I couldn’t understand why these dumps were not getting written to tape.  Then, in a flash of inspiration, it all came together: the dumps on the holding disk were in fact the source of the errors I was getting every night.  I must have forgotten to put the right tape in the night before I changed the disklist entries.  These dumps were written to the holding disk that night.  They next day, after the change to the DLE database, they were no longer valid!  I deleted the dumps, reclaimed some disk space and removed the annoying “planner…” warning.

Realistically, the tools I have available are the free ones. And I’m not very willing to roll my own solution or delve into obscure software with limited community support. So amanda is used for tape backup and rsync is used to manage (in a limited fashion) some offsite backups.

In the Cooperative Multi-Home Network, there are a couple of attributes that represent limitations and opportunities.  To wit:

1. There are multiple sites.
2. The multiple sites cooperate -i.e. security is a secondary concern amongst the homes.
3. The sites are homes, not offices.  This means “operations” run until late at night and  hardware and bandwidth costs are limiting factors.

So the environment that we have is:

1. Tape backup units at each site
2. Limited bandwidth between sites (over a VPN tunnel).
3. Limited disk space at each site
4. Less-than-professional/dedicated users at each site.
5. Desire for strong backup, including local disaster recoverability.

What I would like to have is a backup system that

1. stores traditional file-based backups on the local tape backup device
2. uses the Tower of Hanoi rotation algorithm (to minimize tape movements and introduce some fault-tolerance to tape failures).
3. uses an algorithm similar to rsync to push a minimal set of blocks to a remote backup server.
4. on the remote server, does not keep a normal mirror image of the protected file system (like rsync would), but rather a heavily compressed version of the file system.  Or, even better, an appropriate hash of the files to support the next rsync comparison.

For the local backup, amanda does a reasonable job.  It adapts well to the addition of new datasets (DLEs) and balances the daily backup load very smoothly.  And its disk buffer (holding disk) is great for when the operator forgets to changes tapes.  But I wish it were more flexible with the tape rotation scheme -it uses a custom tape rotation scheme that is strictly cyclical.  Unfortunately, this means that every tape is used at the same frequency and thus:

1. Tapes are likely to fail at about the same time
2. There is no infrequently used tape that is suitable for off-site storage

I also don’t like the fact that it can’t append to a tape, and consequently refuses to use a tape (with perhaps lots of free space) if it is not the scheduled tape.

This category describes some of the software and hardware peculiarities of Compaq ProLiants -especially the three that I have.

References:

The Boot Process: http://openskills.info/topic.php?ID=11

Linux on Compaq: http://www.riedmann.it/linux/linux-proliant.htm

http://www.hyper-linux.org/HP-HOWTO/current/hp-hardware.html

ALL Compaq Stuff

http://www.cpqlinux.com/

Superb details

Efficient offsite backup with open-source tools is one of the more obvious objectives of my CMHN.  I still don’t have a great solution.  Rsync is nice but requires a big investment in disk space -too bad it can’t practically write to a compressed volume.  And all the backup systems seem to grab all the bandwidth they can rendering the limited ISP connection nearly worthless for normal work.  Plus the paradigm of backing up everything periodically just seems too challenging for the remote model.  I think a combination of rsync-like differential technology plus a direct-to-tape writing method (with an intermediate disk buffer to try to keep the tape drive running) would be ideal.

References:

http://www.linuxquestions.org/linux/answers/Jeremys_Magazine_Articles/Quick_and_Dirty_Backups

http://blog.gmane.org/gmane.comp.archivers.amanda.user/day=20050607