Netzwerkweite Datensicherung mit Amanda -- Einsatz von Festplatten statt Bändern

Stark fallende Preise und riesige Kapazitäten gerade bei Festplatten im günstigen ATA-Bereich lassen immer öfter die Frage aufkommen, warum man nicht statt wie bisher auf Band gleich auf eine Festplatte sichern sollte.

Sofern man Festplatten als Sicherungsmedium nicht als Wechselplatte einsetzt, ist die Platte in der Regel immer Online. Man kann die Festplatte zwar ein einem System unterbringen, das räumlich getrennt (mindestens ein anderer Brandabschnitt) vom Fileserver steht, allerdings bleibt die Gefährdung durch Überspannungen. Ein „Offline“-Sicherungsmedium wie ein Band, sicher verwahrt in einem feuerfesten Tresor in räumlicher Entfernung vom Fileserver bietet eine wesentlich höhere Sicherheit.

Gegen technisches Versagen (Ausfall der Festplatte) kann und sollte man RAID einsetzen. Um eine Historie der Datensicherung bereit zu stellen, sind entsprechende Kapazitäten erforderlich. Beispiel: eine durchschnittliche Datensicherung benötigt 20 GByte, es sollen 10 Versionen vorgehalten werden, dann sind 200 GByte Gesamtkapzität notwendig. Achtung: Bei Online-Systemen, bei denen die Historie in Verzeichnissen eines einzigen RAID-Systemes untergebracht wird, besteht allerdings die Gefahr, durch eine Fehlbedienung (menschliches Versagen) gleich alle Versionen der Sicherung zu zerstören.

Im Prinzip kann man Festplatten auch als Offline-Medien einsetzen. Sofern die Technologie Hotplugging erlaubt und der Server entsprechend ausgestattet ist, lassen sich auch Festplatten wie andere Wechselmedien nur zur Sicherung einlegen und nach der Sicherung offline in einem feuerfesten Tresor verwahren. Allerdings muß man berücksichtigen, daß die Lebensdauer der Festplatte durch unregelmäßiges Einschalten und den Transport beeinträchtigt werden kann.

Macht man sich die Besonderheiten einer Sicherung auf Festplatte bewußt, ist es abhängig von Sicherheitsanforderungen und Budget in verschiedenen Fällen durchaus sinnvoll und möglich, eine Sicherung auf Festplatte vorzunehmen.

Die nachstehende Graphik zeigt schematisch den Grad der Datensicherheit abhängig von der eingesetzten Sicherungsvariante.

Verzeichnisstruktur für Konfiguration, Datenbank und Holding Disk:

/etc/amanda/std           # Konfiguration
/data/amandadump/std      # Holding Disk
/var/lib/amanda/std/log   # Logfiles
/var/lib/amanda/std/info  # Info-Datenbank
/var/lib/amanda/std/index # Indexverwaltung      

Der File-Output-Treiber schreibt in ein Verzeichnis, in unserem Beispiel simuliert Amanda einen Tape-Changer über eine Verzeichnisstruktur, mehrere Sicherungsmedien werden als Slots in Form von Unterverzeichnissen dargestellt.

Benötigt wird eine ausreichend große Festplatte, besser ein RAID-System. Angenommen, eine Vollsicherung aller Clients ist ca. 20 GByte groß, es sollen 5 Versionen der Sicherung vorgehalten werden, dann sollte der zur Verfügung stehende Plattenplatz mindestens 100 GByte betragen (beim Einsatz von Wechselfestplatten eben mindestens 20 GByte je Wechselplatte).

Die Verzeichnisstruktur für die Sicherung ist:

/data/vtapes/std        # Hauptverzeichnis
/data/vtapes/std/info   # Info-Datei
/data/vtapes/std/slot1  # erstes virtuelles Tape (Verzeichnis)
...
/data/vtapes/std/slotn  # letztes virtuelles Tape
/data/vtapes/std/data   # Symlink auf aktuelles virtuelles Tape      

Bei 5 Sicherungen kommen die Verzeichnisse slot1 ... slot5 zum Einsatz. Der Symlink „data“ zeigt jeweils auf das aktuelle Verzeichnis, er wird vom Changer-Mechanismus (zum Einsatz kommt das Skript „chg-disk“) entsprechend umgesetzt. Bei einer Offline-Sicherung auf Wechselfestplatten kann man die jeweilige Sicherungsplatte auch direkt unter „data“ mounten.

Alle Verzeichnisse, ob Konfiguration, Datenbank, Holding Disk oder Sicherungsdisk müssen für den Amanda-User schreibbar sein („backup“ bei Debian, „amanda“ bei SuSE). Die Verzeichnisse, die Daten enthalten (Holding Disk, Sicherungsdisk), sollten natürlich nur für den Amanda-User lesbar sein!

