|
|
| (23 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| '''topic''' kurze Beschreibung
| | #WEITERLEITUNG [[Datensicherung]] |
| == Beschreibung ==
| |
| == Installation ==
| |
| == Anwendungen ==
| |
| === Fehlerbehebung ===
| |
| == Syntax ==
| |
| === Optionen ===
| |
| === Parameter ===
| |
| === Umgebungsvariablen ===
| |
| === Exit-Status ===
| |
| == Konfiguration ==
| |
| === Dateien ===
| |
| == Sicherheit ==
| |
| == Dokumentation ==
| |
| === RFC ===
| |
| === Man-Pages ===
| |
| === Info-Pages ===
| |
| == Siehe auch ==
| |
| == Links ==
| |
| === Projekt-Homepage ===
| |
| === Weblinks ===
| |
| === Einzelnachweise ===
| |
| <references />
| |
| == Testfragen ==
| |
| <div class="toccolours mw-collapsible mw-collapsed">
| |
| ''Testfrage 1''
| |
| <div class="mw-collapsible-content">'''Antwort1'''</div>
| |
| </div>
| |
| <div class="toccolours mw-collapsible mw-collapsed">
| |
| ''Testfrage 2''
| |
| <div class="mw-collapsible-content">'''Antwort2'''</div>
| |
| </div>
| |
| <div class="toccolours mw-collapsible mw-collapsed">
| |
| ''Testfrage 3''
| |
| <div class="mw-collapsible-content">'''Antwort3'''</div>
| |
| </div>
| |
| <div class="toccolours mw-collapsible mw-collapsed">
| |
| ''Testfrage 4''
| |
| <div class="mw-collapsible-content">'''Antwort4'''</div>
| |
| </div>
| |
| <div class="toccolours mw-collapsible mw-collapsed">
| |
| ''Testfrage 5''
| |
| <div class="mw-collapsible-content">'''Antwort5'''</div>
| |
| </div>
| |
| | |
| [[Kategorie:Entwurf]] | |
| | |
| = TMP =
| |
| == Was ist ein BACKUP? ==
| |
| * Datensicherung
| |
| * Schutz vor Datenverlust
| |
| | |
| == Wo? ==
| |
| Hardware und Aufbewahrungsorte
| |
| | |
| *'''''Hardware'''''
| |
| **Disketten (früher)
| |
| **CDs
| |
| **DVDs
| |
| **Magnetbänder (wg. Vorteil Energieverbrauch u. Haltbarkeit noch heute - Tape-Library)
| |
| **netzwerkbasierende Festplatten
| |
| **Wechselfestplatten
| |
| | |
| *'''''Aufbewahrungsorte'''''
| |
| **Bankschließfächer (nicht jederzeit Zugriff möglich)
| |
| **Online-Datensicherung (Rechenzentrum; Zugriff jederzeit möglich)
| |
| **sogenannten Zellen - feuersichere Unterbringung in speziell gesicherten Safes oder RäumlichkeitenTape
| |
| | |
| == Dokumentation ==
| |
| Bei der Datensicherung ist es sehr wichtig, eine gute Dokumentation zu führen, da von ihr der Erfolg und die Geschwindigkeit der Datensicherung sowie der Wiederherstellung abhängen können.
| |
| | |
| *Ablauf der Datensicherung
| |
| *Aufbau der Archivierung
| |
| *zu treffende (Sofort-)Maßnahmen
| |
| *Kompetenzen (der Mitarbeiter und Dienstleister)
| |
| *Prioritäten für besonders zeitkritische Daten und Systeme
| |
| | |
| == Sicherungsarten ==
| |
| Je nach Veränderungsintensität der zu sichernden Daten.
| |
| | |
| === Komplett-/Vollsicherung auch „Normale Sicherung“ ===
| |
| ==== Vorteil ====
| |
| * technisch sehr einfach
| |
| ==== Nachteil ====
| |
| * sehr hoher Speicherbedarf
| |
| * Speicherabbildsicherung (Image Backup):
| |
| * 1-zu-1-Abbild gesichert, so können beispielsweise nicht nur die Nutzdaten, sondern das gesamte Dateisystem, inklusive Betriebssystem und Benutzereinstellungen gesichert werden
| |
| | |
| === Differenzielle Sicherung ===
| |
| * Alle Dateien, die seit der letzten Komplettsicherung geändert wurden oder neu hinzugekommen sind, werden gespeichert.
| |
| * Es wird also immer wieder auf der letzten Komplettsicherung aufgesetzt.
| |
| ==== Vorteil ====
| |
| * gegenüber einer neuen Vollsicherung werden Speicherplatz und Zeit gespart
| |
| **Programmierung der Backup-Software relativ simpel
| |
| **nicht mehr benötigte Sicherungsstände können unabhängig voneinander gelöscht werden (inkrementelle Sicherungen zwangsläufig miteinander verkettet)
| |
| ==== Nachteil ====
| |
| * nicht geeignet bei sehr großen Dateien, die sich häufig ändern (virtuelle Maschinen, Datenbanken, Postfach-Dateien mancher E-Mail-Programme)
| |
| | |
| === Inkrementelle Sicherung ===
| |
| **Es wird also immer auf der letzten inkrementellen Sicherung aufgesetzt.
| |
| **vollständige Kette (Vollsicherung – inkrementelle Sicherungen 1, 2, 3 usw. – Originaldaten) muss fehlerfrei nachvollziehbar sein
| |
| **Inkremente können auf zwei Weisen gespeichert werden:
| |
| ***1. '''''forward deltas''''':
| |
| ****Vollsicherung dient als Fundament und wird nicht verändert - Inkremente werden darauf aufgebaut (z.B. duplicity, duply, RSYNCH, RSNAPSHOT)
| |
| ***2. '''''reverse deltas''''' (umgekehrtes forward deltas):
| |
| ****Vollsicherung verändert sich bei jeder Datensicherung
| |
| ****Hat sich eine Datei gegenüber der letzten Vollsicherung verändert, wird die vorherige Dateiversion als Inkrement gespeichert
| |
| ****aktuelle Version wird in die Vollsicherung eingefügt
| |
| ****Auf die Vollsicherung kann jederzeit problemlos zugegriffen werden
| |
| *****Bsp. rdiff-backup
| |
| **''Vorteil'':
| |
| ***geringer Speicherbedarf
| |
| ***besonders geeignet für Datensicherung in Netzwerken oder in der Cloud
| |
| **''Nachteil'':
| |
| ***alle Inkremente miteinander verkettet, weshalb es ist nur mit sehr großem Rechenaufwand möglich, ein Inkrement zwischen zwei anderen Inkrementen zu entfernen, etwa um Speicherplatz zu sparen oder private Daten zu löschen
| |
| | |
| == Erkennung veränderter Dateien ==
| |
| *über Anlage spezieller Dateiattribute
| |
| *Abgleich des Datei-Datums
| |
| *Abgleich der Dateigröße
| |
| *und/oder den Einsatz von Prüfsummen wie SHA-1, MD5, SHA-256
| |
| | |
| == Backupstrategien ==
| |
| *'''''First in, first out (FIFO)'''''
| |
| **Sobald Speicherplatz zur Neige geht, wird die älteste Vollsicherung gelöscht, beziehungsweise auch alle inkrementellen oder differenziellen Backups
| |
| *'''''Großvater-Vater-Sohn auch Generationenprinzip'''''
| |
| **Sohn-Backup: z.B. tägliches BU
| |
| **Vater-Backup: z.B. wöchentliches BU
| |
| **Großvater-Backup: z.B. montliches BU
| |
| * '''''Türme von Hanoi'''''
| |
| **Türme von Hanoi am Bsp. für drei Medien:
| |
| ***erste Medium jeden zweiten Tag benutzt (1, 3, 5, 7, 9, …)
| |
| ***das zweite jeden vierten (2, 6, 10, …)
| |
| ***das dritte jeden achten (4, 12, 20, …)
| |
| | |
| == Echtzeitanwendungen ==
| |
| Hot oder Cold Backup
| |
| *'''''Hot Backup, auch Online Backup''''':
| |
| **Sicherung eines Systems (beispielsweise einer Datenbank) während des laufenden Betriebs dieses Systems
| |
| **''Vorteil'':
| |
| ***Vorhalten eines aktuellen „Ersatz-Datenbestandes“, der im Fall eines Systemabsturzes sofort einsatzbereit ist
| |
| **''Nachteil'':
| |
| ***... ist, dass sich Fehler in einem Datensatz sofort auf die Sicherung übertragen werden
| |
| *'''''Cold Backup, auch Offline Backup''''':
| |
| **Sicherung eines Echtzeit-Systems, die erstellt wird, während das System nicht aktiv ist
| |
| | |
| **''Vorteil''
| |
| ***…, dass die Daten in einem konsistenten Zustand gesichert sind.
| |
| **''Nachteil''
| |
| ***..., dass das System für den Zeitraum der Sicherung nicht verfügbar ist
| |
| | |
| == Datensicherungsrichtlinien ==
| |
| Wie die Datensicherung zu erfolgen hat. Vollsicherung. Differenzielle. Oder Inkrementelle Sicherung.
| |
| *Wer für die Datensicherung verantwortlich ist.
| |
| *Wann Datensicherungen durchgeführt werden.
| |
| *Welche Daten gesichert werden sollen.
| |
| *Welches Speichermedium zu verwenden ist.
| |
| *Wo die Datensicherung sicher aufbewahrt wird.
| |
| *Wie die Datensicherung vor Datendiebstahl zu sichern ist (zum Beispiel durch Verschlüsselung). *Wie lange Datensicherungen aufzubewahren sind.
| |
| *Wann und wie Datensicherungen auf ihre Wiederherstellbarkeit überprüft werden.
| |
| *Weitere Punkte:
| |
| **Wenn die Wiederherstellung von Daten notwendig ist, sollte das Vorgehen mehreren Mitarbeitern bekannt sein. Eine Checkliste für diesen Fall ist sehr nützlich, da im Ernstfall oft niemand Zeit oder Nerven hat, nachzudenken, was als Nächstes zu tun ist.
| |
| **Nach Möglichkeit sollten die Daten vor der Sicherung nicht komprimiert werden. Redundanz kann bei der WiederherstellunLöschung veralteter Datensicherungeng von Daten nützlich sein.
| |
| **Es ist zumindest ein Laufwerk bereitzuhalten, welches die verwendeten Medien lesen kann.
| |
| **Der wirtschaftliche Nutzen von Datensicherungen (Kosten, um die Daten ohne Datensicherung wiederherzustellen) muss in einem sinnvollen Verhältnis zu dem für die Datensicherung betriebenen Aufwand stehen.
| |
| **Der einzig sichere Beweis einer erfolgreichen Datensicherung ist der Nachweis, dass die gesicherten Daten auch vollständig und innerhalb eines angemessenen Zeitraums wiederhergestellt werden können. Aus diesem Grund sollten in regelmäßigen Abständen Rücksicherungstests erfolgen.
| |
| | |
| == Allgemeine Kriterien ==
| |
| *Art der Daten
| |
| *Maschinell wiederherstellbare Daten
| |
| *Manuell wiederherstellbare Daten
| |
| *Unersetzliche Daten - Wert der Daten
| |
| *Änderungshäufigkeit der Daten
| |
| *Gesetzliche Anforderungen
| |
| *Speicherort
| |
| *Zeitaufwand der Datensicherung
| |
| | |
| == Allgemeine Anforderungen==
| |
| *Regelmäßigkeit
| |
| *Aktualität
| |
| *Verwahrung
| |
| *Anfertigung von zwei Datensicherungen
| |
| *Ständige Prüfung auf Vollständigkeit und Integrität
| |
| *Regelmäßige Überprüfung auf Wiederherstellbarkeit
| |
| *Datensicherungen sollten automatisch erfolgen
| |
| *Verwendung von Standards
| |
| *Datenkompression
| |
| *Zeitfenster
| |
| *Löschung veralteter Datensicherungen
| |
| | |
| == Links ==
| |
| === Interne Links ===
| |
| === Weblinks ===
| |
| # https://de.wikipedia.org/wiki/Datensicherung
| |
| | |
| == tmp ==
| |
| === Backup und Zeitstempel ===
| |
| Zeitstempel spielen beim Backup eine besondere Rolle, zum Einem möchte man bei vielen Backupaufgaben bei der Wiederherstellung der Dateien aus dem Backuparchiv die alten Zeitstempel wieder haben, zum anderen benötigt man zum Beispiel
| |
| * bei [http://wiki.linux-club.de/mediawiki/index.php?title=Inkrementelles_Backup&action=edit&redlink=1 inkrementellen Backups] die Zeitstempel der Dateien, um herauszufinden, ob sich die Datei seit dem letztem Backup geändert hat und somit jetzt in das inkrementelle Backup mit aufgenommen werden muss.
| |
| * Und nicht zu guter Letzt, gibt es auch Backup Methoden bei denen einzelne Dateien innerhalb eines Backuparchives gezielt ausgetauscht werden, wenn sie sich seit dem Erstellen des Backups geändert haben, oder in der Zwischenzeit neu hinzu gekommen sind, müssen sie natürlich jetzt in das Archiv aufgenommen werden.
| |
| * Beim Anlegen eines Backups werden die Dateien ausgelesen, durch dieses Auslesen wird im Normalfall die atime dieser Dateien neu gesetzt.
| |
| * Dieses hätte jedoch zur Folge, dass in einem so gesicherten Verzeichnis nicht nach den Dateien gesucht werden könnte, auf die schon länger nicht mehr zugegriffen worden ist, um sie zum Beispiel
| |
| * zu löschen.
| |
| * Aus diesem Grund haben die meisten Backupprogramme spezielle Optionen, die das setzen der atime beim Backup verhindern.
| |
| * Dieses kann aber nur dadurch erreicht werden, dass nach dem die Datei ausgelesen wurde, die alte atime wieder neu gesetzt wird.
| |
| * Der touch-Befehl und viele andere Programme (auch tar) mit denen die Zeitstempel in den [http://wiki.linux-club.de/opensuse/Inode Inode] manipuliert werden können, nutzen den Systembefehl [http://man.splitbrain.org/utime%282%29 utime] dafür.
| |
| * Bei diesen Befehlen wird beim zurücksetzen der atime auf den alten Wert, die ctime zerstört und auf die aktuelle Zeit gesetzt.
| |
| * Das hat dann die Konsequenz, das nach einem Backup dann in diesem Verzeichnis zwar nach Dateien gesucht werden kann, auf die lange nicht zugegriffen wurde, aber nicht mehr nach Dateien gesucht werden kann, bei denen in der letzten Zeit die ctime verändert wurde.
| |
| * Auch kann mit solchen Backupprogrammen nur die atime und die mtime der Dateien wieder hergestellt werden, die ctime wird auf eine Zeit des Zurückspielens der Sicherung gesetzt.
| |
| * Bei inkrementellen Backups stellt sich die Frage, sollen die Dateien nach der mtime oder der ctime beurteilt werden.
| |
| * Wird die Datei nach der Änderung der mtime beurteilt, dann sind dort sämtliche Änderungen am Inhalt dieser Datei für das Backup berücksichtigt, jedoch nicht, zum Beispiel
| |
| * eventuelle vorgenommene Änderungen an den Besitz- oder Zugriffsrechten.
| |
| * Einige Backupkonzepte ermöglichen die Wahl zwischen beiden Varianten, einige Programme unterstützen jedoch nur die Suche nach dem geänderten mtime Zeitstempel.
| |
| * Gelegentlich ein kleines Problem sind die Zeitstempel der [http://wiki.linux-club.de/opensuse/Directory Verzeichnisse].
| |
| * Wird zum Beispiel
| |
| * zuerst das Verzeichnis aus dem Backup gewonnen, dann können die gespeicherten Zeitstempel aus dem Backup zwar gesetzt werden, wenn jedoch anschließend noch die Dateien aus diesem Verzeichnis hineingepackt werden, dann sind die Zeitstempel der Verzeichnisse wieder auf dem Zeitpunkt des Auspackens der letzten Datei in diesem Directory gesetzt und nicht wie gewünscht, die vom gesicherten Verzeichnis.
| |
| * Von Bedeutung für manche Anwendungen ist auch die Genauigkeit mit der die Zeitstempel in den Headerdateien des Backups abgelegt werden können, während für einige Anwendungen durchaus eine Genauigkeit von 1 Sekunde ausreicht, benötigen andere Backupkonzepte eventuell eine Genauigkeit von 1/1000 Sekunde.
| |
| * Aus diesen Ausführungen sollte jetzt erkennbar sein dass es zwischen Backup und Zeitstempel eine doch recht vielschichtige Wechselwirkung gibt, die sich oftmals nur mit der Wahl des für diesen Zweck geeigneten Backupprogramms und den richtigen Einstellungen und Optionen lösen lässt.
| |
| * Wem die Möglichkeiten zum Beispiel
| |
| * von tar in Bezug auf die Zeitstempel nicht ausreichen und wer eventuell auch noch weitere Features wie zum Beispiel [http://wiki.linux-club.de/opensuse/Zugriffsrechte#Access_Control_Lists_unter_Linux ACL-Unterstützung] benötigt, dem sei an dieser Stelle ein Blick in die [http://man.splitbrain.org/star ManPage von star] empfohlen.
| |
| | |
| ==== tar und Zeitstempel ====
| |
| Der Befehl [http://man.splitbrain.org/tar tar] ('''T'''ape '''AR'''chiver) bezeichnet ein Programm mit dessen Hilfe einfache Backup-, Archivierungs und ähnliche -Arbeiten am System gemacht werden können.
| |
| * Wenn wir unter LINUX von '''tar''' sprechen, meinen wir damit eigentlich eine '''GNU implementierung''' eines unter UNIX als tar bezeichneten Befehls.
| |
| * Man bezeichnet das Programm deshalb auch auf anderen Systemen '''GNUtar oder gtar'''.
| |
| * Die beiden Programme (UNIX tar und GNU tar) sind nur bedingt kompatibel.
| |
| * Daneben existieren noch mehrere mit TAR verwandte Implementationen die mehr oder weniger viele Erweiterungen und Verbesserungen beinhalten, und oft noch weniger kompatibel zu ihren Urprogrammen sind.
| |
| * Die Stärke von tar liegt in der einfachen und universellen Benutzung, eine der historisch gewachsenen Schwächen von tar, ist der Umgang mit Zeitstempeln.
| |
| * Mit tar läßt sich nur die mtime wieder herstellen.
| |
| * Die atime und die ctime werden zerstört und durch die aktuelle Zeit beim Restore ersetzt.
| |
| * Moderne Versionen von tar haben eine Option, um mittels der mtime inkrementelle Backups machen zu können.
| |
| * Eine weitere Option von tar ermöglicht es beim Erstellen des Archives die atime, (welche durch das Lesen der Dateien beim Erstellen des Archives verändert würde,) vor Veränderung zu schützen, allerdings mit der Nebenwirkung, dass damit analog zum touch-Befehl, die ctime der oginalen Dateien zerstört wird.
| |
| * Damit ist tar durchaus noch geeignet um einfache Backupaufgaben zu übernehmen, und ein Linuxsystem aus einem Tar-Archiv wird sicherlich ohne Probleme funktionieren, allerdings die gehobenen Anspüche die heute an ein modernes Backupprogramm gestellt werden, kann tar damit nicht erfüllen.
| |
| * Die Hauptbedeutung und der Haupteinsatz von GNUtar ist heute deshalb auch mehr im Bereich der Verteilung und Verbreitung von Softwarepaketen zu finden.
| |
| * Den Umfang und die Funktionen können der [http://man.splitbrain.org/tar ManPage von tar] entnommen werden.
| |
| | |
| | |
| [[Kategorie:Backup]]
| |