Backup
Backup
Ein Backup dient ganz allgemein dazu, Daten in einer geeigneten weise zu sichern. Dabei gibt es meiner Ansicht nach im wesentlichen vier herangehensweisen.
- gar kein Backup: meiner Ansicht nach die schlechteste Idee
- sporadisches kopieren wichtiger Daten auf einen anderen Datenträger: kann bei entsprechender (Un-)Wichtigkeit der Daten und sehr guter Disziplin, das man es auch wirklich macht wenn sich die entsprechenden Daten ändern ausreichend sein
- Regelmäßige voll und delta Backups mit einem entsprechenden Programm: (üblich ist eine Wochen-Voll-Sicherung und eine Tages-"delta"-Sicherung) ist schon sehr gut und bietet über die delta-Sicherungen bis zum letzten aufbewahrten (voll-)Backup auch eine eingeschränkte Archivfunktion
- Backup mit Archiv funktion: hier können auch Änderungen die ausversehen gemacht werden über die Archiv-Dauer rückgängig gemacht werden
Archiv Funktion - wozu und wie
Für mich ist eine echte Archivfunktion, wenn ich über eine gewisse Zeit oder über eine gewisse Anzahl von Änderungen diese wieder rückgängig machen kann. Ein Programm mit Archivfunktion ist das von mir verwendete storeBackup welches bei vielen Distributionen über die standard Repositoris erhältlich ist.
Eine weiteren Artikel zu storeBackup findet man auch in der iX.
Beispiel aus der Praxis
Von Uwe S.
Hier will ich mal ein Beispiel aus meiner beruflichen Praxis zum Besten geben:
Ein Kollege aus der Personalabteilung hat mit dem Ende der zeitlich ohnehin befristeten Beschäftigung von Leiharbeitskräften mit Schlag 01.08.2014 alle bis dahin vorhandnenen Datensätze von eben jenen ausgeschiedenen Mitarbeitern gelöscht. Eine Kollegin von der Zeiterfassung konnte daher die im letzten Monat aufgelaufenen Arbeitszeiten nicht mehr abrechnen. Waren ja keine Daten zu den betreffenden (Ex-) Kollegen mehr vorhanden. Aber wozu hat man eine Datensicherung. Da das Zeiterfassungsprogramm auf Basis einer ISAM-Datenbank läuft, wird eine Datensicherung mit Bordmitteln der Datenbank als Datei auf einem lokalen Dateisystem erzeugt und von dort mit TIVOLI wie eine normale Datei gesichdert. Um Platz zu sparen wird die gesicherte Datei mit ZIP komprimiert. Der TIVOLI-Client ist mit Defaultwerten konfiguriert und da werden ZIP-Dateien ausgenommen. Die ZIP-Datei wird jeden Tag durch die Datenbanksicherung überschrieben. Mit anderen Worten: da gibt es kein Backup! Jedenfalls keines, das älter 24 Stunden ist.
Zuerst habe ich gedacht auch storeBackup würde komprimierte Dateiformate nicht sichern, aber das war falsch: storeBackup komprimiert nur standardmäßig keine Dateien kleiner 1024 kB UND komprimierte Formate:
comprRule = $size > 1024 and not $file =~ /\.zip\Z|\.bz2\Z|\.gz\Z|\.tgz\Z|\.jpg\Z|\.gif\Z| \.tiff\Z|\.tif\Z|\.mpeg\Z|\.mpg\Z|\.mp3\Z|\.ogg\Z|\.gpg\Z|\.png\Z
Übrigens haben wir nun - nachdem das Kind leider schon wieder mal in den Brunnen gefallen ist - ZIP-Dateien von der Ausnahme ausgenommen; sprich: sie werden künftig gesichert. Unsere Rettung ist in diesem Fall etwas aufwändiger, aber immerhin realisierbar. Da wir die Daten auf Dateisystemebene mit TIVOLI sichern, sind auch alle zurückliegenden Datenbankdateien in den Sicherungssätzen vorhanden. Also kann man den Zustand der Datenbank von einem spezifischen Datum theoretisch wiederherstellen. Nicht aber in der Originaldatenbank, sondern auf einer Testinstanz.
Fazit: (By Ulf)
- Backup aller (wichtigen) Daten ist ein Muß für den LUG-Interessierten und ein Fehlen kann beim Profi sogar zur Abmahnung führen!
- Ein Backup ist immer gewissenhaft zu konfigurieren!
- Das erste Backup und alle weiteren zyklisch mindestens monatlich einmal zu überprüfen (Stichproben verschiedener Dateien incl. ZIP und Videos wiederherstellen)!
- Die Backup-Strategie ist gewissenhaft zu wählen!
- Jedes Backup bzw. dessen Logdatei muss zumindest auf Fehler und Warnungen fortlaufend beobachtet werden!
