Backup server (old): Difference between revisions

From wiki.zmanda.com
Jump to navigation Jump to search
(Server-side and Client-side encryption move to a separate page)
Line 68: Line 68:


==Server-side and Client-side encryption==
==Server-side and Client-side encryption==
*a new dumptype option, encrypt is added.
*specify either client or server side in the dumptype (not both):
**encrypt client or encrypt server
*specify client side encryption program:
**client_encrypt  "your encryption program"
***a sample encryption/decryption program amcrypt is provided. amcrypt is a wrapper of aespipe.
***espipe supports AES128, AES192 and AES256 and it uses SHA-256, SHA-384 and SHA-512 respectively.
***any encryption/decryption program can be used as long as it reads from stdin and writes to stdout.
**client_decrypt_option "decrypt parameter" #default to -d
*specify server side encryption program:
**server_encrypt "your encryption program"
***can use amcrypt as in the case of client encryption.
**server_decrypt_option "decrypt parameter" #default to -d


* The logic assumes compression then encryption during backup(thus decrypt then uncompress during restore). Specifying client-encryption and  server-compression is not supported
This section has been moved to a separate page.


* dumptype sample:
See [[Encryption]].
define dumptype custom-tar {
      global
      program "GNUTAR"
      comment "root partitions dumped with encryption"
      compress client fast
      encrypt  server
      server_encrypt "/usr/local/sbin/amcrypt"
      server_decrypt_option "-d"
      index
      priority low
}
* The code is partially based on Matthieu Lochegnies's custom compress patch and Stefan G. Weichinger's amgtar script.
* Code has been commited to the sourceforge CVS, rpm can be downloaded from http://www.zmanda.com/downloads.html
 
===Additional packages needed===
* aespipe http://loop-aes.sourceforge.net/aespipe/aespipe-v2.3b.tar.bz2 and the bz2aespipe-wrapper that comes with it. It gets patched as described later.
* the wrapper-script amcrypt, as listed below,
* GNU-PG http://www.gnupg.org/(en)/download/index.html. This should be part of most current operating systems already.
 
===Setup===
 
* Configure and compile aespipe:
 
tar -xjf aespipe-v2.3b.tar.bz2
cd aespipe-v2.3b
./configure
make
make install
 
* Generate and store the gpg-key for the AMANDA-user:
 
# taken from the aespipe-README
head -c 2925 /dev/random | uuencode -m - | head -n 66 | tail -n 65 | \
gpg --symmetric -a > ~amanda/.gnupg/am_key.gpg
 
*This will ask for a passphrase. Remember this passphrase as you will need it in the next step.
Store the passphrase inside the home-directory of the AMANDA-user and protect it with proper permissions:
 
echo my_secret_passphrase > ~amanda/.am_passphrase
chown amanda:disk ~amanda/.am_passphrase
chmod 700 ~amanda/.am_passphrase
 
*We need this file because we don't want to have to enter the passphrase manually everytime we run amdump. We have to patch bz2aespipe to read the passphrase from a file. I have called that file ~amanda/.am_passphrase.
 
*Store the key and the passphrase in some other place as well, without these information you can't access any tapes that have been encrypted with it (this is exactly why we are doing all this, isn't it? ;) ).
 