Das eigentliche Konfigurationsfile heißt immer „amanda.conf“ und liegt im Konfigurationsverzeichnis des Sicherungslaufes, hier „/etc/amanda/std“.

#
# /etc/amanda/std/amanda.conf
# 
org "std"
#
mailto "wob@swobspace.de"
tapedev "file:/data/vtapes/std"
labelstr "^std-[0-9]+$"
tapetype HARDDISK
tpchanger "chg-disk"
changerfile "/etc/amanda/std/changer"
#
diskfile "disklist"
infofile "/var/lib/amanda/std/info"
indexdir "/var/lib/amanda/std/index" 
logdir "/var/lib/amanda/std/log"
tapelist "tapelist"
#
dumpcycle    7
runspercycle 5
tapecycle    5
#
define dumptype normal {
        comment "Normal backup"
        program  "GNUTAR"
        compress server fast
        index yes
}
#
define tapetype HARDDISK {
        comment "Dump to disk (vtape)"
        length 20000 mbytes
} 
#
define interface eth0 {
    comment "100 Mbps ethernet"
    use 800 kbps
}
#
holdingdisk hd1 {
    comment   "main holding disk"
    directory "/data/amandadump/std"
    use -4 Gb     
    chunksize 1Gb
}
#
reserve 50      

Die Parameter im Einzelnen: „org“ ist ein Bezeichner, der unter anderem in den Infomails verwendet wird. Sinnvollerweise ist dieser identisch mit dem Namen des Sicherunglaufes. Die Mails, die Amanda versendet, gehen an „mailto“. Um eine Verwechslung der Sicherungsmedien zu verhindern, kann der Label, den das Medium erhält, eingeschränkt werden. Mit „labelstr“ wird ein Pattern festgelegt, das die erlaubten Labels beschreibt.

„tapedev“ gibt den Output-Treiber und das Output-Device an, hier soll der File-Treiber verwendet werden, das Verzeichnis „/data/vtapes/std“ beschreibt das Rootverzeichnis der virtuellen Tapes. „tapetype“ gibt den Typ an, unter „define tapetype“ sind die Parameter zu finden, außer einem Kommentar wird dort nur die Angabe der maximalen zur Verfügung stehenden Größe an Sicherungskapazität je Lauf angegeben. „tpchanger“ beschreibt das Changer-Skript, hier wurde das bei Amanda mitgelieferte Skript „chg-disk“ verwendet. Das Skript sorgt für den Wechsel der virtuellen Tapes (u.a. Umsetzen des Symlinks). „changerfile“ ist ein Prefix für Parameter, die das Changer-Skript sich merkt.

Hinter „diskfile“verbirgt sich eine Datei, die beschreibt, was wie gesichert werden soll. Wir gehen gleich noch näher darauf ein. „tapelist“ beinhaltet die für den Sicherungslauf bekannten Bänder (werden beim Labeln dort eingetragen). Die Datei muß existieren (anlegen mit „touch tapelist“) und für den Amanda-User schreibbar sein.

Wie oft gesichert werden soll, beschreibt „dumpcycle“. Hier ist das Intervall 7 Tage, alle 7 Tage wird mindestens eine Vollsicherung gefahren. „runspercyle“ gibt an, daß je dumpcycle nur 5 Läufe stattfinden (Intervall ist eine Woche, die Sicherung findet aber nur werktags statt). „tapecycle“ beschreibt die Anzahl der verfügbaren Medien. Wurden „tapecyle“ Medien benutzt, darf das erste Medium wieder überschrieben werden.

„define dumptype“ definiert Parameter für die Sicherung. Hier wird GNU-Tar verwendet (statt DUMP für dump), die Kompression soll erst am Server statfinden, die Indexverwaltung für gezieltes Recovery wird eingeschaltet.

Mit „define interface“ wird ein logisches Interface beschrieben, das eigentlich nichts mit dem physikalischen Interface zu tun hat. Die Bandbreite benutzt Amanda nur für eine Kalkulation, ob weitere Clients parallel angesprochen werden können oder ob eine weitere, parallele Sicherung eines Clients aufgrund einer Bandbreitenüberschreitung zurückgestellt wird. Eine echte Beschränkung als Obergrenze für die maximal verwendbare Bandbreite ist gibt es jedoch nicht.

