|
Details:
Autor: |
Stefan Greiner / Regelmäßige Sicherungen aller unternehmenskritischen Daten |
Datum: |
25.05.2006 10:16:42 |
|
Schnittstelle ist für die Filterung der gewünschten Meldungen und deren Weiterleitung an zuständige Personen frei programmierbar. Die Alarm-Schnittstelle besteht aus dem Programm /bin/sesam/ sm_ alarm. Analog gibt es für erfolgreich verlaufene Sicherungen und Rücksicherungen das Script sm_notify. Das Script sm_disaster generiert für den Disasterfall einen Aufruf.
Diese Prozedur wird von allen Sicherungen, deren Namen »DISASTER« oder »SESAM« enthält, im Erfolgsfall ausgeführt. Dabei werden zwei Argumente übergeben:
• das Label des gerade benutzten Mediums
• das vollständige Restore-Kommando, mit dem die Daten des Savesets restauriert werden können
Die Disaster-Strategie schaut demnach folgendermaßen aus:
• Der Benutzer richtet mindestens eine Sicherung ein, die das Verzeichnis var des SEP-sesam-Anwenders sichert. Das umfasst beispielsweise Listings, Loggings, Datenbanken und INI-Dateien.
• Diese Sicherung sollte täglich mit dem Modus COPY oder FULL gesichert werden.
• Der Benutzer editiert das sm_disaster-Script. Dieses kopiert den Inhalt der beiden Eingabeargumente
der SEP-sesam-Rechner, beispielsweise E-Mails, Dateikopien und Disketten, auf andere Rechner an zuvor definierte Positionen. Damit stehen die Informationen, wann und auf welches Medium die letzte Eigensicherung des SEP sesam stattgefunden hat, augenblicklich zur Verfügung.
Im Ernstfall muss der Systemverwalter dann nach der Instandsetzung des Rechners die folgenden Schritte abarbeiten:
• Die Software vom Distributionskit SEP sesam neu installieren.
• An der definierten Stelle feststellen, welches Medium die letzte Eigensicherung des SEP sesam enthält
Das Restore-Kommando der Disaster-Informationen ist im Verzeichnis /bin/sesam einzufügen. Danach ist das richtige Medium in das Laufwerk einzulegen. Dadurch wird der originäre SEP-sesam-Server erstellt. Damit können alle weiteren Server wiederhergestellt werden.
Anhang:
1. Backup-Strategien
Das vollständige Backup sichert stets den kompletten Datenbestand. Die so gesicherten Daten können in einem Rutsch zurückgespielt werden. Wegen des hohen Zeitaufwands ist ein Voll-Backup nicht für den täglichen Einsatz geeignet. Deshalb ist in der Regel eine Mischform besser. Bei einem differenziellen Backup werden nur die seit dem letzten vollständigen Backup geänderten oder neu hinzugefügten Dateien gesichert. Gespeichert werden alle Daten seit dem letzten Voll-Backup – egal wie viele Zwischensicherungen bislang erfolgt sind. Dies spart sowohl Zeit als auch Speicherplatz. Bei einer Wiederherstellung der Daten müssen Sie einerseits das vollständige Backup einspielen und danach das letzte differenzielle Backup. Anders beim inkrementellen Backup. Hier werden nicht alle Daten seit dem Voll- Backup gespeichert, sondern nur die Veränderungen seit der letzten Sicherung. Diese Sicherungssätze sind im Vergleich zu einem differenziellen Backup wesentlich kleiner. Daher eignet sich das inkrementelle Backup besonders für die tägliche Sicherung. Für das Zurücksichern benötigen Sie neben dem Voll-Backup alle danach noch angelegten inkrementellen Sicherungssätze. Schließlich wird in der Praxis oft noch ein Multi-Level-Backup gefahren. Hier wird ein volles Backup mit inkrementellen Backups kombiniert. Im einfachsten Fall erfolgt einmal im Monat eine Vollsicherung des Datenbestands und anschließend die tägliche Speicherung der modifizierten Dateien. Dem vollen Backup wird hierbei das Level 0 zugeordnet und die weiteren Sicherungen erhalten das Level 1. Nach Ablauf des Monats wiederholt sich das Ganze.
[Vorherige] 1 2 3 4 5 6 7 8 9 10 11 12 [Nächste]
|