* create amcrypt(or it will available in sourceforge and the rpms) as below:
#!/bin/sh
#
# Original wrapper by Paul Bijnens
#
# worked by Stefan G. Weichinger
# to enable gpg-encrypted dumps via aespipe
# also worked by Matthieu Lochegnies for server-side encryption
prefix=/usr/local
exec_prefix=${prefix}
sbindir=${exec_prefix}/sbin
AMANDA_HOME=~amanda
AM_AESPIPE=${exec_prefix}/sbin/amaespipe
AM_PASSPHRASE=$AMANDA_HOME/.am_passphrase
$AM_AESPIPE "$@" 3< $AM_PASSPHRASE
rc=$?
exit $rc
 
 
* create amaespipe(or it will available in sourceforge and the rpms) which is based on wrapper-script bz2aespipe, which comes with the aespipe-tarball:
#! /bin/sh
# FILE FORMAT
# 10 bytes: constant string 'bz2aespipe'
# 10 bytes: itercountk digits
# 1 byte: '0' = AES128, '1' = AES192, '2' = AES256
# 1 byte: '0' = SHA256, '1' = SHA384, '2' = SHA512, '3' = RMD160
# 24 bytes: random seed string
# remaining bytes are bzip2 compressed and aespipe encrypted
# These definitions are only used when encrypting.
# Decryption will autodetect these definitions from archive.
ENCRYPTION=AES256
HASHFUNC=SHA256
ITERCOUNTK=100
AMANDA_HOME=~amanda
WAITSECONDS=1
GPGKEY=""$AMANDA_HOME/.gnupg/am_key.gpg"
FDNUMBER=3
PATH=/usr/bin:/usr/local/bin
export PATH
if test x$1 = x-d ; then
    # decrypt
    n=`head -c 10 - | tr -d -c 0-9a-zA-Z`
    if test x${n} != xbz2aespipe ; then
        echo "bz2aespipe: wrong magic - aborted" >/dev/tty
        exit 1
    fi
    itercountk=`head -c 10 - | tr -d -c 0-9`
    if test x${itercountk} = x ; then itercountk=0; fi
    n=`head -c 1 - | tr -d -c 0-9`
    encryption=AES128
    if test x${n} = x1 ; then encryption=AES192; fi
    if test x${n} = x2 ; then encryption=AES256; fi
    n=`head -c 1 - | tr -d -c 0-9`
    hashfunc=SHA256
    if test x${n} = x1 ; then hashfunc=SHA384; fi
    if test x${n} = x2 ; then hashfunc=SHA512; fi
    if test x${n} = x3 ; then hashfunc=RMD160; fi
    seedstr=`head -c 24 - | tr -d -c 0-9a-zA-Z+/`
    aespipe -K ${GPGKEY} -p ${FDNUMBER} -e ${encryption} -H ${hashfunc} -S ${seedstr} -C ${itercountk} -d
else
    # encrypt
    echo -n bz2aespipe
    echo ${ITERCOUNTK} | awk '{printf "%10u", $1;}'
    n=`echo ${ENCRYPTION} | tr -d -c 0-9`
    aesstr=0
    if test x${n} = x192 ; then aesstr=1; fi
    if test x${n} = x256 ; then aesstr=2; fi
    n=`echo ${HASHFUNC} | tr -d -c 0-9`
    hashstr=0
    if test x${n} = x384 ; then hashstr=1; fi
    if test x${n} = x512 ; then hashstr=2; fi
    if test x${n} = x160 ; then hashstr=3; fi
    seedstr=`head -c 18 /dev/urandom | uuencode -m - | head -n 2 | tail -n 1`
    echo -n ${aesstr}${hashstr}${seedstr}
    aespipe -K ${GPGKEY} -p ${FDNUMBER} -e ${ENCRYPTION} -H ${HASHFUNC} -S ${seedstr} -C ${ITERCOUNTK} -w ${WAITSECONDS}
fi
exit 0
 
 
 
Changes from bz2aespipe:
* Decreased WAITSECONDS: No need to wait for 10 seconds to read the passphrase.
* Removed bzip2 from the pipes: AMANDA triggers GNU-zip-compression by itself, no need to do this twice (slows down things, blows up size).
* Added options -K and -p: This enables aespipe to use the generated gpg-key and tells it the number of the file-descriptor to read the passphrase from.
   
You may set various parameters inside bz2aespipe. You may also call bz2aespipe with various command-line-parameter to choose
the encryption-algorithm, hash-function etc. . For a start I have chosen to call bz2aespipe without command-line-options.
 
===Plans===
 
There are several TODO:
 
*test to see if aespipe can be replaced by gpg.
*test to see if public-key encryption works.


==Custom Compression==
==Custom Compression==

Revision as of 21:42, 15 December 2005

amanda.conf

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

There are multiple methods to set (turn off) hardware compression.

  • Using stinit command: stinit(8) command initializes the SCSI tape drives at the system startup by sending driver ioctl commands. Use "comp" field in /etc/stinit.def configuration file to configure hardware compression for each type of tape.
  • Use mt(1) command to turn off hardware compression at boot time. For example:
# mt -f /dev/st0 compression 0
Please note that compression information is not stored on the tapes ident header block until the tape has been written to.

Procedure for turning off compression and labelling tapes

  • Label the tape
  • Rewind the tape
  • Read the label to a file using dd command
  • Turn off tape compression using mt(1) command. See above.
  • Re-write the label block and write more /dev/zero blocks to flush its buffers.