© suze, photocase.com

Eine Herstellerumfrage soll herausfinden, wie Admins typischer KMU-Umgebungen rotierende Backups so organisieren können, dass sie selbst in den normalen Prozess nicht eingreifen müssen.

Moderne Netzwerkbackup-Programme lassen sich nicht mehr intuitiv bedienen – zu vielfältig sind die Konfigurationsmöglichkeiten. Das Linux-Magazin hat darum die Hersteller und Projekte wichtiger Programme befragt, wie ein Setup für zum Beispiel eine Büroumgebung aussehen müsste, bei dem – einmal eingerichtet – der Admin keine Routineaufgaben mehr erledigen muss.

Die Vorgaben waren: wöchentliches Vollbackup, täglich ein inkrementelles, Backupmedium soll ein NAS sein, angesprochen per NFS oder Samba. Die Software soll automatisch alte Sicherungen herausrotieren, sodass das Zielmedium nicht vollläuft. Hier die Antworten.

Amanda

Die freie Backupsoftware Amanda [1] sichert normalerweise auf ein Bandlaufwerk. Für die geforderte Aufgabe würde ich das NAS per NFS am Backupserver anbinden und darauf anhand von [2] so genannte Virtual Tapes anlegen. Es entsteht eine virtuelle Bandbibliothek, deren Bänder Verzeichnisse auf dem NAS sind; »tpchanger “chg-disk:/Pfad_zu_Vtapes“« bindet den virtuellen Changer in die Amanda-Config ein.

Zum Beispiel »amtape« macht es möglich, solche Bänder in den Changer einzulegen oder sie zu wechseln. Entsprechend eingestellt erledigt Amanda das automatisch passend zum geforderten Tape, was tägliche Eingriffe unnötig macht. Da ich die Größe der Bänder selbst definiere, kann ich leicht beeinflussen, wie viel Platz Backups maximal belegen, ich baue einfach zehn Bänder à 100 GByte.

Beim Thema Vollbackup unterscheidet sich Amandas Philosophie [3] von den klassischen Backup-Schemata. Ich definiere darum beispielsweise:

• Es gibt »$tapecycle« Bänder.
• Mein »$dumpcycle« ist »7 days« .
• In dieser Zeit führe ich an den Werktagen »$runspercycle« Sicherungsläufe aus.

Das heißt, dass Amanda versucht von jeder DLE (Disk List Entry) innerhalb des »$dumpcycle« zumindest eine Vollsicherung zu machen. Eine DLE entspricht vielleicht einem Verzeichnis oder einer Partition, die ich sichern will und in die Amanda-Diskliste eintrage.

An welchem der Wochentage Amanda die Vollsicherung anfertigt, ist nicht definiert. Ein Algorithmus bestimmt den Zeitpunkt dynamisch. Ein Estimate-Lauf prüft vorab, wie voll die zu sichernden Verzeichnisse sind und wann welche zuletzt full-gesichert wurden. Aus dem Ergebnis der Prüfung und aus meinen Vorgaben kalkuliert Amanda den Schedule für heute. Ziele sind eine ungefähr gleichbleibende Bandfüllung zu erreichen, eine vorhersehbare Backupdauer und die gestellten Aufgaben zu erfüllen.

Mit »amadmin Config force DLE« darf ich jedoch dem Scheduler mitteilen: “Ich wünsche beim nächsten Lauf ein Full Backup dieser DLE.” Wenn alle meine DLEs auf ein einzelnes virtuelles Tape passen, würde in einem Freitags-Cronjob »amadmin daily force myserver« für alle DLEs ein Level-0-Backup erzwingen.

Da ich mit Amanda aber keinen einzelnen Tag mit Vollsicherung aller DLEs haben muss, darf die Summe der DLEs größer sein als ein Medium. Sofern ich ausreichend Medien in meiner Rotation habe, verteilt der Algorithmus die Backups über meine Tapes: Das Full Backup von »DLE1« landet vielleicht auf Band 12, das von »DLE2« auf Band 08. Ich sichere also mit relativ vielen und relativ kleinen Medien größere Datenmengen.

Für das vorgegebene NAS-Szenario ist das unproblematisch, weil ja alle Bänder auf ein und demselben NAS liegen und nicht “entnommen” werden. Listing 1 benutzt zehn Tapes auf dem NAS. Zwei Cronjobs würden es täglich starten:

# Morgendlicher Prüflauf, optional
0 9 * * 1-5 /usr/sbin/amcheck -m daily
# abends das Backup
00 22 * * 1-5 /usr/sbin/amdump daily

Nach einer Einlaufphase von zirka ein bis zwei »$dumpcycle« dürfte der Algorithmus die DLEs ausbalanciert haben. Das lässt sich zum Beispiel per »amadmin daily balance« sichtbar machen.

01 dumpcycle 7     #
02 runspercycle 5  # an 7 Tagen in der Woche läuft eine Sicherung
03 tapecycle 10    # 10 Bänder in meinem Changer
04 tapetype HARD-DISK
05 tpchanger "chg-disk:/Pfad_zu_Vtapes"  # laut Link angelegt
06
07 define tapetype HARD-DISK {
08     comment "Dump onto hard disk"
09     length 100 gb
10 }

