Backup server (old): Difference between revisions
Paul.bijnens (talk | contribs) (Server-side and Client-side encryption move to a separate page) |
Paul.bijnens (talk | contribs) (Tape hardware compression moved to a separate page) |
||
Line 99: | Line 99: | ||
==Tape hardware compression== | ==Tape hardware compression== | ||
This section has been moved to a separate page. | |||
See: [[Hardware compression]]. | |||
Revision as of 21:45, 15 December 2005
amanda.conf
- dumptypes
- dumpcycle
- estimate timeouts
- Tapetype definitions
disklist
tapelist
Exclude lists
This part has been moved to a separate page. See Exclude and include lists.
Device configuration
Tapetypes
Tapetype definitions are specified in amanda.conf configuration file. The tapetype definition provides AMANDA how much it is supposed to be able to store in a tape (length), how much space is wasted at the end of a dump image with the EOF mark (filemark) and how fast the tape unit is (speed).
The most important parameter is length, since AMANDA may decide to delay a backup if length is too small, but, if it is too large, AMANDA may end up leaving dumps in the holding disk or having to abort some dump.
Filemark is important if you have many disks, particularly with small incremental backups. The space wasted by so many filemarks may add up and considerably modify the available tape space.
The speed is currently unused.
AMANDA provides the amtapetype utility to calculate the size of a tape, to generate a "tapetype" entry for your amanda.conf.
Specifying the appropriate tape device, but beware that it may take many hours to run (it fills the tape twice ...). Make sure you do not use hardware compression, even if you plan to use hardware compression in the future. amtapetype writes random data to tape, and random data will expand instead of compressing, therefore you'll get an estimate that's smaller than expected.
Some tapetype definitions are available here.
Changers
This part has been moved to a separate page.
See Changers.
RAIT
Currently it is only integrated with the chg-manual changer script
RAIT is an acronym for "Redundant Array of Inexpensive Tapes", where data is striped over several tape drives, with one drive writing an exclusive-or-sum of the others which can be used for error recovery. Any one of the data streams can be lost, and the data can still be recovered.
This means that a 3-drive RAIT set will write 2 "data" streams and one "parity" stream, and give you twice the capacity, twice the throughput, and the square of the failure rate (i.e. a 1/100 failure rate becomes 1/10,000, since a double-tape failure is required to lose data).
Similarly, a 5-drive RAIT set will give you 4 times the capacity, 4 times the throughput (with sufficient bus bandwidth), and the square of the failure rate.
This means you can back up partitions as large as four times your tape size with AMANDA, with higher reliability and speed.
Using a RAIT
This section has been moved to a separate section.
See: Rait.
Disaster Recovery
To assist in disaster recovery (as well as changer scripts) the AMANDA package now also includes amdd, which is a simple dd(1) replacement which supports (only) the "if=xxx", "of=xxx", "bs=nnn[kMb]" "skip=nnn" and "count=nnn" options, but which can read and write RAIT tapesets.
Using amdd and your usual AMANDA unpack instructions will suffice for disaster recovery from RAIT tape-sets.
File driver/Disk backups
This section has been moved to a separate page;
See File driver.
Server-side and Client-side encryption
This section has been moved to a separate page.
See Encryption.
Custom Compression
- compress client custom
- Specify client_custom_compress "PROG"
- PROG must not contain white space and it must accept -d for uncompress.
- compress server custom
- Specify server_custom_compress "PROG"
- PROG must not contain white space and it must accept -d for uncompress.
- sample dumptype:
define dumptype custom-tar { global program "GNUTAR" comment "root partitions dumped with custom compression" compress server custom server_custom_compress "/usr/bin/my_gzip" priority low }
- I have tested custom compression using bzip2. Dumps works fine. Amrestore has a glitch on which
the image gets uncompressed correctly and written to a temp file but gets a broken-pipe error. I am investigating the problem.
Tape hardware compression
This section has been moved to a separate page.
See: Hardware compression.