Der „holding disk“ Parameter enthält das Verzeichnis und eine Angabe, wieviel Platz dort verwendet werden darf, hier ist das alles bis auf 4 GByte. Schließlich gibt der Parameter „reserve“ an, daß 50% der Holding Disk für inkrementelle Backups reserviert sind. Ist das Sicherungsmedium nicht verfügbar, schaltet Amanda automatisch auf inkrementelle Backups um, falls nicht mehr ausreichend Platz in der Holding Disk zur Verfügung steht, auch wenn eigentlich ein Vollbackup gefahren werden müßte.

#
# /etc/amanda/std/disklist
#
# host disk dumptype spindle interface
client1 /      normal  -1  eth0
client1 /usr   normal  -1  eth0
client1 /var   normal  -1  eth0
client1 /data  normal  -1  eth0
#
client2 /data  normal  -1  eth0
#
client3 /data  normal  -1  eth0        

amanda dgram udp wait backup /usr/lib/amanda/amandad amandad
amandaidx stream tcp nowait backup \
   /usr/lib/amanda/amindexd amindexd
amidxtape stream tcp nowait backup \
   /usr/lib/amanda/amidxtaped amidxtaped        

Sind alle notwendigen Verzeichnisse und die beiden Konfigurationsdateien („amanda.conf“ und „disklist“) angelegt, müssen die virtuellen Tapes (die Unterverzeichnisse mit dem Namen slot1 .. slot5 „gelabelt“ werden:

% amlabel std std-001 slot 1
% amlabel std std-002 slot 2
% amlabel std std-003 slot 3
% amlabel std std-004 slot 4
% amlabel std std-005 slot 5      

„std“ ist die Bezeichnung des Sicherungslaufes, alle Amanda-Kommandos benötigen diese Angabe, um die korrekte Konfigurationsdateien und Datenbankverzeichnisse referenzieren zu können. „std-001“ ist ein Label gemäß der Pattern-Spezifikation „labelstr“. Da ein Tape-Changer simuliert wird, folgt zusätzlich die Angabe der Slot-Nummer.

Vor der eigentlichen Sicherung testet man die Konfiguration mit dem Programm amcheck. Später kann man das Programm per cron während der Bürozeiten vor einer Sicherung laufen lassen, um gegebenenfalls auftretende Problem noch vor Dienstschluß (und vor der automatischen Sicherung) beheben zu können. Hier eine Beispielausgabe für eine korrekte Funktionsweise:

% amcheck std
Amanda Tape Server Host Check
-----------------------------
Holding disk /data/amandadump/std: 36215420 KB disk space available, using 32021116 KB
amcheck-server: slot 2: date 20040425 label std-002 (active tape)
amcheck-server: slot 3: date X        label std-003 (new tape)
NOTE: skipping tape-writable test
Tape std-003 label ok
Server check took 0.550 seconds

Amanda Backup Client Hosts Check
--------------------------------
Client check: 1 host checked in 10.195 seconds, 0 problems found
(brought to you by Amanda 2.4.5b1-20040423)      

Hier verweist im Moment noch der Symlink data auf slot2 (das vtape std-002), amcheck (oder auch ein Aufruf von amdump) korrigiert das sofort. Ein zweiter Aufruf zeigt dann nur noch die Zeile mit std-003, auf das letztenendes hier gesichert wird.

Die Sicherung selbst erfolgt mit amdump:

% amdump std      

Die Angabe des Sicherungslaufes (hier „std“) ist zwingend erforderlich. Nach erfolgter Sicherung sendet Amanda eine Mail mit Infos und der Zusammenfassung an die Mailadresse unter „mailto“.

Für die Rücksicherung gibt es zwei Programme:

AMRECOVER Version 2.4.5b1-20040423. Contacting server on localhost ...
220 swobspace AMANDA index server (2.4.5b1-20040423) ready.
200 Access OK
Setting restore date to today (2004-04-28)
200 Working date set to 2004-04-28.
Scanning /data/amandadump/std...
  20040427220022: found Amanda directory.
200 Config set to std.
200 Dump host set to swobspace.
Trying disk /var ...
$CWD '/var/restore' is on disk '/var' mounted at '/var'.
200 Disk set to /var.
Invalid directory - /var/restore        

200 Disk set to /.
amrecover> cd /etc/
/etc        

Added dir /etc/amanda at date 2004-04-25        

Extracting files using tape drive file:/data/amvtape/std on host localhost.
The following tapes are needed: std-002        

% cd /etc/amanda/std
% /usr/lib/amanda/chg-disk -slot 2        

Restoring files into directory /var/restore        

Extracting files using tape drive file:/data/amvtape/std on host localhost.
Load tape std-002 now        

/var/restore/etc/amanda        

Die kurze Darstellung von Amanda kann natürlich nicht auf alle Aspekte eingehen. Folgende Quellenhinweise sollten weitere, nützliche Informationen im Umgang mit Amanda liefern: