8.4. Red Hat Enterprise Linux-spezifische Informationen

8.4.2.1. tar

Die tar-Utility ist unter UNIX-Systemadministratoren sehr bekannt. Es ist eine beliebte Archivierungsmethode für das gemeinsame Verwenden von Source Code und Dateien auf mehreren Systemen. Die tar Implementierung in Red Hat Enterprise Linux ist GNU tar, eine der tar-Implementierungen, die mehr Features besitzt.

Mithilfe von tar ist das Sichern von Inhalten eines Verzeichnisses so einfach wie das Eingeben des folgenden Befehls:

tar cf /mnt/backup/home-backup.tar /home/

Dieser Befehl erstellt ein Archiv mit dem Namen home-backup.tar in /mnt/backup/. Das Archiv enthält den Inhalt des /home/ Verzeichnisses.

Die resultierende Archivdatei ist fast so groß wie die zu sichernden Datenmengen. Abhängig von der Art der Daten, die gesichert werden sollen, kann das Komprimieren der Archivdatei die Größe erheblich reduzieren. Die Archivdatei kann durch das Hinzufügen einer einzigen Option zur vorherigen Zeile komprimiert werden.

tar czf /mnt/backup/home-backup.tar.gz /home/

Die resultierende Archivdatei home-backup.tar.gz wird nun mit gzip komprimiert[1].

Es gibt viele Optionen für tar; weitere Informationen finden Sie auf der tar(1) man-Seite.

8.4.2.2. cpio

Die cpio-Utility ist ein anderes traditionelles UNIX-Programm. Es ist ein hervorragendes, allgemeines Programm für das Verschieben von Daten von einem Ort zum nächsten und dient so als gutes Backup-Programm.

Das Verhalten von cpio unterscheidet sich leicht von tar. Im Gegensatz zu tar liest cpio die Namen der Dateien, die verarbeitet werden sollen, über Standard-Eingabe. Eine allgemeine Methode, eine Liste von Dateien für cpio zu generieren, ist mit einem Programm wie find, dessen Ausgabe dann zu cpio geleitet wird:

find /home/ | cpio -o > /mnt/backup/home-backup.cpio

Dieser Befehl erstellt eine cpio-Archivdatei (die alles im /home/-Verzeichnis befindliche enthält) mit dem Namen home-backup.cpio, die im Verzeichnis /mnt/backup abgelegt wird.

	Tipp
	Dadurch dass find eine große Anzahl von Dateiauswahlprüfungen besitzt, können ausgereifte Backups erstellt werden. So führt zum Beispiel der folgende Befehl ein Backup nur der Dateien aus, die im letzten Jahr nicht geändert wurden:

find /home/ -atime +365 | cpio -o > /mnt/backup/home-backup.cpio
            

Es gibt noch viele andere Optionen für cpio (und find); weitere Informationen finden Sie auf den man-Seiten zu cpio(1) und find(1).

8.4.2.3. dump/restore: Nicht empfohlen für gemountete Dateisysteme!

Die Programme dump und restore sind die Linux-Äquivalente zu den gleichnamigen UNIX-Programmen. Als solche denken viele Systemadministratoren mit UNIX-Erfahrung, dass dump und restore gute Kandidaten für ein Backup-Programm unter Red Hat Enterprise Linux sind. Das Design des Linux-Kernels hat sich jedoch im Gegensatz zum dump-Design weiterentwickelt. Hier die Kommentare von Linus Torvalds zu diesem Thema:

From:	 Linus Torvalds
To:	 Neil Conway
Subject: Re: [PATCH] SMP race in ext2 - metadata corruption.
Date:	 Fri, 27 Apr 2001 09:59:46 -0700 (PDT)
Cc:	 Kernel Mailing List <linux-kernel At vger Dot kernel Dot org>

[ linux-kernel added back as a cc ]

On Fri, 27 Apr 2001, Neil Conway wrote:
> > I'm surprised that dump is deprecated (by you at least ;-)).  What to
> use instead for backups on machines that can't umount disks regularly? 


Note that dump simply won't work reliably at all even in 2.4.x: the buffer
cache and the page cache (where all the actual data is) are not
coherent. This is only going to get even worse in 2.5.x, when the
directories are moved into the page cache as well.

So anybody who depends on "dump" getting backups right is already playing
Russian roulette with their backups.  It's not at all guaranteed to get the
right results - you may end up having stale data in the buffer cache that
ends up being "backed up".

Dump was a stupid program in the first place. Leave it behind.

> I've always thought "tar" was a bit undesirable (updates atimes or
> ctimes for example).

