Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linuxtopia - Red Hat Enterprise Linux Einfuhrung in die System-Administration - Red Hat Enterprise Linux-spezifische Informationen

8.4. Red Hat Enterprise Linux-spezifische Informationen

Es gibt wenig im allgemeinen Kapitel �ber Disaster und Wiederherstellung, das einen direkten Einfluss auf ein bestimmtes Betriebssystem hat. Die Computer in einem �berfluteten Datencenter w�ren so oder so betriebsunf�hig, ob auf ihnen nun Red Hat Enterprise Linux oder ein anderes Betriebssystem l�uft. Es gibt jedoch Teile von Red Hat Enterprise Linux, die sich auf bestimmte Aspekte der Wiederherstellung beziehen. Diese werden im folgenden Abschnitt beschrieben.

8.4.1. Software-Support

Als Softwarehersteller hat Red Hat eine Reihe von Support-Angeboten f�r seine Produkte, inklusive Red Hat Enterprise Linux. Mit diesem Handbuch halten Sie das allereinfachste Supporttool in den H�nden. Dokumentation f�r Red Hat Enterprise Linux erhalten Sie auf der Red Hat Enterprise Linux Dokumentations-CD (die auf Ihrem Red Hat Enterprise Linux-System f�r schnellen Zugriff installiert werden kann), gedruckt in den verschiedenen Red Hat Enterprise Linux-Packungen und in elektronischer Form unter https://www.redhat.com/docs/.

Selbsthilfe-Optionen finden Sie in den vielen Mailinglisten von Red Hat (unter https://listman.redhat.com/mailman/listinfo/). Diese Mailinglisten machen Gebrauch vom gemeinschaftlichen Wissen der Red Hat-Benutzer-Gemeinschaft und zus�tzlich dazu werden viele Listen von Red Hat-Mitarbeitern mitgelesen, die auch ihren Beitrag dazu leisten, wenn die Zeit es erlaubt. Desweiteren gibt es eine Wissensdatenbank auf der Red Hat-Webseite. Diese finden Sie auf der Hauptsupportseite von Red Hat unter https://www.redhat.com/apps/support/.

Es gibt noch weitere umfangreiche Support-Optionen. Informationen hierzu finden Sie auf der Red Hat-Webseite.

8.4.2. Backup-Technologien

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.

AnmerkungAnmerkung
 

Wie in Abschnitt 8.2.6.1 beschrieben, besitzen die meisten Computer, die auf einer Standard-PC-Architektur basieren, nicht die n�tige Funktionalit�t, direkt von einem Backup-Band zu booten. Darausfolgend ist Red Hat Enterprise Linux nicht in der Lage, ein Booten vom Band auf solcher Hardware durchzuf�hren.

Sie k�nnen jedoch auch Ihre Red Hat Enterprise Linux CD-ROM als Rettungsdiskette verwenden. Weitere Informationen finden Sie im Kapitel �ber den Rettungsmodus im Red Hat Enterprise Linux Handbuch zur System-Administration.

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.

TippTipp
 

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.

Fu�noten

[1]

Die Erweiterung .gz wird traditionell verwendet, um anzuzeigen, dass die Datei mit gzip komprimiert wurde. Manchmal wird .tar.gz zu .tgz abgek�rzt, um Dateinamen nicht zu lang werden zu lassen.

 
 
  Published under the terms of the GNU General Public License Design by Interspire