Red Hat Enterprise Linux wird mit verschiedenen Programmen f�r das Durchf�hren von Backups und Wiederherstellen von Daten ausgeliefert. Jeweils f�r sich sind diese Dienstprogramme jedoch keine vollst�ndige Backup-L�sung. Sie k�nnen jedoch als Kern f�r eine solche L�sung verwendet werden.
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.