Stefan G. Weichinger hat die auf Backupsoftware spezialisierte Firma Oops! [4] gegründet und ist seit Anfang 2004 Mitglied des Amanda-Core-Teams.

Arkeia

Das als Softwareversion, physikalische oder virtuelle Appliance verfügbare Arkeia [5] lässt sich einfach über einen Webbrowser administrieren. Per E-Mailing informiert es über den Verlauf der Backups. Einmal eingerichtet, erstellt und verwaltet Arkeia vollautomatisch volle, inkrementelle oder differenzielle Backups. Die Lebensdauer der Backupsets bestimmt der Benutzer selbst. Ist eines abgelaufen, entfernt es die Software aus der Datenbank. Die Backups finden – einmal eingerichtet – also automatisch über Jahre hinweg statt.

Arkeia sichert auf vom Backupserver erreichbare Storages (NAS, Shares oder lokale Platten) oder Bandlaufwerke. Daten lassen sich auch erst auf Disk und dann auf Tape oder Cloud speichern (D2D2T/D2D2C). Ein Restore einzelner Dateien, Verzeichnisse oder ganzer Backups passiert wieder über einen Browser und läuft dann automatisch ab.

Karsten Ehmann ist Regional Manager bei Arkeia Software und verfügt über Linux-Kenntnisse und mehr als zehn Jahre Erfahrung mit Speicher-Anwendungen.

Bacula

Für die gestellte Aufgabe kann ich Bacula [6] empfehlen, weil Sicherungsintervall und -level schon sinnvoll vorkonfiguriert sind: Montag bis Samstag inkrementell, erster Sonntag im Monat Vollsicherung und die übrigen Sonntage differenziell. Das muss ich nur leicht abändern. Um Bacula anzuweisen, auf ein NAS zu schreiben, mounte ich das entfernte Verzeichnis per NFS und gebe es als Sicherungsverzeichnis in der »bacula-sd.conf« an. Wer die volle Kontrolle über das NAS hat, kann sogar auf diesem Baculas Storage-Daemon »bacula-sd« installieren.

Das in Listing 2 gezeigte Setup habe ich zusammen mit Philipp Storz entworfen, dem Autor des demnächst erscheinenden “Bacula”-Buches [7]. Es definiert die Pools »daily« und »weekly« , die kombiniert höchstens 15 Archivdateien (bei Bacula “Volumes”) mit je 100 GByte Größe entstehen lassen. Nach und nach überschreibt Bacula ältere Volumes.

01 # Weekly Pool definition
02 Pool {
03   Name = weekly
04   Label Format = "weekly-"
05   Pool Type = Backup
06   Recycle = yes
07   AutoPrune = yes
08   Volume Retention = 14 weeks     # Wer weniger Puffer zur Sicherheit haben möchte, kann die Vorhaltezeit der Vollsicherungen erhöhen.
09   Maximum Volume Bytes = 100 GB
10 #  Maximum Volumes = 15           # Ist nicht unbedingt notwendig, da Volume Retention ausreicht. Mit Maximum Volumes muss man u.U. sogar häufiger manuell eingreifen.
11   Volume Use Duration = 23 hours
12 }
13
14 # Daily Pool definition
15 Pool {
16   Name = daily
17   Label Format = "daily-"
18   Pool Type = Backup
19   Recycle = yes
20   AutoPrune = yes
21   Volume Retention = 31 days     # gleiches wie oben
22   Maximum Volume Bytes = 1 GB
23 #  Maximum Volumes = 32          # gleiches wie oben
24   Volume Use Duration = 23 hours
25 }
26
27 # Im Schedule Differential auskommentieren:
28 Schedule {
29   Name = "WeeklyCycle"
30   Run = Full sun at 23:05
31 #  Run = Differential 2nd-5th sun at 23:05
32   Run = Incremental mon-sat at 23:05
33 }
34
35 # Standardmäßig soll Bacula das Pool daily nutzen, Vollsicherungen sollen im Full Pool "weekly" landen:
36 JobDefs {
37   Name = "DefaultJob"
38   Type = Backup
39   Level = Incremental
40   Client = course-fd
41   FileSet = "Full Set"
42   Schedule = "WeeklyCycle"
43   Storage = File
44   Messages = Standard
45   Full Backup Pool = weekly
46   Incremental Backup Pool = daily
47   Pool = daily
48   Priority = 10
49   Write Bootstrap = "/home/course/bacula/working/%c.bsr"
50 }

Noch zwei Tipps: In der Clientkonfiguration empfiehlt sich »Auto Prune« auf »no« zu setzen. Dies vermeidet, dass Bacula Datei-Informationen nach 30 Tagen aus seinem Katalog entfernt. Eine gute Idee ist es auch, sich die Bootstrap-Datei der Katalogsicherung im Katalogbackup-Job per E-Mail schicken oder auf NAS sichern zu lassen. Das gelingt per Skript im »RunAfterJob« . Fällt der Backupserver aus, kann ich mit der Bootstrap-Datei den Bacula-Katalog bequem wiederherstellen.