Right now, the cpio/tar/xxx solutions are definitely the best ones, and
will work on multiple filesystems (another limitation of "dump"). Whatever
problems they have, they are still better than the _guaranteed_(*)  data
corruptions of "dump".

However, it may be that in the long run it would be advantageous to have a
"filesystem maintenance interface" for doing things like backups and
defragmentation..

		Linus

(*) Dump may work fine for you a thousand times. But it _will_ fail under
the right circumstances. And there is nothing you can do about it.

Angesichts dieses Problems wird von der Benutzung von dump/restore auf gemounteten Dateisystemen strengstens abgeraten. Da dump jedoch ursprünglich dazu entwickelt worden war, um ungemountete Dateisysteme zu sichern, bleibt dump in Situationen, in denen ein Dateisystem auch offline mittels umount gebracht werden kann, aus diesem Grund nach wie vor eine funktionsfähige Backup-Methode.

8.4.2.4. Advanced Maryland Automatic Network Disk Archiver (AMANDA)

AMANDA ist eine Client/Server-basierte Backup-Applikation, die von der Universität Maryland, USA, erstellt wurde. Durch eine Client/Server-Architektur kann ein einziger Backup-Server (gewöhnlich ein leistungsstarkes System mit sehr viel freiem Platz auf schnellen Festplatten und mit der gewünschten Backup-Software konfiguriert) viele Client-Systemen sichern, auf denen nichts weiter als die AMANDA-Client-Software laufen muss.

Dieser Ansatz ist sehr sinnvoll, da die für Backups benötigten Ressourcen in einem System zusammengefasst werden, anstelle dass zusätzliche Hardware für jedes System, das Backup-Services benötigt, gebraucht wird. AMANDAs Design dient auch dazu, die Verwaltung von Backups zu zentralisieren und erleichtert somit das Leben des Systemadministrators.

Der AMANDA-Server verwaltet einen Pool von Backup-Medien und rotiert die Verwendung im Pool, sodass alle Backups für die vom Administrator vorgegebene Aufbewahrungszeit aufbewahrt werden. Alle Medien werden vorformatiert, so dass AMANDA erkennen kann, ob das richtige Medium zur Verfügung steht oder nicht. Zusätzlich dazu kann AMANDA mit automatischen Medien-Wechsel-Einheiten gekoppelt werden und ermöglicht so das vollständige Automatisieren der Backups.

AMANDA verwendet entweder tar oder dump für das Durchführen der eigentlichen Backups (unter Red Hat Enterprise Linux ist tar aufgrund der Probleme mit dump, wie in Abschnitt 8.4.2.3 beschrieben, vorzuziehen). Als solches benötigen AMANDA-Backups kein AMANDA zum Wiederherstellen von Dateien — ein eindeutiger Pluspunkt.

AMANDA wird normalerweise einmal am Tag während des Backupszeitraums des Datencenters ausgeführt. Der AMANDA-Server verbindet sich mit dem Client-System und weist diesen an, geschätzte Größen der durchzuführenden Backups herzustellen. Sobald alle diese Schätzungen zur Verfügung stehen, erstellt der Server einen Plan, indem automatisch festgelegt ist, in welcher Reihenfolge die Systeme gesichert werden.

Ist das Backup gestartet, werden die Daten über das Netzwerk vom Client zum Server gesendet, wo sie dann auf einer Festplatte gespeichert werden. Ist ein Backup vollständig, beginnt der Server, die Daten von der Festplatte auf ein Backup-Medium zu schreiben. Zum gleichen Zeitpunkt schicken andere Clients ihre Backups zum Server zum Speichern auf der Festplatte. Dies resultiert in einem kontinuierlichen Datenstrom, der für das Schreiben auf das Backup-Medium zur Verfügung steht. Mit dem Schreiben der Backups auf das Backup-Medium werden diese vom Server gelöscht.

Sobald alle Backups abgeschlossen sind, erhält der Systemadministrator eine E-Mail mit dem Bericht über den Status der Backups, was ein Review schnell und einfach werden lässt.

Müssen Daten wiederhergestellt werden, enthält AMANDA ein Utility, mit dem das Dateisystem, Datum und Dateiname identifiziert werden können. Sobald dies geschehen ist, identifiziert AMANDA das richtige Backup-Medium, sucht die Daten und stellt diese wieder her. Wie bereits erwähnt, ermöglicht AMANDAs Design das Wiederherstellen von Daten auch ohne die Hilfe von AMANDA, auch wenn die Identifizierung der richtigen Medien dann ein langsamerer, manueller Vorgang wäre.

Dieser Abschnitt streift lediglich die einfachsten AMANDA-Konzepte. Weitere Informationen über AMANDA finden Sie auf der amanda(8) man-Seite.