Erol Akman ist zertifizierter Bacula Instructor bei der Firma Dass IT GmbH.

BRU

Mein Beispielsetup für BRU [8] geht von diesen Annahmen aus: Backupmedium ist ein gemounteter, 4 TByte großer Raid-5-Storage, auf dem im wöchentlichen Full Backup insgesamt 400 GByte Daten von 30 Clientsystemen mit geschätzten 5 GByte täglichem Änderungsvolumen für inkrementelle Backups anfallen.

Acht Wochen sollen die Vollbackups erhalten bleiben, zwei Wochen die inkrementellen. Wir legen dafür zwei Nutzer an: »Full« der Besitzer der wöchentlichen Komplettbackups und »Inc« für die täglichen inkrementellen Sicherungen.

• Im »Preferences« -Dialog setze ich die »Max Stage Age« auf 56 Tage (8 Wochen).
• Unter »Open Data Manager | Users« setze ich »Max Stage Age« auf 56 Tage für den User »Full« , für »Inc« auf 14.
• Dann erstelle ich die Backup-Definitionen und -Schedules: »New…« erzeugt einen neuen Backupjob, sein Ziel (»Destination« ) lasse ich auf »Stage Disk« zeigen, der Backuptyp ist »Full« , der Jobtyp »Backup« , das »Overwrite Setting« veranlasst den BRU-Server alte Backups zu überschreiben.
• Jetzt noch den Eigentümer »Full« angeben, »OK« klicken, die Clients (und deren Daten) auswählen und speichern (»Save« ).
• Als Nächstes stelle ich ein, wie oft das Backup erfolgen soll (wöchentlich).
• Das tägliche, inkrementelle Backup entsteht aus einer (umbenannten) Kopie der oben erzeugten wöchentlichen Komplettsicherung mit einem anderen User, Namen, Intervall (täglich, nach den üblichen Arbeitszeiten) und Backuptyp (inkrementell).

Als Ergebnis habe ich jetzt ein vollständiges Backup, das jeden Freitag mit der Userkennung »Full« auf der Platte landet. Zusätzlich dazu gibt es ein tägliches inkrementelles Backup auf dem Server (User »Inc« ). Ersteres wird 56 Tage aufbewahrt, die täglichen Backups nur 14 Tage. Der BRU-Server löscht die Sicherungen vollautomatisch, sobald sie dieses Alter erreichen.

Tim Jones, President and CTO of TOLIS Group Inc., beschäftigt sich seit 1982 mit den Prozessen um Datenbackup and Restore. Seit 1994 gehört er zum BRU-Team.

SEP Sesam

Mit SEP Sesam Version 4.x[9] ist es einfach, die manuellen Backups voll zu automatisierten. Nach der Installation erfolgen die Einstellungen in vier Schritten:

• Aufnahme der Backupclients: Ich gebe den Hostnamen der Backupclients unter dem Menüpunkt »Komponenten | Topologie« ein.
• NAS als Backupstorage einbinden: Ich lege einen neuen Datastore mit einem beliebigen Name an, wähle als Device-Server den Backupserver selbst und gebe den UNC-Pfad des NAS-Share an, zum Beispiel »\\192.168.1.100\sesam« . Als Laufwerksgruppe verwende ich wegen der Übersichtlichkeit den Namen des Datastore. Ich bestätige den Dialog mit »OK« und akzeptiere die Einstellungen der Watermarks.
• Aufträge und Sicherungsgruppe: Im Menüpunkt »Aufträge | nach Clients« generiere ich für alle Backupclients einen neuen Auftrag und wähle über den Browser die lokalen Filesysteme aus. Auftragsname und Sicherungstyp ergeben sich automatisch. Unter »Aufträge | nach Gruppen« lege ich eine neue Gruppe an und füge ihr die angelegten Aufträge hinzu.
• Zeitpläne: Auf der Management-Oberfläche lege ich unter »Zeitplanung | Zeitpläne« zwei Pläne an: einen vom Backuptyp »Full« zur wöchentlichen Ausführung der Vollsicherung, beispielsweise für Sonntage um 15:00 Uhr, den zweiten vom Typ »INC« zur inkrementellen Sicherung, beispielsweise von Montag bis Samstag um 20:00 Uhr. Die Zeitpläne füge ich abschließend zu der vorhin angelegten Sicherungsgruppe hinzu.

SEP Sesam kann den Admin täglich per Mail über den Status der nicht erfolgreichen Sicherungen benachrichtigen. Ich gebe dazu unter dem Menüpunkt »Konfiguration | E-Mail Einstellungen« passende Parameter an und aktiviere »sm_alarm« und »sm_disaster« über »Konfiguration | Schnittstellen« .

Der Bundesverdienstkreuz-Träger Georg Moosreiner ist Vorstand der SEP AG.