Methoden - net-tex.de ? Stefan Schumacher Methoden Zur Datensicherung Strategien und Techniken fr

  • Published on
    27-Jan-2019

  • View
    212

  • Download
    0

Transcript

Stefan SchumacherMethodenZurDatensicherungDer AutorStefan Schumacher ist geschftsfhrender Direktor des Magdeburger In-stituts fr Sicherheitsforschung und gibt zusammen mit Jan W. Meine dasMagdeburger Journal zur Sicherheitsforschung heraus.Er befasst sich seit ber 15 Jahren mit Fragen der Informations- und Unter-nehmenssicherheit und erforscht Sicherheitsfragen aus pdagogisch/psychologischerSicht. Seine Forschungsergebnisse stellt er regelmig auf internationalenFachkongressen der ffentlichkeit vor.Darber hinaus bert er Unternehmen bei der Umsetzung von Sicherheits-manahmen und der Etablierung unternehmensweiter IT-Sicherheitsstrategienmit seiner Unternehmensberatung http://www.kaishakunin.com.http://www.kaishakunin.comStefan SchumacherMethodenZurDatensicherungStrategien und Techniken fr NetBSDInklusive eines Kapitels zu PostgreSQLwww.net-tex.dewww.cryptomancer.deMagdeburg, den 15. Mai 2011http://www.net-tex.de/http://www.net-tex.de/http://www.magdeburg.de/MadeinGermany 2003, 2004, 2005, 2006, 2007 Stefan SchumacherAlle Rechte verbleiben beim Urheber.NetBSD and pkgsrc sind eingetragene Warenzeichen der NetBSD FoundationSolaris und OpenSolaris sind eingetragene Warenzeichen von SUN MicrosystemsHP-UX ist ein eingetragenes Warenzeichen von Hewlett-PackardBSDi ist ein eingetragenes Warenzeichen von Berkeley Software Design, Inc.UNIX ist ein eingetragenes Warenzeichen von The Open Group/X Open.CERT is a registered trademark and service mark of Carnegie Mellon University.Microsoft Windows is a registered trademark and service mark of Microsoft.registered trademark ist ein eingetragenes Warenzeichen von Registered Trademarking.Alle Rechte verbleiben beim jeweiligen Inhaber, alle Warenzeichen bei ihren Besitzern. SmtlicheUrheberrechte werden in vollem Umfang anerkannt.2. Auflage 2007Dies ist Version 1.132 mit 107 Seiten, kompiliert am 15. Mai 2011 mit pdfLATEX3.141592-1.21a-2.2 (Web2C 7.5.4).Es ist nicht genug, zu wissen, man mu auch anwenden;es ist nicht genug, zu wollen, man mu auch tun.GoetheINHALTSVERZEICHNISQuellcode- und Befehlsverzeichnis 111 vorwort 151.1 Danksagung 151.2 Vortrge 161.3 Warnung 161.4 Urheberrechtshinweis 16i strategie und organisation 172 strategie und organisation 192.1 Definitionen 192.2 Vorbereitung der Strategie 192.3 Inventur 202.4 Bedrohungsszenarien analysieren 202.5 Wichtige Daten finden und organisieren 212.6 Sicherung der Sicherungssysteme 222.7 Organisation der Sicherung 222.7.1 Einweisung der Benutzer 222.7.2 Cronjob vs. Batchjob 232.7.3 Homogene Systeme 232.7.4 Dokumentation der Adminstration 232.7.5 Shellskripte statt Handarbeit 242.7.6 Logdateien erstellen und auswerten 242.7.7 Verifikation der Daten 242.7.8 Den GAU erwarten 242.7.9 Alles sichern 252.7.10 Testsysteme und -lufe 252.7.11 Verschiedene Sicherungskreise 252.7.12 Maximale Archivierungsdauer 252.7.13 Wochenenden und Feiertage beachten 252.8 Dokumentation 262.9 Testen, Testen, Testen 262.10 Verminderung von Ausfllen und Ausfallzeiten 272.11 Datenrettung 283 sicherungsvarianten 293.1 Komplettbackup 293.2 Differentielles Backup 293.3 Inkrementelles Backup 293.4 Dump-Level 293.5 Beispielstrategie 293.6 Komprimierung und Verschlsselung 303.7 Medien 323.7.1 Organisation und Lagerung der Medien 343.8 Prfliste zur Strategie 34ii sicherung einzelner systeme 374 programme automatisieren 394.1 Zeitgesteuert 394.2 Ablaufgesteuert 405 sicherung einzelner systeme 415.1 Tgliche Sicherungsmechanismen im Basissystem 415.2 Das Basissystem sichern 415.3 Filesystem-Snapshots 435.3.1 Praktischer Einsatz 435.3.2 Sicherung eines Snapshots 445.4 dump(8)/dump_lfs(8) und restore(8) 4475.4.1 restore 465.4.2 Dump im Detail 465.5 tar(1) 485.6 star 485.7 cpio(1) 495.8 afio(1) 495.9 pax(1) 495.10 Verzeichnisse synchronisieren mit rsync(1) 505.10.1 MS Windows als Client 515.11 rdiff-backup 515.12 dd(1) 525.13 Ghost for Unix (g4u) 52iii sicherung verteilter systeme 556 sicherung verteilter systeme in netzwerken 576.1 Amanda 576.1.1 Einrichtung des Servers 586.1.2 Einrichtung der Clients 596.1.3 Programme im Amanda-Paket 596.1.4 Praktischer Einsatz 616.2 Bacula 626.2.1 Installation 636.2.2 Konfiguration 636.2.3 Rcksicherung 68iv postgresql 717 sicherung eines postgresql-servers 737.1 Den Datenbankcluster sichern 737.2 Point-in-Time-Recovery 737.3 pg_dump, pg_dumpall und pg_restore 757.4 Replikation 757.4.1 Synchrone Replikation mit Pgpool 76v sonstige programme 798 sonstige programme 818.1 Magnetbnder ansteuern mit mt(1) 818.2 Datenstrme puffern 818.3 Dateien mit split(1) zerlegen 828.4 Dateien mit find(1) finden 828.5 Das kryptographische Dateisystem CFS 838.6 Das kryptographische Pseudogert CGD 838.7 symmetrische Verschlsselung mit mcrypt 838.8 Versionsverwaltung mit CVS 848.9 Dateisystemintegritt prfen 858.10 Prfsummen einzelner Dateien erstellen 85vi der test 879 der test 899.1 Problemfelder 899.1.1 Datumsprobleme 899.1.2 Dateigren 899.1.3 Verschiedene Dateitypen 899.1.4 Zeichenstze 899.1.5 Lcher in Dateien 899.1.6 lange Pfadnamen 909.1.7 Zugriffsrechte 909.1.8 Testgestellung und Testdurchfhrung 909.2 Testergebnisse 919.3 Auswertung 939.3.1 dump 939.4 Fazit 93vii anhang 95a einen einzelnen rechner sichern 97b prfliste zur strategie 101Literaturverzeichnis 103Index 105QUELLCODE- UND BEFEHLSVERZEICHNIS2.1 Daten verifizieren . . . . . . . . . . . . . . . . . . . . . . . . 243.1 Archive komprimieren und verschlsseln . . . . . . . . . . 324.1 Cronjobs um PostgreSQL zu sichern . . . . . . . . . . . . . 394.2 Anacrontab-Beispiel . . . . . . . . . . . . . . . . . . . . . . . 404.3 Jobs zur spteren Ausfhrung vorbereiten . . . . . . . . . . 405.1 Betriebssystem mit g4u sichern . . . . . . . . . . . . . . . . 425.2 Konfigurationsdateien sichern . . . . . . . . . . . . . . . . . 435.3 fssconfig-Optionen . . . . . . . . . . . . . . . . . . . . . . . 435.4 Snapshot mit Dump sichern . . . . . . . . . . . . . . . . . . 445.5 NODUMP setzen . . . . . . . . . . . . . . . . . . . . . . . . 455.6 Sicherung mit dump . . . . . . . . . . . . . . . . . . . . . . 455.7 dump-Befehl fr mehrere Volumes . . . . . . . . . . . . . . 455.8 Dump im Netzwerk . . . . . . . . . . . . . . . . . . . . . . . 465.9 Zwei Dumps mit restore zurckspielen . . . . . . . . . . . 465.10 einzelne Dateien mit restore zurckspielen . . . . . . . . . 465.11 Protokoll einer Dump-Sicherung . . . . . . . . . . . . . . . 475.12 Dateien mit tar archivieren und entpacken . . . . . . . . . 485.13 Dateien mit cpio sichern . . . . . . . . . . . . . . . . . . . . 495.14 Sicherung und Rcksicherung mit pax . . . . . . . . . . . . 495.15 rsync-Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . 505.16 /etc/powerd/scripts/power_button . . . . . . . . . . . . . 505.17 cwRsync auf Windows einsetzen . . . . . . . . . . . . . . . 515.18 Windows-Programme zeitgesteuert ausfhren . . . . . . . 515.19 rdiff-backup . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.20 Daten mit dd schreiben . . . . . . . . . . . . . . . . . . . . . 525.21 Festplatten-Images mit g4u erstellen . . . . . . . . . . . . . 536.1 Spoolplatten fr Amanda definieren . . . . . . . . . . . . . 596.2 dumptypes in amanda.conf definieren . . . . . . . . . . . . 606.3 Zu sichernden Pfade in der disklist festlegen . . . . . . . . 606.4 Amanda-Server-Dienste starten . . . . . . . . . . . . . . . . 606.5 Amanda-Client-Dienste starten . . . . . . . . . . . . . . . . . 606.6 Zugriffsrechte auf dem Client konfigurieren . . . . . . . . . 606.7 Amanda Header vom Band restaurieren . . . . . . . . . . . 626.8 PostgreSQL fr Bacula einrichten . . . . . . . . . . . . . . . 636.9 Bacula per rc.d starten . . . . . . . . . . . . . . . . . . . . . 656.10 Baculas bconsole starten . . . . . . . . . . . . . . . . . . . . . 656.11 Beispiel einer Konfiguration fr Bacula . . . . . . . . . . . . 676.12 Daten mit Bacula rcksichern (1) . . . . . . . . . . . . . . . 687.1 PostgreSQL-Cluster mit dump sichern . . . . . . . . . . . . 737.2 postgresql.conf-Konfig zur Sicherung der Logs . . . . . . . 747.3 PostgreSQL-Datenbankcluster und WALs sichern . . . . . . 747.4 PostgreSQL-Datenbanken sichern . . . . . . . . . . . . . . . 757.5 Rckspielen von PostgreSQL-Sicherungen . . . . . . . . . . 757.6 Pgpool-Konfiguration fr die Replikation . . . . . . . . . . 778.1 Bnder mit mt manipulieren . . . . . . . . . . . . . . . . . . 818.2 mt(1)-Optionen . . . . . . . . . . . . . . . . . . . . . . . . . . 818.3 Datenstrme puffern . . . . . . . . . . . . . . . . . . . . . . 828.4 Dateien zerlegen und zusammensetzen . . . . . . . . . . . 828.5 Dateien mit find(1) finden . . . . . . . . . . . . . . . . . . . 838.6 eine CGD-Partition verschlsselt dumpen . . . . . . . . . . 838.7 symmetrische Verschlsselung mit mcrypt . . . . . . . . . 848.8 Datei mit mcrypt entschlsseln . . . . . . . . . . . . . . . . 848.9 Fingerabdruck eines Systems mit mtree erstellen . . . . . . 858.10 Beispiel eines mtree-Reports . . . . . . . . . . . . . . . . . . 85118.11 Dateisystem mit Fingerabdruck vergleichen . . . . . . . . . 858.12 Ergebnisse eines Dateisystemvergleichs . . . . . . . . . . . 868.13 Dateien mit SHA1 vergleichen . . . . . . . . . . . . . . . . . 869.1 Testgestellung fr den Belastungstest . . . . . . . . . . . . . 91A.1 Shellskript fr Dump (1/3) . . . . . . . . . . . . . . . . . . . 97A.2 Shellskript fr Dump (2/3) . . . . . . . . . . . . . . . . . . . 98A.3 Shellskript fr Dump (3/3) . . . . . . . . . . . . . . . . . . . 99TABELLENVERZEICHNISTabelle 1 Wochensicherung mit Leveln 30Tabelle 2 Datenmenge einer Komplettsicherung 30Tabelle 3 Datenmenge einer Inkrementellsicherung 30Tabelle 4 Datenmenge einer Differentiellsicherung 31Tabelle 5 Trme-von-Hanoi-Algorithmus 31Tabelle 6 Datenverteilung im Hanoi-Algorithmus 32Tabelle 7 Vergleich von Sicherungsmedien 34Tabelle 8 Prfliste zur Strategie 35Tabelle 9 Dumplevel fr einen Einzelrechner 43Tabelle 10 Baculas PostgreSQL-Datenbank 64Tabelle 11 Baculas Table public.file 64Tabelle 12 Baculas Table public.filename 66Tabelle 13 Baculas bconsole-Befehle 66Tabelle 14 Daten mit Bacula rcksichern (2) 69Tabelle 15 Auswertung von star und Bacula 92141VORWORTDieses Dokument stellt Strategien und Konzepte zur Datensicherung voneinzelnen Rechnern und verteilten Systemen vor. Es werden mgliche Si-cherungskonzepte eingefhrt und diskutiert. Verfgbare Programme imBasissystem und Lsungen von Drittanbietern werden vorgestellt und eini-ge davon mit einem Zuverlssigkeitstest berprft. Der Einsatz geeigneterProgramme wird an Beispielen gezeigt. Weiterhin werden Sicherungsmg-lichkeiten und Replikationsmethoden fr PostgreSQL vorgestellt.Im ersten Teil wird die Strategie und Organisation der Datensicherungbeleuchtet. Was muss wie organisiert werden, damit meine Datensicherungauch wirklich klappt? Hierbei geht es darum eine Strategie zu erstellen, indem man Bedrohungsszenarien analysiert, zu sichernde Daten bestimmt unddie beste Sicherungsvariante festlegt um die Sicherungsstrategie korrekt zuimplementieren.Der zweite Teil stellt Programme vor, mit denen einzelne Rechner oderauch kleinere Netze bspw. von Kleinen und Mittleren Unternehmen, Arbeits-gruppen oder Privatpersonen, gesichert werden knnen. Insbesondere dieSicherungsprogramme des Basissystems werden vorgestellt und besondersdump(8) nher untersucht und diskutiert.Der dritte Teil stellt Programme vor, die speziell fr grere Netze entwi-ckelt wurden. Dabei handelt es sich um Amanda und Bacula.Der vierte Teil behandelt PostgreSQL bezglich Datensicherung mit denmitgelieferten Werkzeugen zur logischen Datensicherung, den Einsatz derWrite-Ahead-Logs fr Point-In-Time-Recovery und Replikationsmethodenmit Pgpool um die Ausfallsicherheit eines PostgreSQL-Servers zu erhhen.Im fnften Teil werden Programme vorgestellt, die nicht direkt der Daten-sicherung dienen, aber ntzlich sind.Im sechsten Teil werden die Ergebnisse eines Zuverlssigkeitstest fr Siche-rungsprogramme vorgestellt und analysiert. Elizabeth D. Zwicky hat bereits1991 und wiederholt 2003 Sicherungsprogramme auf ihre Zuverlssigkeitund Robustheit getestet. Ich habe diesen Test auf NetBSD mit verschiedenenProgrammen aus dem Basissystem und weiteren Anwendungen, die in dieserAnleitung vorgestellt werden, wiederholt. Es wird die Testgestellung und-durchfhrung beschrieben, die Ergebnisse werden in tabellarischer Formprsentiert und anschlieend bewertet.Im siebenten und letzten Teil befinden sich die Anhnge, wie Skripte,Index und Bibliographie.1.1 danksagungDank fr Korrekturen und Anregungen geht an: Peter Eisentraut, Hubert Feyrer, Jrgen Hannken-Illjes, Matthias Scheler, #netbsd im IRCnet news://de.comp.os.unix.bsd1.4. Urheberrechtshinweis1.2 vortrgeDieser Artikel ist die Grundlage verschiedener Vortrge und Verffentlichun-gen: Magdeburger Linux-User-Group, Themenabend am 28.02.2006 in Mag-deburg Chemnitzer Linux-Tage, 04. und 05. Mrz 2006 in Chemnitz Frhjahrsfachgesprch 2006 der German Unix User Group, 23. und24. Mrz 2006 in Osnabrck. Zu dieser Veranstaltung gibt es einenTagungsband geben, in dem eine stark gekrzte Fassung dieses Artikelenthalten ist. Magdeburger Linux-User-Group, am 20.05.2006 in Magdeburg Sicherung verteilter Systeme mit Bacula, GUUG UpTimes 04/2006 Sicherung verteilter Systeme mit Bacula, LinuxTag-2007-Konferenz-DVD PostgreSQLs Datenbestnde sichern, GUUG UpTimes 02/20071.3 warnungIch habe diesen Artikel sorgfltig recherchiert und wei im Allgemeinenwovon ich rede. Trotzdem gewhre ich diese Informationen nur auf eigeneGefahr, da das Kapitel der Datensicherung sehr komplex ist und ich wederalle Flle und Besonderheiten kennen noch bercksichtigen kann.Wenn ein professionelles Datensicherungsverfahren notwendig ist, Sie abernicht wissen wie es fehlerfrei umgesetzt werden kann, besorgen Sie sichprofessionelle Hilfe. Das ist in der Regel billiger als ein Datenverlust.Fragen werde ich in der Regel beantworten, es bietet sich aber auch an dieNetBSD-Mailinglisten oder das Usenet (de.alt.comp.os.unix.bsd) zu benut-zen.1.4 urheberrechtshinweisSmtliche Rechte am Werk verbleiben beim Urheber. Weitergabe des unver-nderten Artikels ist gestattet und erwnscht, Wiedergabe in kommerziellenMedien bedarf der Genehmigung des Autors. Zitate gem den blichenRegeln sind erwnscht.16Teil ISTRATEGIE UND ORGANISATION2STRATEGIE UND ORGANISATIONNiemand will Backup. Alle wollen Restore.(Kristian Khntopp zitiert einen Vertriebler)2.1 definitionenEin Backup ist die Sicherung relevanter Daten um diese vor Verlust oderBeschdigung zu schtzen. Es ist ein Sicherungssystem fr den Fall desVerlusts der Daten. Im allgemeinen Falle ist eine Datensicherung nicht mitder Archivierung der Daten gleichzusetzen, da in der Regel nur eine Mo-mentaufnahme des Datenbestandes gesichert wird. Ist eine Archivierung desDatenbestandes notwendig1, kann dies ber spezielle Archivierungsprogram-me erfolgen, oder in dem die Datensicherungen selbst archiviert werden.Eine weitere Mglichkeit Daten vor Verlust zu schtzen ist die Spiegelungdieser auf andere Systeme.2.2 vorbereitung der strategieDa die Organisation einer Sicherungsstrategie uerst komplex ist, ist esnotwendig eine umfassende Anforderungsanalyse vorzunehmen und diegewonnenen Erkenntnisse umzusetzen. Hierzu gilt es einen Notfallplan2 zuerstellen, der das Fundament fr die Sicherungsstrategie bildet.Die einzelnen Schritte umfassen:1. Inventur2. Bedrohungsszenarien analysieren3. Wichtige Daten finden4. Sicherungssysteme sichern5. Dokumentation6. TestenAm einfachsten ist es, den Plan so aufzustellen, wie es im Idealfall (alsoohne technische Einschrnkungen) mglich wre. Anschlieend passt manden Idealplan an die reale Situation an, in dem man bspw. die Sicherungs-zyklen an die verfgbaren Zeitfenster anpasst. Steht der Plan und seineImplementierung, gilt es ihn zu testen, zu testen, zu testen und zu warten.Denn die zugrundeliegende Umgebung verndert sich und ebenso wie Si-cherheitsstrategien, muss der Plan stetig an die neue Situation angepasstwerden. Daher empfiehlt es sich, in der Regel alle sechs Monate, den Plan zuberprfen und gegebenenfalls anzupassen.Von vornherein sollten Sie sich bewusst sein, das eine Datensicherungsstra-tegie lebt. Sie mssen regelmig ihre Strategie und Taktik berprfen undgegebenenfalls berarbeiten. Hierzu bietet sich beispielsweise der sogenanntePDCA-Zyklus an.PDCA steht fr:1 bspw. 239 Abs. 4 Satz 2 HGB Die Handelsbcher und die sonst erforderlichen Aufzeichnungenknnen auch in der geordneten Ablage von Belegen bestehen oder auf Datentrgern gefhrt wer-den, soweit diese Formen der Buchfhrung einschlielich des dabei angewandten Verfahrens denGrundstzen ordnungsmiger Buchfhrung entsprechen. Bei der Fhrung der Handelsbcher undder sonst erforderlichen Aufzeichnungen auf Datentrgern mu insbesondere sichergestellt sein,da die Daten whrend der Dauer der Aufbewahrungsfrist verfgbar sind und jederzeit innerhalbangemessener Frist lesbar gemacht werden knnen. Abstze 1 bis 3 gelten sinngem.2 Neudeutsch auch gerne als Disaster Recovery Plan bezeichnet.http://www.iks-jena.de/mitarb/lutz/usenet/Fachbegriffe.der.Informatik.html2.4. Bedrohungsszenarien analysierenplan Planen Sie den gesamten Prozess der Datensicherung von vornherein.do Setzen Sie die Datensicherungsstrategie gem Plan um.check berprfen Sie die umgesetzte, reale, Datensicherung mit den ge-planten, idealen, Werten. Durch diesen Soll/Ist-Abgleich knnen SieSchwachstellen und Probleme aufdecken.act Korrigieren Sie die erkannten Schwachstellen und Probleme aus demCheck-Schritt. Fhren Sie dazu wieder den Plan-Schritt aus und arbeitensie den kompletten Zyklus erneut ab.Wichtig ist hierbei, dass Sie ihre Datensicherungsstrategie ber den gesam-ten Lebenszyklus hinweg berwachen und verbessern. Der PDCA-Zyklusmuss dazu zyklisch durchgefhrt werden deswegen heit er auch Zyklus.berprfen Sie ihr System regelmig auf Fehler oder Probleme. Tun Siedies insbesondere vor Vernderungen, wenn Sie beispielsweise Hardwareoder Software ersetzen, austauschen oder erweitern.2.3 inventurZiel der Inventur ist es, einen berblick ber die eingesetzten Systeme zubekommen. Dabei ist es notwendig zu katalogisieren, welche Hardware, Be-triebssysteme, Anwendungsprogramme und Dienste auf welchen Maschinenlaufen. Anhand dieser Inventur knnen Anforderungen an die Sicherungs-software festegelegt werden.Existiert schon ein Inventar, idealerweise in einer Datenbank oder einemspeziellen Inventurprogramm, kann dieses um die Informationen bezgl.der Sicherung erweitert werden. Falls noch kein Inventar besteht, solltebeim Erstellen eines Neuen auf die Erfassung der notwendigen Daten zurOrganisation der Sicherung geachtet werden.2.4 bedrohungsszenarien analysierenWodurch werden meine Daten bedroht? und Wie kann ich mich vor diesenBedrohungen schtzen? lauten die Fragestellungen zu den Bedrohungen.In der Regel gibt es bestimmte Fehlertypen/Bedrohungen, die jeweils eineeigene Sicherungsstragie erfordern:1. BenutzerfehlerDer Benutzer lscht oder verflscht Dateien. Hier muss die letztevorhandene Version zurckgespielt werden. Dieser hufige Fehler er-fordert eine Archivierung der Daten oder Sicherungsbnder.2. AdministratorenfehlerIst in der Regel eher selten, wenn er aber vorkommt, dann richtig.Schlielich kann sich root nicht nur einfach ins Knie schieen, sondernbeide Beine wegblasen. Hier hilft meist nur die Rcksicherung deskompletten Systems, daher sollte man das gesamte System bspw. mitSnapshots sichern.3. Systemfehlera) Festplatte defektLeider auch recht hufig, reit dies meist alle Daten (und oftdas gesamte System) in den Tod. Hier helfen Sicherungen aufWechselmedien, andere Rechner oder RAID-Systeme.b) DateisystemkorruptionHier helfen nur archivierte Sicherungen, da sich ein Fehler auf dieSpiegel bzw. Sicherungen fortpflanzt.204. elektronischer Einbruch/Vandalismus/DiebstahlEinbruch auf elektronischem Wege und daraus resultierende Vernich-tung der Daten3 erfordert eine Rcksicherung der Daten. Im Falleschleichender Korruption4 sind auch hier wieder Archive notwendig.5. herkmmlicher Einbruch/Vandalismus/DiebstahlWas ist wenn jemand einbricht und alle Rechner klaut? Hier hilft dieletzte Datensicherung weiter, aber wurde die auch gestohlen odervernichtet?6. Naturkatastrophen/Hhere GewaltGlcklicherweise wird Deutschland nicht von Wirbelstrmen oder Erd-beben5 heimgesucht, aber Fluten sind an gewissen Standorten schoneine Gefahr. Weiterhin knnen auch andere Gefahren lauern, wie Flug-zeugabstrze/-einschlge, Erdrutsche, Grobrnde oder Unglcke inbenachbarten Unternehmungen (Chemiewerk, E-Werk, Raffinierie).Was passiert also wenn Gebude/Stadtteil/Stadt ausradiert werdenund das Unternehmen die Daten noch bentigt? Existieren Sicherungenan anderen Orten? Hier sollte entsprechend dem GefahrenpotentialSicherungsbnder ausgelagert werden, bspw. in andere Filialen. Eben-so mglich ist eine Spiegelung/Replikation der Datenbestnde aufentfernte Systeme.2.5 wichtige daten finden und organisierenAls erster Schritt ist es notwendig, alle zu sichernden Daten zu finden. Diessind in der Regel alle Daten, deren Verlust nicht akzeptabel ist.Dies hat drei Grnde: nicht wiederherstellbare DatenDie Daten sind bei Verlust nicht wiederherstellbar, da sie bspw. an einenbestimmten Zeitpunkt gebunden sind6 oder die beteiligten Programme/ Bearbeiter nicht mehr verfgbar sind wirtschaftlicher TotalschadenDie Daten sind zwar rekonstruierbar, der Aufwand dafr, oder dieNichtverfgbarkeit, bersteigt monetr den Aufwand der Datensiche-rung. SystemdatenAuf einem System liegen nicht nur einfach Daten vor, sondern esexistiert mindestens ein Betriebssystem und in der Regel auch nochweitere Programme bzw. Dienste. Es empfiehlt sich auch diese Datenzu sichern. Moderne Sicherungsmedien stellen gengend Platz frBetriebssystemdateien zur Verfgung. Kann, oder mchte, man Be-triebssystem und Anwendungen nicht sichern, sollte man zumindestderen Konfigurationsdateien sichern.Eine finanzielle Bewertung der Daten hilft auch festzustellen, ob der Aufwandfr die Datensicherung den Wert der Daten bersteigt.Im Allgemeinen bietet es sich an Datenbestnde aus Anwendungspro-grammen zu sichern, bspw. Datenbanken oder CAD-Systemen. Desweiterensollten die Homeverzeichnisse der Benutzer regelmig gesichert werden.Konfigurationsdateien oder modifizierte Programme sollten einmalig bzw.nach Vernderungen gesichert werden.3 Die Daten mssen nicht unbedingt gelscht worden sein, aber sind sie noch integer?4 Wurden Daten manipuliert? Wenn ja, wann?5 Manchmal ist aber auch die Krisenreaktion der Behrden gefhrlicher als das eigentlichUnglck.6 z. B. Patientendaten, Logdateien, Versuchsprotokolle212.7. Organisation der SicherungUm die Datensicherung zu erleichtern, sollten die erzeugten bzw. verwen-deten Dateien systematisch abgelegt werden und in Mehrbenutzerumgebun-gen/Netzwerken die Benutzer in die Struktur der Verzeichnisse (Was wirdgesichert?) eingewiesen werden.Bei der Organisation der Daten sollte man auch deren Sicherung im Blickhaben. Hat man Daten, die nicht oft verndert werden, sollte man diese so inVerzeichnissen ablegen, da die Sicherung vereinfacht wird. Meist umfasstdies Bilder, Fotos, Audiodateien oder Filme, die lediglich ein- oder zweimalauf CD oder DVD gebrannt werden mssen und nicht im regelmigenSicherungszyklus erfasst werden mssen.Einige Programme legen Daten in Systempfaden und/oder im Homever-zeichnis des Benutzers ab. Werden nur die Homeverzeichnisse gesichert,sollte man nderungen oder neue Dateien nur im Homeverzeichnis ablegen.Ein Beispiel dafr ist LATEX, das standardmig die Pakete unter /usr/pkg/share/texmf ablegt. Zustzlich kann man auch fr jeden Benutzerein eigenes Verzeichnis unter \textasciitilde/texmf anlegen. Werden dieHomeverzeichnisse regelmig gesichert, bietet es sich an die eigenen TEX-Pakete im Homeverzeichnis abzulegen.Weiterhin ist es nicht notwendig Dateien zu sichern, die sich aus anderenDateien erzeugen lassen. Dies umfasst beispielsweise PDF-Dateien, die mitLATEX erzeugt werden. Es gengt die TEX-Dateien zu sichern. Oder Binaries,deren Quellcode gesichert wird, Fotos die fr eine Webseite verkleinert undaufbereitet wurden etc. pp.2.6 sicherung der sicherungssystemeEinige Sicherungssysteme, insbesondere solche fr Netzwerksysteme wieAmanda oder Bacula, verwenden einen Index. In diesem Index7 werdenalle Metadaten zur Sicherung abgelegt. Also Daten zu wann wurde welcheDatei von welchem Client in welcher Version auf welches Band gesichert.Dieser Index ist also wichtig wenn man eine Rcksicherung einer bestimmtenVersion durchfhren muss. Ohne den Index kann man zwar in der Regel nochdie Bnder von Hand zurckspielen, dies ist aber bei einer gren Anzahl vonBndern recht mhselig. Daher sollte zwingend auch das Sicherungssystemselbst gegen Ausflle und Verlust gesichert werden. Welche Daten hierbeizu sichern sind, hngt vom verwendeten Softwarepaket ab. Verwendet maneigene Skripte, die bspw. einen Katalog der gesicherten Dateien erstellen,sollte dieser ebenfalls gesichert werden.2.7 organisation der sicherungHat man ein Netzwerk aus heterogenen Rechnern zu sichern, sollte manbereits bei der Einrichtung bzw. der Administration einige Punkte beachten.2.7.1 Einweisung der BenutzerInsbesondere in Netzwerken, in denen nur Teile der Clients gesichert werden,ist es wichtig die Benutzer der Systeme ber die Strategie zu unterrichten.Dabei ist darauf zu achten da Anwenderdaten von den Benutzern in Ver-zeichnissen abgespeichert werden, die auch gesichert werden. Gegebenenfallsmuss man hier mit sozialen Manahmen (Richtlinien, Abmahnungen, LARTsetc.) nachhelfen.Drfen die Benutzer auf den Clients selbstndig Programme installieren,muss bereits im Vorfeld dafr gesorgt werden, da deren Anwendungsdatenebenfalls mitgesichert werden. Ist dies nicht mglich, muss ein Prozedereinstalliert werden, da in solchem Falle die Sicherungsmechanismen anpasst.7 Logdateien bei Amanda, eine Datenbank bei Bacula222.7.2. Cronjob vs. Batchjob2.7.2 Cronjob vs. BatchjobWenn man einzelne Systeme sichern mchte, kann man dies bspw. nachtsper Cron erledigen. Dabei sollte man aber beachten, da die entsprechendenSkripte robust sind und Toleranzen einplanen. Kommt es nmlich dazu, dassich die Laufzeit der Skripte verschiebt, kann unter Umstnden der gesamteSicherungsalgorithmus fehlschlagen.Ein Beispiel aus der Praxis:In einem Unternehmen sollten vier kleinere Arbeitsgruppenserver mit ver-schiedenen Unixvarianten gesichert werden. Dazu stand ein lterer Rechnermit Spoolingplatte und Streamer zur Verfgung. Nchtlich sollten die vierServer ihre Daten per dump und SSH-Tunnel auf den Spoolserver schie-ben, der diese danach auf ein Streamerband schreibt. Da alle Rechner imselben Raum standen, wurden sie ber einen einfachen Switch extra fr dieSicherung mit TBase100 verkabelt. Ein Cronjob auf den vier Servern startetemit einer Stunde Abstand den Dump-Lauf und auf dem Spoolingserver dieendgltige Sicherung auf Band. Da das Backupnetzwerk eben nur fr dasBackup genutzt wurde, bemerkte niemand in der Firma da ein Port amSwitch massive Hardwareprobleme entwickelte und daher die Sicherungber das Netzwerk extrem langsam wurde. Zu dem Zeitpunkt als der Spoo-lingserver per Cron begann die Daten auf Band zu schreiben, lieferte derdritte Server seine Sicherung immer noch auf die Spoolingplatte ein. DerSpoolingserver verwendete zwar dump um das Band zu schreiben, so dadie anderen Sicherungen fehlerfrei waren, das Archiv vom dritten Serverwar aber defekt. Das ganze fiel erst auf, als ein Admin frher als gewhnlichin der Firma auftauchte und bemerkte da der Sicherungsprozess noch luft.Nachdem der Netzwerkfehler behoben war, wurde das Skript abgendert.Und zwar so, da nchtlich per Cron auf dem Spoolingserver ein Shellskriptanlief, das nacheinander die Sicherungslufe auf den Servern anwarf underst nach erfolgreichem Abschluss dieser Sicherungen die Archive auf Bandschrieb. Abschlieend wurden die Logdateien aller Dump-Lufe per Mail andie Administratoren weitergeleitet und von diesen auch gelesen.2.7.3 Homogene SystemeMeist ist es zwar nicht mglich alle Systeme homogen aufzusetzen, mansollte sich aber bemhen uniforme Systeme einzurichten und zu benut-zen. Dazu gehrt auch, da man bspw. die Systemdienste gleich einrichtet,Benutzerdaten mglichst zentral verwaltet und gleiche Hardware einsetzt.Dies vereinfacht die Administration des Netzes und damit auch die Siche-rung bzw. Rcksicherung im Falle eines Falles.2.7.4 Dokumentation der AdminstrationDie normalen administrativen Aufgaben sollten ebenso dokumentiert wer-den wie das Sicherungssystem selbst. Es ist ntzlich den Arbeitsablauf zudokumentieren, da man so auch spter noch nachvollziehen kann, was wannwarum wie gemacht wurde. Aber besonders nach einem Systemausfall undder Systemrestaurierung ist es ntzlich, Aufzeichnungen ber das System zuhaben, da man bestimmt das ein oder andere Detail vergessen und die Datendazu nicht gesichert hat. Dies ist insbesondere dann wichtig, wenn mehrereAdministratoren in der EDV arbeiten. Man kann beispielsweise Blog-Systemeoder Wikis verwenden, um die Arbeit in Gruppen aufzuzeichnen. Dann darfman aber nicht vergessen, den Datenserver zu sichern :-)232.7. Organisation der Sicherung2.7.5 Shellskripte statt HandarbeitMeist kommt es vor, da man einzelne Handgriffe wirklich manuell erledigt sei es bspw. das Anlegen neuer Benutzer oder das Warten des Datenbank-servers. Meist kann man die Befehle dazu auswndig und gibt sie von Handein. Praktischer ist es aber, diese Befehle in ein Shellskript zu gieen undggf. per Cron ausfhren zu lassen. Dies hat den Vorteil, da die Skripte mit-gesichert werden, also nach einem Systemausfall wiederhergestellt werdenknnen. Auerdem kann man ein Skript leicht kommentieren und somitdokumentieren. Im Zweifelsfalle wissen also auch die Kollegen was auf denMaschinen abluft.2.7.6 Logdateien erstellen und auswertenFr gewhnlich knnen die meisten Sicherungsprogramme Logdateien er-stellen. Dies sollte man auch aktivieren und die erzeugten Protokolleunbedingt lesen. Denn nur so ist sichergestellt, da alle Sicherungslufe auchwie erwartet funktionieren.2.7.7 Verifikation der DatenWann immer Daten bertragen oder bearbeitet werden, kann dabei etwasschief gehen. Daher sollte jedes Programm, das Daten verifizieren kann, diesauch tun.Die Kompressionsprogramme Bzip2 und Gzip untersttzen mit der Option-t die Verifikation der komprimierten Daten.Ansonsten kann man Daten mit Prfsummen wie MD5 oder SHA1 (sieheKap. 8.10) nach der bertragung testen. Komplette Dateisysteme lassen sichmit mtree(8) (Siehe Kap. 8.9) berprfen und vergleichen.1 $ gzip netbsd.gz2 $ root@balmung {48} gzip -t netbsd.gz ; echo $?3 04 $ root@balmung {49} date >> netbsd.gz5 $ root@balmung {50} gzip -t netbsd.gz ; echo $?6 gzip: input not gziped (MAGIC0)7 gzip: netbsd.gz: uncompress failed8 19 $10 $ md5 dump.0 > MD511 $ scp dump.0 stefan@backup:/home/backup/12 $ ssh stefan@backup md5 /home/backup/dump.0 > MD5.113 $ diff MD5 MD5.1Listing 2.1: Daten verifizieren2.7.8 Den GAU erwartenEs wird der Tag kommen, an dem Mond und Sonne verschlungen werden,Ragnark beginnt und das Schicksal der Gtter besiegelt ist. Alle Rechnerwerden in Flammen stehen und ihre Daten verlieren und nur ein kleiner, un-bedeutender Systemadminstrator mit einem Schrank voll Sicherungsbnderwird das Schicksal wenden knnen.Und wehe Ihm, hat er nicht alle bentigten Werkzeuge und seine roteHelden-Strumpfhose bereitliegen.242.7.9. Alles sichernDie Frage ist nicht, ob ein GAU eintreten wird, sondern nur wann ereintritt. Wichtig ist es die Konfiguration aller Rechner und deren Softwarezu kennen. Am besten nicht (nur) als Datei, sondern auch als Ausdruck.Dann bentigt man alle Installationsmedien fr das Betriebssystem undeine Live-CD oder eine Festplatte mit einem eingerichteten NetBSD.Eine Live-CD kann man mit pkgsrc/sysutils/mklivecd selbst erstellen,man sollte dazu einen Kernel verwenden, der alle bentigten Gerte (Lauf-werke, Netzwerkkarten, CGD, RAID, LVM, etc. pp.) untersttzt und allebentigten Pakete (z. B. mcrypt, Amanda) bereitstellen. Alternativ kann manauch eine kleinere Festplatte mit NetBSD einrichten und alle bentigtenProgramme einbinden.2.7.9 Alles sichernDas Sicherungssystem muss nach dem Prinzip Erstmal alles sichern undden Rest ausschlieen angelegt sein. In der Praxis heit dies bspw. da allePlatten, die nach /home gemountet werden, gesichert werden sollen. Diesist besonders praktisch, wenn bspw. ein Kollege eine weitere Platte fr eineArbeitsgruppe als /home/ag einbindet, dann aber vergisst diese Platte imBackupskript nachzutragen. Sichert das Skript allerdings alle Partitionen diein der /etc/fstab nach /home gemountet werden, wird diese neue Partitionautomatisch mitgesichert.2.7.10 Testsysteme und -lufeEs ist allgemein bekannt, das man nicht am Produktivsystem herumschrau-ben sollte, wenn sich dies vermeiden lsst. hnlich wie bei wichtigen Servernsollte auch fr die Sicherungsanlage ein Testsystem bereitgestellt werden, andem Testlufe und Versuche durchgefhrt werden knnen.Auerdem sollte regelmig eine Inventur der Medienbestnde durchge-fhrt werden, in der neben deren Vollstndigkeit auch die Funktionsfhig-keit8 der Laufwerke und Medien getestet wird.2.7.11 Verschiedene SicherungskreiseAus Datenschutz- oder rechtlichen Grnden oder technischen Gegebenheitenkann es notwenig werden das Netzwerk in verschiedene Sicherungskreisezu unterteilen, die entsprechend behandelt werden.2.7.12 Maximale ArchivierungsdauerSo wie der Gesetzgeber fr einige Daten eine Mindestarchivierung vor-schreibt, legt er auch bestimmte Obergrenzen fest. So sind beispielsweiseEintragungen in der Personalakte ber Disziplinarmanahmen nach Eintrittdes Verwertungsverbots9 von Amts wegen zu entfernen und zu vernichten.Das heit auch, das in dieser Frist angelegte Sicherungskopien der Akte zuvernichten sind. Daher kann es sinnvoll sein bspw. die Personalabteilungin einen eigenen Sicherungskreis zu gliedern und auch entsprechend zuarchivieren, da man sonst erfolgreich juristisch belangt werden kann.2.7.13 Wochenenden und Feiertage beachtenIn Unternehmen, in denen nicht rund um die Uhr, oder zumindest jedenTag, gearbeitet wird, wird oftmals nur an den regulren Werktagen gesichert.Dies kann problematisch werden, wenn doch einmal an einem Feiertag oder8 Bnder sollten bspw. mindestens einmal pro Jahr durchgespult werden.9 Meist zwei Jahre.252.9. Testen, Testen, TestenWochenende gearbeitet wird. Denn wie es Murphys Law will, wird es danngarantiert zu einem Datenverlust kommen.Sind die entsprechenden Rechner auch auerhalb der Werkszeiten an,knnen sie ber das Netzwerk gesichert werden. Falls nicht, sollte in denNetzwerkrichtlinien und Benutzerordnungen auf die fehlende Sicherunghingewiesen werden. Ergreifen Sie Manahmen, die den Benutzern eineSicherung der Daten ermglicht. Dies kann bspw. ber CD-Brenner, ZIP-Disketten oder USB-Sticks erfolgen. Falls Wechseldatentrger verboten sind,kann man bspw. einen Fileserver bereitstellen, auf den die Mitarbeiter Kopiender zu sichernden Dateien ablegen knnen.2.8 dokumentationEs muss sichergestellt werden, da das gesamte Prozedere auch von anderenAdministratoren als dem Implementierenden ausgefhrt werden kann. Daherist es lebenswichtig, eine funktionierende Dokumentation des gesamtenSystems zu erstellen. Idealerweise sollte hier der gesamte Entwurf und diegesamte Implementierung des Systems formal dargelegt werden zustzlichaber auch eine einfache und leicht verstndliche Schritt-fr-Schritt-Anleitungzur Rcksicherung von Daten.Anhand der Dokumentation sollte ein Administrator, der bisher noch nichtmit dem Sicherungssystem gearbeitet hat, in der Lage sein eine Rcksiche-rung durchzufhren. Es ist unerlsslich mehr als eine Person im Sicherungs-system zu unterweisen, denn schlielich kann diese nicht rund um die Uhrverfgbar10 sein.Ntzlich ist es, die Einweisung in das Sicherungssystem mit der Doku-menation als Testlauf anzusetzen. Hierbei sollten weitere Administratorenanhand der Dokumentation eine Rcksicherung auf ein Testsystem durch-fhren, wobei der Entwickler des Systems lediglich beobachtet und nichteingreift. So kann bequem die Qualitt der Dokumentation (Versteht manwas dort beschrieben wurde? Fehlen Teile?) und die Funtionstchtigkeitdes Sicherungssystems (Gelingt die Rcksicherung?) berprfen. Nach Ab-schluss der Rcksicherung wird eine Manverkritik durchgefhrt, in dergemeinsam Schwchen und Fehler des Systems und der Dokumentationdurchgesprochen und abgestellt werden.Wie hoffentlich schon ersichtlich wurde, ist es wichtig nicht nur einen Ad-ministrator in das Sicherungssystem einzuweisen, sondern auch hier mehrerePersonen auszubilden. Insbesondere in kleinen bis mittleren Unternehmun-gen, die keine eigentliche EDV-Abteilung sondern nur einen Teilzeit-Adminhaben, ist dies oftmals ein Problem. Lsungen lassen sich dann evtl. berexterne Berater finden, die im System eingewiesen und vertraglich entspre-chend in den Ablauf eingebunden werden.2.9 testen, testen, testenEin Sicherungssystem, das nicht unter realen Bedingungen getestet wurde,kann und darf nicht als funktionierend betrachtet werden. Dies hat mehrereGrnde: Der Administrator muss in der Lage sein die Rcksicherung durchzu-fhren. In der Regel erzeugt ein Systemausfall mit Datenverlust Stress.Wenn dann zustzlich der Chef das Problem am besten gestern gelstsehen will, wird der Administrator zustzlich unter Druck gesetzt.In solch einer Situation muss man aber einen khlen Kopf bewahrenum die Situation nicht weiter eskalieren zu lassen. Daher ist es uner-lsslich, derartige Situationen und Verfahren in Ruhe durchzuspielen,um Sicherheit im Ablauf zu bekommen. Ist man an den Ablauf der10 Freigang auf dem Hof, Ftterungszeiten u. .26Prozedur gewhnt, verringert dies den auftretenden Stress und somitFehlerquellen Es ist nicht sichergestellt, da die Sicherungsstrategie auch wirklichfunktioniert. Man kann zwar versuchen im Entwurfsprozess der Stra-tegie Fehlerquellen zu minimieren, kann dies aber, wie in jedem Ent-wurfsprozess berhaupt, nicht ausschlieen. Nur durch Testlufe lsstsich sicherstellen, das die Prozedur funktioniert und auch wirklich diegewnschten Daten gesichert werden. Daher sollte man verschiedeneTestlufe durchfhren, in denen mgliche Fehler/Situationen betrachtetwerden: Rcksicherung von n einzelnen Dateien Rcksicherung von n Versionen verschiedener Dateien Rcksicherung eines kompletten Dateisystems (eines Clients) undVergleich der Rcksicherung mit dem echten System ein komplettes System (Betriebssystem mit Konfiguration plusAnwendungssoftware und Daten) wieder aufsetzen Rcksicherung einer Archivversion zu einem bestimmten Zeit-punkt in der Vergangenheit (Point-in-Time-Recovery) Rcksicherung eines Systems obwohl der Backup-Server ausgefal-len istEine sehr gute Anleitung zum Thema Datensicherung finden Sie in (Pre-ston, 1999).2.10 verminderung von ausfllen und ausfallzeitenNeben der eigentlichen Datensicherung ist es erstrebenswert Ausflle erst garnicht auftreten zu lassen. Hierzu existieren ebenfalls verschiedene Strategien,wie bspw. hochverfgbare Systeme (HV oder engl. HA) oder Replikation.Wnscht man hochverfgbare Systeme, muss man in entsprechende Tech-nik investieren. Dies setzt unter anderem redundante Bauteile (Netzteile,Laufwerke), zuverlssige Hardware, RAID-Systeme, entsprechende Strom-versorgung und im Betrieb austauschbare Hardware voraus. Auch wennman so unter Einsatz entsprechender finanzieller Mittel ein hochverfgbaresSystem installiert, ist immer noch eine Datensicherung erforderlich.Selbst wenn eine Verfgbarkeit von 99, 99999% (das heit maximal 5,3Minuten Ausfallzeit pro Jahr) erreicht werden kann, ist das System nicht vorBenutzer- und Bedienfehlern oder hherer Gewalt sicher.Bei einer Spiegelung werden Daten idealerweise sofort (also direkt beimSchreiben) auf ein anderes System bertragen. Dies ist bspw. bei RAID-5Systemen der Fall, wo Daten auf mindestens drei Festplatten verteilt werdenund so bei Ausfall einer Platte die Daten integer bleiben.Abzuraten ist hierbei dringendst von RAID-0, dem sogenannten Striping.Hierbei werden zur Geschwindigkeitssteigerung mindestens zwei Festplattenzu einer Logischen zusammengefasst. Bei diesem System multipliziert sichauch die Verfgbarkeit11 beider Fesplatten. Da die Verfgbarkeit immerkleiner Eins ist, wird die Gesamtverfgbarkeit mit jeder weiteren Plattekleiner. Ein System mit 2 Platten, die eine Verfgbarkeit von 99% haben, hateine Gesamtverfgbarkeit von 0,99*0,99=0,98.Eine ideale Form der Spiegelung ist die Replikation eines laufenden Sys-tems auf ein identisches, bereitstehendes Ersatzsystem (hot standby) dasbei Ausfall des Originals sofort einspringen kann. Diese Variante kostetmehr als das Doppelte eines Einzelsystems, auerdem ist sie nur sinnvollwenn der Nutzen den Aufwand rechtfertigt, man also auf entsprechendeHochverfgbarkeit angewiesen ist. Wichtig ist hierbei vor allem auch einerumliche Trennung (mindestens eine Brandschutzschleuse) der Systeme. Da11 Verfugbarkeit = meantime between failuremeantime between failure meantime to repair272.11. Datenrettungbeide Systeme in der Regel rund um die Uhr laufen sind sie den blichenelektrischen Gefhrdungen (Stromausfall, Blitzschlag, Kurzschluss) ausge-setzt und mssen dagegen gesichert werden. Diese Variante hat den Vorteil,das bei ausreichendem Schutz des Ersatzsystems dieses das ausgefalleneSystem mit minimalem Zeitaufwand ersetzen kann. Nachteilig sind hierbeidie Kosten.Besonders im Datenbankenbereich sind schon seit Jahren erfolgreich Repli-kationsmechanismen etabliert. Fr PostgreSQL existieren mehrere Program-me, die synchrone oder asynchrone Replikation ermglichen. Mit einemsynchronen Replikationssystem, wie beispielsweise Pgpool (siehe Kap. 7.4.1,Seite 76), werden alle SQL-Anforderungen auf mehrere verteilte Systemerepliziert, so da der Datenbestand auf mehreren unabhngigen Rechnernvorliegt. Da diese Rechner rumlich getrennt aufgestellt werden knnen,lassen sich die Daten vor einem Totalverlust schtzen.2.11 datenrettungIst es notwendig Daten nach einem Headcrash oder einem Brand wieder-herzustellen, muss man die Daten von den beschdigten Festplatten retten.Hierzu sollte man unbedingt, insbesondere im professionellen Bereich, spe-zialisierte Datenrettungsunternehmen beauftragen. Diese verfgen ber dienotwendige Erfahrung und Technologien um beschdigte Medien wiederher-zustellen.Sind Daten versehentlich gelscht wurden (rm(1), Partitionierung/Forma-tierung) knnen diese u.U. mit Datenrettungsprogrammen (bspw. pkgsrc/sysutils/gpart) wiederhergestellt werden. Dabei sollte man grundstzlichnicht auf dem betroffenen Medium arbeiten, insbesondere Schreibzugrif-fe sind zu verhindern. Alle Datenrettungsversuche drfen nur auf einer1:1-Kopie (siehe Kap. 5.12, S. 52) des Mediums erfolgen.Sollen die Daten (trotz der recht hohen Kosten) von einem Datenrettungs-unternehmen wiederhergestellt werden, sollte man jeglichen Zugriff auf dieMedien unterlassen und die Profis arbeiten lassen.283SICHERUNGSVARIANTENProfis verhalten sich vorhersagbar. Die Amateuresind es, die gefhrlich sind.3.1 komplettbackupEin Komplettbackup sichert alle relevanten Daten. Dies ist in der Regel sehreinfach zu bewerkstelligen, auerdem ist das Zurckspielen der Daten eben-falls recht einfach. Nachteile sind dabei vor allem die Dauer der Sicherungund der bentigte Platz, da auch Daten gesichert werden, die seit dem letztenBackup nicht verndert wurden.3.2 differentielles backupIn Anlehnung an das mathematische auch Delta-Methode genannt. UmPlatz und Zeit zu sparen werden hierbei nur Daten gesichert, die seit demletzten Komplettbackup gendert wurden. Bei der Rcksicherung mussallerdings die Reihenfolge der Bnder beachtet werden, im allgemeinenbentigt man hierzu die letzte Komplettsicherung1 und das letzte Tagesband.3.3 inkrementelles backupHier werden nur die Dateien gesichert, die sich seit dem letzten Inkre-mentalbackup gendert haben. Bei der Rcksicherung muss ebenfalls dieReihenfolge beachtet werden, dafr ist bei der Sicherung noch weniger Platzund Zeit als beim Differentialbackup erforderlich.3.4 dump-levelFr gewhnlich untersttzen ordentliche Sicherungsprogramme den Ein-satz sogenannter Level, die mittels einer Zahl die zu sichernden Dateienangeben. Auf dem Level n werden alle Dateien gesichert, die seit der Siche-rung mit n 1 verndert wurden.Vorteil ist hierbei die Zeit- und Platzersparnis, Nachteil ist die aufwndi-gere Rcksicherung.Man kann hierbei aber auch die Methoden mischen, so ist es beispielsweisepraktikabel montags eine Komplettsicherung mit Level 0 durchzufhren undwerktags, also dienstags freitags, mit Level 1 die Arbeitsdaten der Woche zusichern. Da es auch am Wochenende zu Arbeitseinstzen kommmen kann2,knnen am Sonnabend und Sonntag mit Level 2 die Tagesdaten gesichertwerden.3.5 beispielstrategieEine einfache Beispielstrategie fr einen einzelnen Rechner mit Leveln: Am Montag existiert 1 GB an Daten es werden jeden Tag 100 MB Daten erzeugt am Sonntag liegen 1,6 GB Daten vor1 meist montags oder freitags erstellt2 Vorausgesetzt das Wochenende ist kein normaler Arbeitstag.3.6. Komprimierung und Verschlsselung Sicherungen erfolgen in der Nacht, vor Arbeitsbeginn Sonntag Mittag sei eine Rcksicherung vom Band notwendigTabelle 1 zeigt die verwendeten Dumplevel, die Tabellen 2, 3 und 4 zeigendie anfallende und gesicherte Datenmenge.Mo Di Mi Do Fr Sa SoKomplett 0 0 0 0 0 0 0Differentiell 0 1 1 1 1 1 1Inkrementell 0 1 2 3 4 5 6Tabelle 1.: Wochensicherung mit LevelnMo Di Mi Do Fr Sa SoKomplett 0 0 0 0 0 0 0Tagesration 1 GB 1,1 GB 1,2 GB 1,3 GB 1,4 GB 1,5 GB 1,6 GBGesamt 1 GB 2,1 GB 3,3 GB 4,6 GB 6,0 GB 7,5 GB 9,1 GBTabelle 2.: Datenmenge einer KomplettsicherungMo Di Mi Do Fr Sa SoInkrementell 0 1 1 1 1 1 1Tagesration 1 GB 0,1 GB 0,2 GB 0,3 GB 0,4 GB 0,5 GB 0,6 GBGesamt 1 GB 1,1 GB 1,3 GB 1,6 GB 2,0 GB 2,5 GB 3,1 GBTabelle 3.: Datenmenge einer InkrementellsicherungDie Komplettsicherung sichert jeden Tag alle Daten. Die Rcksicherungerfolgt vom letzten Band, also dem Sonntagsband.Differentiell sichert man jeden Montag alle Daten und dienstags bis freitagsauf Level 1. Die Rcksicherung erfolgt erst mit dem letzten Montagsbandund anschlieend dem letzten Tagesband.In der inkrementellen Sicherung sichert man jeden Montag alle Datenund wochentags inkrementell, also nur Vernderungen zum Vortag. DieRcksicherung erfolgt hier in der Reihenfolge aller Bnder von Montag bisSonntag. Nachteil der Strategie ist, da Dateien in der Regel nur auf einemeinzigen Band gesichert sind, was bei Verlust des Bandes dem Verlust allerDaten des Tages und der darauffolgenden Tage gleichkommt.Daher gibt es noch eine andere, platzsparende Strategie, die an die Trmevon Hanoi angelehnt ist.Diese Strategie (siehe Tab. 5) verteilt einzelne Dateien auf mehrere Bnder,wobei bei diesem Algorithmus aber am wenigsten Platz verschwendet wird.Fr einen gesamten Monat, lsst sich der Algorithmus mit Level-1 Sicherun-gen an den folgenden Montagen erweitern. Vorteil der Strategie ist hierbeidie Sicherung der Dateien auf mehr als ein Medium, ohne jedesmal allessichern zu mssen.Die Verteilung der Dateien auf die Bnder wird in Tabelle 6 illustriert:3.6 komprimierung und verschlsselungOftmals ist es ntzlich ein Archiv zu komprimieren um Platz zu sparen.Jedoch sei hierzu angemerkt, da bei Archivfehlern ein Dekomprimieren der30Mo Di Mi Do Fr Sa SoDifferentiell 0 1 2 3 4 5 6Tagesration 1 GB 0,1 GB 0,1 GB 0,1 GB 0,1 GB 0,1 GB 0,1 GBGesamt 1 GB 1,1 GB 1,2 GB 1,3 GB 1,4 GB 1,5 GB 1,6 GBTabelle 4.: Datenmenge einer DifferentiellsicherungMo Di Mi Do Fr Sa So0 3 2 5 4 7 61 3 2 5 4 7 61 3 2 5 4 7 61 3 2 5 4 7 6Tabelle 5.: Trme-von-Hanoi-Algorithmusgepackten Archive oftmals nicht mehr mglich ist. Daher sollte man die Kos-ten und Nutzen abwgen und die gesicherten Archive jedesmal verifizierenlassen. Ebenso ist es sinnvoll nur gngige Komprimierungsprogramme zuverwenden, um spter wieder an die Daten heranzukommen.Aktuelle Bandlaufwerke untersttzen in der Regel Hardwarekomprimie-rung. Das heit da das Laufwerk vor dem eigentlichen Schreiben der Datendiese in einem eigenen Chip komprimiert. Dieses Verfahren hat den Vorteildie sichernde Maschine nicht weiter zu belasten.Ob man Komprimierungsverfahren einsetzen sollte, hngt von der ent-stehenden Last bzw. Einsparung (Netzwerk ./. CPU ./. Bandbedarf) undvon der Zusammensetzung der Daten ab. Sind die Daten in der Mehrzahl(natrlichsprachige) Texte (Logdateien, Textverarbeitung, Datenbanken mitTexten) ist eine recht groe Kompressionsrate gegeben. Bereits komprimierte(z. B. JPEG, MP3, AVI) oder verschlsselte Datentypen hingegen lassen sichnicht weiter komprimieren.Es ist sinnlos ein verschlsselndes Dateisystem einzusetzen und unver-schlsselte Backups im Schrank liegen zu haben, daher sollten auch Backupsverschlsselt werden. Dies gilt insbesondere dann, wenn die Sicherungsbn-der ausgelagert werden sollen.Zur Komprimierung eignen sich die Standardprogramme gzip und bzip23,da diese relativ weit verbreitet sind und bisher zuverlssig arbeiten.Verschlsseln kann man die Archive sicher mit OpenSSL, GnuPG oder demsymmetrischen Verschlsselungprogramm mcrypt, welches verschiedeneAlgorithmen wie Rijndael, 3DES oder Panama untersttzt.Werden die Archive nicht mittels einer Pipe direkt verschlsselt auf Daten-trger geschrieben, mssen die unverschlsselten Dateien sicher gelscht( gewipet) werden. Dazu gibt es die Option -P fr rm, die Dateien vordem Lschen dreimal berschreibt. Diese Option gengt aber nicht denallgemein anerkannten Regeln der Technik. Daher sollte hierfr dringend einProgramm verwendet werden, das zumindest den US DoD 5220.22-M ECEoder Peter Gutmanns Standard implementiert. In pkgsrc befindet sich dazupkgsrc/security/destroy oder pkgsrc/sysutils/wipe. Empfehlenswertist es allerdings, die unverschlsselten Archive in eine mit CGD verschlssel-te Partition zu schreiben und danach ebenfalls zu wipen. Hierzu kann manauf einzelnen Rechnern eine hinreichend groe /tmp-Partition erstellen, diemit CGD verschlsselt ist.Verwendet man GnuPG zum Verschlsseln der Archive, sollte man aufasymmetrische Verschlsselung verzichten und Symmetrische einsetzen.3 bzip2 erzeugt zwar im Allgemeinen eine bessere Komprimierungsrate, erzeugt dabei aberauch hhere Systemlast und Laufzeiten313.7. MedienWochentag Daten auf dem TagesbandMontag MontagDienstag Montag & DienstagMittwoch Montag & Dienstag & MittwochDonnerstag Mittwoch & DonnerstagFreitag Mittwoch & Donnerstag & FreitagSonnabend Freitag & SonnabendSonntag Freitag & Sonnabend & SonntagMontag 1. Montag - 2. MontagDienstag 2. Montag & 2. Dienstag...Tabelle 6.: Datenverteilung im Hanoi-AlgorithmusDenn fr die Entschlsselung bentigt man sonst wieder den GnuPG-Schlssel was das Archiv unbrauchbar macht, wenn der nicht mehr exis-tiert.1 # dump -0a -f - /etc/ | bzip2 > dump.bz22 # gpg -a -c dump.bz2 && destroy -f -s 7 t dump.bz23 # dump -0a -f - /etc/ | bzip2 | openssl aes-256-ecb \4 -out dump.bz2.enc -e -salt5 # openssl aes-256-ecb -in dump.bz2.enc -d -salt | \6 bunzip2 - | restore -r -f -Listing 3.1: Archive komprimieren und verschlsselnListing 3.1 erzeugt einen Dump, der sofort per bzip2 komprimiert wird.Anschlieend wird der dump mit GnuPG symmetrisch verschlsselt undmit destroy sicher gelscht. Zeile drei erzeugt einen Dump der sofort perPipe an bzip2 zum komprimieren und OpenSSL zum Verschlsseln geschicktwird. Die vierte Zeile ist des Gegenstck zur Dritten, denn hier wird derverschlsselte und komprimierte Dump entschlsselt, dekomprimiert undan restore geschickt.3.7 medienAls Medium eignet sich prinzipiell alles was am Markt erhltlich ist, jedochsollte man einige Vorberlegungen treffen.1. VerlsslichkeitDie Medien mssen zuverlssig sein und auch lngere Archivierungs-perioden problemlos berstehen. Auerdem mssen Lesegerte nochverfgbar sein, um die Sicherungsmedien einlesen zu knnen. Diesist besonders wichtig, wenn Medien ber mehrere Jahre archiviertwerden mssen. Hier sollte man regelmig (bspw. alle sechs Monate)zusammen mit der Inventur prfen ob die ltesten Medien noch lesbarsind und ggf. die Medien auswechseln. Im allgemeinen muss man beider Archivierung sptestens alle Acht bis Zehn Jahre eine kompletteMigration der Medien durchfhren, da die Medien und Lesegerteveraltet sind.2. GeschwindigkeitDas Sicherungssystem muss so schnell wie mglich sein. Dabei sollteman aber auch die Kapazitten des Netzwerks und des Sicherungsser-vers beachten, denn es ist bertrieben, einen 50-MBit-Streamer einzu-setzen, wenn die Sicherung in einem 10-MBit-Netz erfolgt.32Ein weiterer Faktor, der die Geschwindigkeit des Sicherungslaufwerksbeeinflusst, ist ein Bandwechsel. Wenn ein Sicherungslauf auf mehrereBnder verteilt werden muss, senkt die Wartezeit auf das neue Bandden Gesamtdurchsatz des Systems.3. Dauer der Rcksicherung (sog. Time to Data)Wie lange bentige ich um bei einer Rcksicherung an bestimmteDaten zu kommen?Hierbei spielen verschiedene Faktoren eine Rolle, wie Zugriffszeit derMedien aber auch die Organisation der Archivierung selbst.Mehr als 90% aller Rcksicherungen betreffen nur einzelne Dateien,die in lteren Versionen restauriert werden mssen. Der gesamte Zeit-aufwand der Operation besteht daraus, die richtigen Medien mit dergewnschten Version zu finden, einzulegen und die Dateien zurck-zuspielen. Verwendet man hierzu ein automatisiertes System (Index,Bandwechsler) geht dies wesentlich schneller als wenn man die Datenvon Hand zurckspielen muss.Ist man auf besonders schnelle Zugriffszeiten angewiesen, sollte manzur Sicherung hierarchische Speichersysteme4 verwenden.4. KapazittDie anfallenden Datenmengen mssen auf mglichst wenige Medienverteilt werden. Verwendet man einen einfachen Streamer, ist es be-sonders wichtig da alle Daten auf ein Band passen, denn niemandmchte nachts um drei neben dem Streamer Wache schieben.Beachten sollte man auch, dass eine steigende Kapazitt die Zeit zurRcksicherung anhebt, denn ein 10GB Band lsst sich schneller durch-spulen als ein 100GB Band.Aus betriebswirtschaftlicher Sicht ist eine Betrachtung der Kosten uner-lsslich, denn es ist unntig einen 100GB-Streamer mit entsprechendgroen und teuren Medien anzuschaffen, wenn tglich nur 5GB Datenanfallen. Andererseits sollte man auch nicht zu kurz planen, da dieHardware wenigstens die vier Jahre bis zur Abschreibung im Einsatzbleiben sollte.5. KostenDabei darf das System blicherweise nichts Kosten. Denn wozubraucht man schon ein Backupsystem, wenn doch alles prima luft?5Disketten, ZIP-Medien, CD/DVD und Festplatten sind weit verbreitet,billig und von daher gut zur Rcksicherung geeignet. Nachteilig wirkt sichhierbei allerdings die relativ geringe Integritt und die kurze Lebensdauerder Datentrger aus. Relativ kostspielig und langsam, aber dennoch hervor-ragend geeignet aufgrund hoher Kapazitten und exzellenter Integritt undLebensdauer sind Magnetbnder.Es bietet sich auch hier an verschiedene Medien zu nutzen und zu mischen,z. B. ZIP-Disketten oder CDRW/DVDRW fr tgliche Sicherungen.Festplatten knnen aufgrund der hohen Kapazitt und Geschwindigkeitauch zur Datensicherung eingesetzt werden, sollten dann aber als Wechsel-platte ausgefhrt sein und auerhalb der Sicherungslufe offline gelagertwerden.4 Hierbei werden verschiedene Medientypen mit unterschiedlichen Zugriffzeiten eingesetzt.Hufig bentigte Dateien werden auf schnellen Medien gesichert (Festplatte, Magneto-Optische Medien), whrend ltere bzw. seltener bentigte Daten auf entsprechend langsa-meren aber greren Medien (Magnetbnder) gesichert werden. Diese Methode war frher,als Festplatten noch in Megabyte vermessen wurden, sehr beliebt und wird heute noch ineinigen sehr datenintensiven Umgebungen (Grafik-/Videobearbeitung) eingesetzt.5 man Zynismus333.8. Prfliste zur StrategieMedien Verfgbarkeit Geschwindigkeit Haltbarkeit /GBDVD+RW ++ + - 0,3DVD+RAM ++ + ++ 1USB-Stick ++ + + 15,00ZIP250 - 32,00Platten ++ ++ - 0,7Bnder + ++ 1-5,00Tabelle 7.: Vergleich von Sicherungsmedien3.7.1 Organisation und Lagerung der MedienBei groen Datenmengen und niedrigen Migrationszyklen, sowie der Archi-vierung der Medien, ist eine ausgefeilte Organisation der Lagerung notwen-dig.Zuerst ist die Lagerung der Medien ihren physikalischen Bedrfnissenanzupassen. Fr gewhnlich befinden sich in deren Spezifikation Angabenzur besten Luftfeuchtigkeit, Umgebungstemperatur, Luftdruck und so weiterund sofort. Insbesondere magnetische Datentrger sollten vor starken Tem-peraturschwankungen geschtzt werden. Bnder mssen aufrecht stehendgelagert werden, da sich sonst das Magnetband lockern kann und niemandwill Bandsalat bei einer Rcksicherung erleben.Physikalische Sicherungen (gegen Einbruch) und Brandschutzeinrichtun-gen sind ebenso obligatorisch wie eine restriktive Zugangspolitik.Da die Anzahl der Medien mit der Zeit wchst und die Archivierung kom-plexer wird, bietet sich ein datenbankengesttzes Inventarisierungssysteman. Hierzu sollten mindestens folgende Attribute aufgenommen werden: Primrschlssel Name Zweck Medientyp gesicherte Dateien inkl. Datum/Version, Eigentmer, Attribute LagerortDer Primrschlssel dient der Identifikation des Mediums und kann bspw.eine laufende Nummer sein, sinnvoller ist es aber in ihm Informationenzu codieren (bspw. Datum, gesicherte Daten, IP-Adresse, Level oder hn-liches). Der Primrschlssel muss mindestens auf jedem Medium und derentsprechenden Hlle angebracht werden. Name kann ggf. verwendetwerden, wenn man die Medien nicht ber den Primrschlssel ansprechenmchte. Zustzlich muss ebenfalls der Zweck, Medientyp und der Lagerortder Medien katalogisiert werden.In der Datenbank werden auch die Metadaten der gesicherten Dateienerfasst. Dies ist notwendig, um im Falle einer Rcksicherung das passendeSicherungsband zu finden.Fr groe Datenmengen existieren auch automatische Bandwechseleinhei-ten, die die Medien und Hllen mit einem Strichcode etikettieren knnen.In Verbindung mit einem einfachen Handscanner ist dies ideal um grereMedienbestnde zu inventarisieren und zu verwalten.3.8 prfliste zur strategie34* Wer ist verantwortlich?* Wie wird gesichert?* Wann wird gesichert?* Was wird gesichert?* Welche Medien und Gerte werden verwendet?* Wo werden die Medien gelagert?* Wie lange werden die Medien gelagert? .* Wie/Wann wird die Integritt der Sicherung geprft?* Welche Backupstrategie? (Wann welche Level?)* Wo ist die Dokumentation zur Backupstrategie?Tabelle 8.: Prfliste zur Strategie353.8. Prfliste zur Strategie36Teil IISICHERUNG EINZELNER SYSTEME4PROGRAMME AUTOMATISIERENA computer program does what you tell it to do,not what you want it to do.(Greers Third Law)4.1 zeitgesteuertNetBSD verfgt, wie jedes anstndige Unix, ber eine Cron-Implementierung.Cron fungiert sozusagen als Zeitschaltuhr und ermglicht dem SystemProgramme zeitgesteuert auszufhren. Jeder Benutzer verfgt ber eineneigenen crontab(5), in dem die Programm und Startzeitpunkte konfiguriertwerden knnen. um den crontab mit vi zu editieren gengt crontab -e.cron erwartet die Eintrge in einem einfachen Tabellenformat mit 6 Eintr-gen:1. Minute (0-59)2. Stunde (0-23)3. Tag (1-31)4. Monat (1-2)5. Wochentag (0-7)16. ProgrammZahlenwerte knnen als Liste (0, 3, 5), Intervall (1 9) oder gemischt (09, 11, 13, 17 31) angegeben werden.1 0,15,30,45 * * * * /usr/pkg/bin/vacuumdb2 -Uoperator -f -z woerterbuch34 20 0 * * * /usr/pkg/bin/pg_dump -Fc -Uoperator5 woerterbuch > /home/pg/wb`date +%y%m%d`67 30 0 * * 1 /sbin/dump -0 -au /home/8 30 0 * * 2-5 /sbin/dump -1 -au /home/Listing 4.1: Cronjobs um PostgreSQL zu sichernDer erste Eintrag in Listing 4.1 reinigt die PostgreSQL-Datenbank alleViertelstunde, der Zweite sichert die Datenbank jeden Tag um 00:20 ineine Datei. Eintrag drei und vier sichern /home/ mittels dump(8) auf dasMagnetband, wobei montags Level 0 und dienstags bis freitags Level 1verwendet wird.Problematisch ist bei cron, das absolute Zeitwerte angegeben werdenmssen, der Rechner zu dem Zeitpunkt also laufen muss. Abhilfe schaffthier das Programm Anacron, welches aus pkgsrc/time/anacron installiertwerden kann.Anacron verwendet anders als cron(8) keine absoluten Zeitangaben son-dern Frequenzen. Man bestimmt also nicht wann genau ein Programmlaufen soll, sondern an welchen Tagen und nach wieviel Minuten Laufzeitdes Systems es gestartet wird.1 0 und 7 sind Sonntag, 1 Montag ... 6 Sonnabend4.2. AblaufgesteuertKonfiguriert wird es nach der Installation ber /usr/pkg/etc/anacrontabin folgender Weise:1. Frequenz in Tagen2. Verzgerung in Minuten3. ID des Eintrags, ist Primrschlssel fr alle Eintrge4. auszufhrendes Programm1 SHELL=/bin/sh2 PATH=/bin:/sbin:/usr/bin:/usr/sbin3 HOME=/var/log45 #days delay id command6 1 5 daily /bin/sh /etc/daily7 7 15 weekly /bin/sh /etc/weekly8 30 30 monthly /bin/sh /etc/monthly9Listing 4.2: Anacrontab-BeispielDie ersten drei Zeilen definieren einige Variablen, die letzten drei die aus-zufhrenden Programme. Der Eintrag daily wird hier tglich ausgefhrt,es wird aber fnf Minuten nach Start des Rechners gewartet. Die anderenbeiden Eintrge werden alle sieben bzw. 30 Tage, also wchentlich bzw.monatlich ausgefhrt.4.2 ablaufgesteuertProgramme lassen sich nicht nur zeit- sondern auch ablaufgesteuert aufru-fen. Eine einfache Mglichkeit ist es /etc/rc.local dazu zu verwenden,Programme beim Systemstart aufzurufen. Dazu ist es lediglich notwendigdie Befehle an /etc/rc.local anzufgen, oder fr elaboriertere Shellskripteden /etc/rc.d/-Mechanismus zu verwenden.Ebenfalls mglich ist es, beim Herunterfahren des Systems ein Skriptausfhren zu lassen. Hierzu muss lediglich KEYWORD: shutdown imbetreffenden Skript gesetzt sein.Um Jobs spter ausfhren zu lassen, kann man die Programme at(1)oder batch(1) verwenden. Soll ein Programm zu einer bestimmten Zeitausgefhrt werden, verwendet man at und bergibt einen Zeitstempel sowiedie auszufhrenden Programme. Soll das Programm in Abhngigkeit von derSystemlast gegebenenfalls verschoben werden, kann man batch einsetzen. Eserwartet genau wie at einen Zeitstempel und die auszufhrenden Programm,fhrt diese aber erst aus, wenn die Systemlast unter 1,52 gesunken ist.1 $ at 10am Jul 312 tar cf /root/etc.tar /etc3 Job 1 will be executed using /bin/sh4 $ batch 1pm tomorrow5 dump 0a -f /root/etc.dump /etc6 Job 2 will be executed using /bin/sh7 $Listing 4.3: Jobs zur spteren Ausfhrung vorbereiten2 Oder ein anderer Wert, der an atrun(8) bergeben wurde.405SICHERUNG EINZELNER SYSTEMEUnix ist was fr Leute, denen es gefllt, auf einenBildschirm zu starren, auf dem es aussieht, alshtte sich gerade ein Grteltier auf der Tastaturgewlzt.5.1 tgliche sicherungsmechanismen im basissystemNetBSD verfgt mit /etc/daily und /etc/security ber zwei Shellskripte,die nchtlich von cron gestartet werden. Sie fhren verschiedene Wartungs-aufgaben aus und prfen sicherheitsrelevante Systemeinstellungen. Konfigu-riert werden die Skripte ber /etc/daily.conf bzw. /etc/security.conf.Es empfiehlt sich diese Skripte ausfhren zu lassen und ber die Optionrun_security in /etc/daily.conf auch /etc/security aufzurufen.In /etc/security.conf finden sich einige Optionen, die der Sicherheitdes Systems dienen. Unter anderem sorgt check_disklabels dafr, das dieAusgaben von disklabel und fdisk1 nach /var/backups/work kopiert werden.check_pkgs sichert eine Liste der installierten Pakete nach /var/backups/work/pkgs, check_changelist vergleicht die in /etc/changelist definierteListe an Dateien mit ihren jeweiligen Sicherungskopien in /var/backups.Empfehlenswert ist es ebenfalls, die Option backup_uses_rcs zu setzen, dadie Sicherungskopien somit im RCS vorgehalten werden und damit jedeVersion verfgbar ist.Zustzlich hlt /etc/security in /var/backups/etc ein RCS-Repositoryverschiedener Konfigurationsdateien aus /etc vor, die somit bei Verlust oderBeschdigung ersetzt werden knnen.5.2 das basissystem sichernUm einen einzelnen Rechner, bspw. einen Heimrechner, zu sichern, kannman einem einfachen Schema folgen:1. NetBSD installieren2. NetBSD konfigurieren3. pkgsrc einrichten und Pakete installieren4. Sicherung des Systems mit dd(1) oder Ghost 4 Unix (Siehe Listing 5.1)5. Systemkonfiguration sichern (Siehe Listing 5.2)6. Regelmige Sicherung der Daten und Konfigurationsdateien7. erneute Sicherung des Systems nach System- oder Paketaktualisierun-gen (Wie Punkt 4)Ob man das System erst sichert, nachdem alle Pakete installiert wurden,liegt im Ermessen des Administrators und den verfgbaren Ressourcen.Passt das Festplattenimage nicht mehr auf des Sicherungsmedium, sollte dasSystem gesichert werden, bevor alle Pakete installiert sind.Ob man die Pakete sichern muss, entscheidet sich in der Administrationdes Systems. Setzt man bspw. nur Stable-Releases fr PCs ein, sind in derRegel Binrpakete auf ftp.netbsd.org verfgbar. Daher kann man hier auf dieSicherung der Pakete verzichten, da sie eben auf den NetBSD-Servern und1 Sofern auf der Plattform verfgbar5.2. Das Basissystem sichernSpiegeln verfgbar sind. Ebenso kann man eigene Binrpakete erstellen unddiese getrennt vom Basissystem auf eigene Medien sichern. Diese Vorgehens-weise bietet sich an, wenn man Current-Releases und/oder Current-Pkgsrceinsetzt. Man installiert mit make package die gewnschten Pakete und lsstsie danach als Binrpaket standardmig unter pkgsrc/packages/All ab-legen. Dieses Verzeichnis kann man bspw. per NFS importieren oder diegesammelten Pakete auf DVD brennen, um sie nach der Restauration schnellwieder einpsielen zu knnen.Um nach der Einrichtung des Systems die Systemplatte mit dem Betriebs-system zu sichern, verwendet man dd(1) oder g4u, siehe Kapitel 5.13 bzw.Listing 5.1.1 g4u# uploaddisk benutzer@ftp.server.local Image-wd0.gz wd0Listing 5.1: Betriebssystem mit g4u sichernIst das System inklusive aller Pakete eingerichtet, muss die Sicherungder Anwenderdaten und der Konfigurationsdateien betrachtet werden. ImAllgemeinen kommt es vor, da sich Konfigurationsdateien im System n-dern. Es ist nun nicht notwendig, das gesamte System zu sichern, sondernes reicht meist die Konfigurationsdateien zu sichern. Da diese in der Regelnicht besonders gro sind, kann man sie mit den Anwendungsdaten zusam-men sichern, indem man bspw. vor dem dump der Homeverzeichnisse eineTarball mit allen wichtigen Systemverzeichnissen anlegt. Die Verzeichnisseumfasssen: /etc /usr/pkg/etc /var/cron /var/log /var/backups /var/db /var/yp /rootAuerdem sollte man noch folgende Informationen ber das System sammeln(und idealerweise ausdrucken): dmesg fdisk fr alle Platten disklabel fr alle Platten ggf. Kernel-Konfiguration pkg_info | sort > pkgs-listDie Befehle in Listing 5.2 packt man am einfachsten in ein Shellskript, dasman vor jedem Dumplauf ausfhren lsst.Fr die Sicherung der Daten verwendet man dump(8) mit einem Wochen-schema (siehe Tab. 9) auf mindestens zwei Medienzyklen. Man kann diesebspw. in gerade und ungerade Kalenderwoche unterteilen, besser wren aberdrei oder sogar vier Medienzyklen. Ist die Datenmenge nicht zu gro umein Medium zu sprengen, was bei Heimrechnern oft der Fall ist, kann manauch auf verschiedene Dumplevel verzichten und tglich ein Level 0 Dumperzeugen. Dies vereinfacht die Rcksicherung und erhht die Zuverlssigkeitder Sicherung, da nur ein Medium notwendig ist.Im Anhang (A.1, A.2 und A.3) findet sich ein Shellskript, das ich einsetzeum einen einzelnen Rechner zu dumpen.421 $ dmesg > /home/back/system/dmesg2 $ pkg_info | sort > /home/back/system/pkgs-list3 $ for i in wd0 w1 wd2 wd3 sd0 sd1 sd2 sd3 sd44 > do disklabel $i >> /home/back/system/disks5 > fdisk $i >> /home/back/system/disks6 > done7 $ config -x /netbsd > /home/back/system/MYKERNEL8 # tar cpf - /etc /usr/pkg/etc /var/cron /var/log /var/backups \9 /var/db /var/yp /root/ | gzip > konf.`date +%y%m%d`.tgz10 # gzip -t konf.`date +%y%m%d`.tgzListing 5.2: Konfigurationsdateien sichernWoche Mo Di Mi Do Fr Sa So1. 0 1 1 1 1 2 22. 0 1 1 1 1 2 2Tabelle 9.: Dumplevel fr einen Einzelrechner5.3 filesystem-snapshotsEin Snapshot erzeugt ein Abbild eines Dateisystems zu einem gegebenenZeitpunkt. Dieses Abbild kann bspw. mit dump gesichert werden, whrenddas eigentliche Dateisystem wieder im Produktiveinsatz ist. Somit werdenAusfallzeiten von Dateisystemen minimiert. Die Erstellung eines Snapshotsdauert nicht einmal eine Sekunde, dabei werden alle datenvernderndenProzesse gestoppt, die Blcke synchronisiert und der Snapshot erstellt. An-schlieend werden die gestoppten Prozesse fortgesetzt. Das Dateisystem istsomit zur Erstellung des Snapshots so konsistent wie nach einem gewhnli-chen umount.5.3.1 Praktischer EinsatzAb NetBSD 2.0 sind Snapshots im GENERIC-Kernel verfgbar.Um einen Snapshot zu verwenden, muss mit fssconfig(8) das entsprechen-de Pseudogert zum Dateisystem konfiguriert werden. Dies geschieht mit:fssconfig -c fss0 /home home0.fss wobei folgende Optionen gelten:* fss0 ist das zu verwendende Pseudogert* /home ist das Quellverzeichnis* home0.fss ist eine Datei, in die alle nderungen am Quellverzeichnis nachdem Snapshot geschrieben werden.Listing 5.3: fssconfig-OptionenDas Quellsystem ist nun ab dem Zeitpunkt des Snapshots als /dev/fss0wie ein normales, schreibgeschtztes Dateisystem verfgbar, kann also bspw.gemounted werden. Wird das Quellverzeichnis verndert, bspw. eine Dateihineinkopiert, wird diese nderung nicht nach /dev/fss0 durchgeschleift,sondern nach home0.fss geschrieben. Sollen die nderungen nicht mitge-schrieben werden (was z. B. beim Einsatz zur Datensicherung der Fall wre),wird die Option -x bergeben.fssconfig -vl zeigt alle Pseudogerte und ihre Konfiguration an. fssconfig-u fss0 deaktiviert das Pseudogert, wobei die Datei fr die nderungenzurckbleibt.435.4. dump(8)/dump_lfs(8) und restore(8)Ist /dev/fss0 konfiguriert, kann es ganz normal (nur lesbar) eingebundenwerden.5.3.2 Sicherung eines SnapshotsSnapshots sind ein ideales Werkzeug um Dateisysteme mit dump zu sichern.Die Arbeitsschritte sind wie folgt:1. Snapshot erstellen2. Snapshot sichern3. Snapshot abschalten1 # fssconfig -x -c fss0 /home /usr/fss0.log2 # dump -0au -X /dev/fss03 # fssconfig -u fss0Listing 5.4: Snapshot mit Dump sichernMchte man andere Sicherungsprogramme, bspw. Amanda mit gtar ver-wenden, kann man stattdessen an zweiter Stelle den Snapshot mounten(mount -r /dev/fss0 /mnt && tar -c -f foo.tar /mnt) und als norma-les Dateisystem sichern.5.4 dump(8)/dump_lfs(8) und restore(8)Dump und Restore sind historisch gewachsen die bedeutendsten Backup-programme unter Unix. Sie arbeiten hierbei auf Blockebene, also unterhalbder Dateischicht. Dies heisst das Dump einen Verzeichnisbaum oder einDateisystem2 komplett mit allen Eigenschaften sichert und nicht auf Dateie-bene Dateien kopiert. So ist es quasi mglich eine Partition zu spiegeln undzurckzusichern oder auch auf andere Rechner zu bertragen.Da Dump speziell an das Dateisystem angepasst ist, kann dump(8) nur FFSsichern, fr LFS gibt es dump_lfs(8). Die beiden Programme unterschei-den sich aber in der Bedienung nicht. Restore entpackt einen dump aberdateisystemunabhngig, kann also auch bspw. auf einem NFS-Verzeichnisarbeiten.Dump untersttzt inkrementelle Backups durch die Verwendung soge-nannter Dumplevels, dabei werden bei jedem Backup in der Datei /etc/dumpdates die entprechenden Daten eingetragen und knnen so spterausgelesen und aufbereitet werden. Ein Dump mit Dumplevel 0 erzeugtein Komplettbackup, whrend ein Level grer 0 die nderungen seit demletzten Backup inkrementell sichert. Level 2 sichert also alle Daten, die seitdem letzten Dump mit Level 1 erzeugt oder gendert wurden. Die Datendazu werden in einem menschenlesbaren Format in /etc/dumpdates abge-legt, wenn man die Option -u bergibt und Dump auf eine Partition ansetzt,nicht aber auf einzelne Dateien oder Verzeichnisse.Da Dump fr gewhnlich dazu eingesetzt wird, komplette Partitionen zusichern, verfgt es ber keine Ein-/Ausschlusslisten, wie dies einige andereProgramm benutzen. Stattdessen prft Dump, ob das Fileflag NODUMPgesetzt ist. Mit diesem Flag kann man einzelne Dateien oder Verzeichnissevom Dump ausschlieen. Allerdings muss man hierbei beachten, da Dumpmit Level 0 generell Fileflags ignoriert. Mchte man trotzdem markierteDateien nicht sichern, muss man -h0 bergeben.Dump lsst sich auf Dateisysteme und Partitionen ansetzen, dies geschiehtam einfachsten mit Listing 5.6, die Option -a veranlasst d. abei die Grssedes Archivs selbst festzulegen, anstatt nur Dateien voreingestellter Gre zuschreiben.2 allerdings bleibt dump dabei in der angegebenen Partition, folgt also Mountpoints nicht.441 $ chflags nodump .fetchmailrc .signature mail/ .gnupg/2 $ ls -lo .signature3 -rw-r--r-- 1 stefan stefan nodump 369 Feb 18 21:09 .signature4 $ chflags dump mail/Listing 5.5: NODUMP setzen1 # dump -0u -f dump-02-31-12 -a /home2 # dump -0u -f dump-02-31-12 -a /dev/wd0eListing 5.6: Sicherung mit dumpDump kann mit der Option -W auch eine bersicht der bisher erstelltenDumps aus /etc/dumpdates erstellen und mit -w die noch zu sicherndenPartitionen angeben. Mchte man Archive bestimmter Gre erzeugen (bspw.fr Streamer oder um sie auf CD/DVD zu brennen), verfgt dump(8) bereinige, teils historische, Optionen. Von Interesse drfte heute aber nur noch-B sein, das die Gre der zu sichernden Archive in Kilobyte erwartet. Dazumuss aber zwingend der Name eines jeden zu erzeugenden Archivs ber-geben werden, da dump(8) sonst automatisch nacheinander in die zuletzt3angegebene Datei schreibt.1 #!/bin/sh23 DATUM=`date +%y%m%d`4 QUELLE=/home/56 # Mediengre in kB, 102000=>99MB,7 # 715000=>698MB, 2097152000=>2000MB8 MEDIUM=102000910 #Gre des Verzeichnis in kB11 MEDIEN=`du -sk $QUELLE | awk '{print $1}'`1213 # Medienzahl kalkulieren, Nachkomma wird abgeschnitten!14 MEDIEN=$(($MEDIEN/$MEDIUM))1516 # Medienzahl aufrunden17 MEDIEN=$(($MEDIEN+1))1819 # Dateinamen iterieren20 DAT=${DATUM}_121 i=122 while [ $i -lt $MEDIEN ]23 do24 i=`expr $i + 1`25 DATEIEN=${DATUM}_$i26 DAT=${DAT},${DATEIEN}27 done2829 echo "dump -0 -B $MEDIUM -f $DAT $QUELLE"Listing 5.7: dump-Befehl fr mehrere Volumes3 werden drei Dateinamen angegeben, aber fnf Dateien erzeugt, werden die dritte, vierteund fnfte in die dritte Datei geschrieben, man hat dann also drei Dateien mit der ersten,zweiten und fnften Sicherung vorliegen455.4. dump(8)/dump_lfs(8) und restore(8)s.elber hat keine Mglichkeit Archive zu komprimieren, dies kann abermittels Pipe an Bzip2 oder Gzip bzw. einem kleinen Shellskript gelst wer-den. Mglich ist ebenfalls der Einsatz im Netzwerk mittels rdump(8) undrrestore(8), dies ist aber aufgrund mangelnder Sicherheit bzw. fehlender Ver-schlsselung nur in gesicherten Netzwerken mglich, so das ein SSH-Tunnelmit der Umgebungsvariable RCMD_CMD aufgerufen werden sollte. Besser isthier eine Pipe an ssh, der die Ausgabe auf einen Rechner im Netzwerkschreibt, wie in Listing 5.8 illustriert.1 # dump -0a -f - home | ssh operator@192.168.1.1 \2 dd of=/usr/backup/dump.0Listing 5.8: Dump im Netzwerk5.4.1 restoreRestore kann ein komplettes Archiv mit der Option -r zurckspielen (sieheListing 5.9). Dabei erzeugt es eine Datei namens restoresymtable, in der dieMetainformationen zur Rcksicherung (Inodes, welche Bnder, etc.) abgelegtwerden. Diese Datei kann nach der Rcksicherung aller Bnder entferntwerden.1 # restore -r -f 02-11-01 && restore -r -f 02-11-082 # rm restoresymtableListing 5.9: Zwei Dumps mit restore zurckspielenMchte man nur bestimmte Pfade oder Dateien zurckspielen, kann manTeile des Verzeichnisses mit der Option -x bergeben. Leider untersttztrestore keine RegExes, aber man kann sich hierbei mit ein paar Backticksbehelfen. Um zu prfen ob ein Archiv erfolgreich geschrieben wurde, reichtes zu Testzwecken die allerletzte Datei zu restaurieren. Da dump alle vorigenEintrge zumindest traversieren muss, werden Fehler im Archiv erkannt undgemeldet. In der Dateiliste (-t) werden die Inodes und die korrespondierendeDateiname angegeben, man kann also den letzten Eintrag zurcksichern.1 $ restore -x stefan/ www/2 $ restore -t > dateiliste3 $ restore -x `grep -i 'bz2$' dateiliste | awk '{print $2}'`4 $ restore -x `tail -n 1 dateiliste | awk '{print $2}'`Listing 5.10: einzelne Dateien mit restore zurckspielenSucht man eine bestimmte Datei im gesicherten Verzeichnisbaum, kannman restore -i verwenden. Hier wird eine Shell aufgerufen, in der man mit lsund cd den Verzeichnisbaum traversieren kann. Hat mann die gewnschtenDateien gefunden, kann man sie mit add zur Liste der zurckzusicherndenDateien hinzufgen. Mit extract werden die in der Liste spezifierten Dateienim aktuellen Verzeichnis entpackt.Um einen unterbrochenen Lauf fortzusetzen, kann man die Option -Rverwenden.5.4.2 Dump im DetailDa d. as wichtigste Sicherungsprogramm ist, werde ich es nher untersuchen:Das exemplarisch abgedruckte Log eines Sicherungslaufes gibt wertvolleInformationen wieder:465.4.2. Dump im Detail1 root@# dump -1au -h0 -f - /home |gzip > home.12 DUMP: Found /dev/rwd1a on /home in /etc/fstab3 DUMP: Date of this level 1 dump: Sat Dec 24 12:17:56 20054 DUMP: Date of last level 0 dump: Sun Dec 18 23:20:19 20055 DUMP: Dumping /dev/rwd1a (/home) to standard output6 DUMP: Label: none7 DUMP: mapping (Pass I) [regular files]8 DUMP: mapping (Pass II) [directories]9 DUMP: mapping (Pass II) [directories]10 DUMP: estimated 41438 tape blocks.11 DUMP: Volume 1 started at: Sat Dec 24 12:18:18 200512 DUMP: dumping (Pass III) [directories]13 DUMP: dumping (Pass IV) [regular files]14 DUMP: 40541 tape blocks15 DUMP: Volume 1 completed at: Sat Dec 24 12:18:40 200516 DUMP: Volume 1 took 0:00:2217 DUMP: Volume 1 transfer rate: 1842 KB/s18 DUMP: Date of this level 1 dump: Sat Dec 24 12:17:56 200519 DUMP: Date this dump completed: Sat Dec 24 12:18:40 200520 DUMP: Average transfer rate: 1842 KB/s21 DUMP: level 1 dump on Sat Dec 24 12:17:56 200522 DUMP: DUMP IS DONE23 root@#Listing 5.11: Protokoll einer Dump-Sicherung das zu sichernde Verzeichnis /home ist als eigene Slice /dev/rwd1a in/etc/fstab aufgefhrt Dieser Sicherungslauf (Level 1) beginnt 12:17 am 24.12.2005 Der letzte Sicherungslauf im Level 0 fand am 18.12. statt Der dump wird durchgefhrt und erfolgreich beendet, dazu wird eineStatistik (Dauer, Platz, bertragungsrate) ausgegeben.Interessant sind hierbei insbesondere die einzelnen Durchlufe (Pass I -IV):1. aus dem aktuellen Datum, dem angegebenen Level (hier: 1) undden letzten relevanten Durchlufen aufgezeichnet in /etc/dumpdatesberechnet dump die Variable DUMP_SINCE. Alle Inodes im Dateisys-tem werden traversiert und deren modification time (mtime) wird mitDUMP_SINCE bezgl. Gre verglichen. Ist die mtime einer Datei greroder gleich DUMP_SINCE, wird der Inode in die Liste zu sichernderDateien bernommen. Nichtzugeordnete Inodes werden ignoriert, sodas dump am Ende des ersten Durchlaufes drei Listen erzeugt hat:a) Inodes der Dateien, die gesichert werden sollenb) Inodes aller Verzeichnissec) Zugeordnete Inodes2. Durchlauf II luft in mehreren Stufen ab:a) Die in Durchlauf 1 erstellte Liste der Verzeichnisse wird erneuttraversiert und geprft ob zu sichernde Dateien im Verzeichnisexistieren. Wenn nicht, wird der entsprechende Inode aus derListe zu sichernder Verzeichnisse entfernt.b) Die Verzeichnisse werden erneut berprft, in dem der Verzeich-nisbaum von den Blttern zur Wurzel traversiert wird. Dabei475.6. starsollen evtl. im letzten Durchlauf freigewordene Verzeichnisse ge-funden werden.Es wurden in diesem Lauf keine weiteren Verzeichnisse freige-macht, da sonst ein weiterer Pass II stattgefunden htte.3. Vorbereitung von Pass III:Bevor dump mit dem Schreiben der Daten beginnt, werden derenMetainformationen abgelegt. Hierzu wird ein Header geschrieben, derdie nachfolgenden Daten beschreibt. Zustzlich werden zwei Inode-Tabellen geschrieben, eine im nativen Format und eine, aus Kompatibi-littsgrnden, im normalisierten alten BSD-Format.4. Ein Header, der den Inode des Verzeichnisses enthlt, und die Daten-blcke fr jedes Verzeichnis in der zu-sichernde-Verzeichnisse-Listewerden geschrieben.5. Ein Header, der den Inode der Datei enthlt, und die Datenblcke frjede Datei in der zu-sichernde-Dateien-Liste werden geschrieben.6. Nachbereitung von Pass IV :Der abschlieende Header wird aufs Band geschrieben.Inkonsistenzen in der Sicherung knnen nur auftreten, wenn das Quell-laufwerk whrend der Sicherung beschrieben wird. Dabei ist es mglich,das einzelne Dateien nicht, oder nur falsch, gesichert werden. Eine Korrum-pierung der gesamten Sicherung ist dabei aber uerst unwahrscheinlich.Unmglich werden diese Fehler, wenn das Dateisystem umounted ist oderman Snapshots (siehe Kap. 5.3) verwendet.5.5 tar(1)Tar(1) ist das wohl bekannteste Sicherungsprogramm und vielseitig einsetz-bar. Allerdings gibt es verschiedene Versionen und Implementierungen vontar, so das man darauf achten sollte nur entsprechend kompatible Versioneneinzusetzen bzw. bzw kompatible Archive zu erzeugen.Tar steht fr Tape Archiver, es wurde also dazu entwickelt Bandarchivezu beschreiben. Es erzeugt dazu eine Datei, die alle zu sichernden Dateienenthlt und schreibt diese auf ein Band oder in eine einfache Datei.1 $ tar cpfz operator@backup:/home/backup/backup.tgz /home/2 $ tar xpfz backup.tgzListing 5.12: Dateien mit tar archivieren und entpackenDie Option -f erzeugt eine Datei, standardmig schreibt das Archiv sonstauf das erste Bandlaufwerk /dev/nrst0.Zurckspielen kann man ein Backup mit x, die Option p sorgt dafr, dadie Dateirechte beibehalten werden.Tar schreibt relativ zum jetzigen Pfad, d. h. das gesicherte /home-Verzeichniswird an aktueller Stelle entpackt. Tar kann mit der Option -z gzip- bzw. mit-j bzip2-komprimierte Archive erzeugen. Entpackt werden Archive mit -x.Es sei hierbei nicht verschwiegen das Tar grosse Probleme mit defektenArchiven hat, da bei einem Archiv ein Header erzeugt wird der Infomationenber das gesamte Archiv beinhaltet. Taucht jetzt an einer Stelle ein Fehlerauf, entpackt Tar das Archiv nur bis zu dieser Fehlerstelle.5.6 starStar ist eine von Jrg Schilling seit 1982 entwickelte Tar-Implementierung.Es ist die weltweit schnellste Tar-Variante und weist einige sehr ntzliche48Erweiterungen gegenber Tar auf. Es untersttzt unter anderem RegulreAusdrcke, Levels a la Dump, keine Begrenzung der Pfadlnge, automatischeErkennung der Endianess oder die Mglichkeit ein Dateisystem mit einemTarball zu vergleichen. In der Standardvariante kann Star Tar-Archive lesenund umgekehrt.Star lsst sich aus pkgsrc/archivers/star installieren und sollte im Allge-meinen dem normalen Tar vorgezogen werden. Star untersttzt verschiedeneTar-Formate, die mit der Option -H= bestimmt werden knnen. Am leistungs-fhigsten ist EXUSTAR.5.7 cpio(1)Cpio (copy in/out) ist von der Syntax her etwas eigen, da es als erste Optiondie bergabe einer zu sichernden Datei erwartet und diese auf STDOUTschreibt. Dieses Problem erweist sich allerdings mithilfe der Pipe als Vorteil,da so mit find(1) oder ls(1) die Dateiliste bergeben und die Ausgabe mit >bestimmt werden kann.1 $ ls *.jpg | cpio -0 > /home/Bilder.cpio2 $ find /home -mtime 7 | cpio -o > /dev/nrst03 $ cpio -i < /dev/nrst0Listing 5.13: Dateien mit cpio sichernListing 5.13 zeigt wie man alle JPEGs im aktuellen Verzeichnis in dieDatei ./Bilder.cpio sichert. Die Ausgabe kann stattdessen auch auf dasBandlaufwerk /dev/nrst0 umgeleitet werden. Um Unterverzeichnisse zusichern oder inkrementelle Backups zu erzeugen nutzt man find(1). Derzweite Befehl sichert alle Dateien die in den letzten sieben Tagen gendertwurden auf das erste Bandlaufwerk. Zurckspielen kann man die Sicherungmit dem dritten Befehl.Leider untersttzt Cpio keine berprfung der Archive, so da man diesauf Wunsch manuell machen muss, indem man das Archiv wieder entpacktund die Dateien mit diff(1) oder mtree(8) vergleicht.5.8 afio(1)Afio ist eine Neuauflage von Cpio und behebt einige Probleme, z. B. Problememit leeren Dateien oder auf 0 gesetzte Rechte. afio verwendet dabei die selbeSyntax wie Cpio afio ist via pkgsrc/archivers/afio installierbar und sollteCpio vorgezogen werden.5.9 pax(1)Pax ist ein Standardisierungsversuch der IETF, da es zu viele Implementierun-gen von Tar und Cpio gibt. Pax ist in der Lage verschiedene Archivformatewie Cpio und Tar zu schreiben und zu lesen und kann so gerade in hetero-genen Umgebungen ntzlich sein. pax wird unter anderem auch auf denInstallationsmedien von NetBSD verwendet.1 # pax -w -f /dev/nrst0 /home2 # pax -v -f /dev/nrst03 $ pax -r -s ',^/*usr/* ' -f a.paxListing 5.14: Sicherung und Rcksicherung mit pax495.10. Verzeichnisse synchronisieren mit rsync(1)Befehl Nummer eins in Listing 5.14 schreibt das /home-Verzeichnis aufBand und zweitens gibt ein Inhaltsverzeichnis der Sicherung aus. Der letzteBefehl extrahiert alle Dateien in /usr im Archiv ./a.pax5.10 verzeichnisse synchronisieren mit rsync(1)Rsync ist aus pkgsrc/net/rsync installierbar und ermglicht es Dateihierar-chien auf lokalen Platten oder im Netz zu synchronisieren. Dabei verwendetes den rsync-Algorithmus, der nur Daten bertrgt, die nicht gleich sind.Dabei ist es schnell und effizient, setzt aber, bei Verwendung im Netzwerk,auf beiden Maschinen ein installiertes rsync voraus.Rsync kann verschiedenste Optionen bernehmen, unter anderem auchExclude/Include-Anweisungen oder Optionen, ob es nicht mehr existierendeDateien auf dem Empfnger lschen soll.1 1$ rsync -azc -e ssh --exclude-from=/home/rsync.excl \2 --delete-excluded --delete-after /home/ \3 stefan@192.168.2.2:/home/45 2$ rsync -azc -e ssh --exclude-from=/home/rsync.excl \6 --delete-excluded --delete-after \7 /home/* /usr/home/Listing 5.15: rsync-BeispieleDer erste Befehl synchronisiert das lokale /home mit /home auf 192.168.2.2.Es verwendet dazu ssh(1) als Tunnel, schliet die Pfade, die in /home/rsync.excl definiert sind, aus. delete-excluded und delete-after lscht Da-teien die nicht synchronisiert werden sollen auf dem Empfnger, dies sollallerdings erst nach dem Transfer geschehen. Die Optionen -azc starten denDurchlauf rekursiv, als Archivierung, mit Komprimierung und Prfsum-menvergleich der Dateien. Der zweite Befehl fhrt genau das selbe durch,synchronisiert aber mit der lokalen Platte.Rsync lsst sich einfach verwenden um Datenbestnde auf verschiedenenMedien (Wechselplatten, tragbare Wechselmedien, ZIP-Disketten, NFS) oderverschiedenen Systemen (Dateiserver, Laptop) zu synchronisieren. Durchden rsync-Algorithmus ist rsync insbesondere bei vielen kleinen Dateien(z. B. CVS-Repository) sehr schnell.Rsync lsst sich sehr gut verwenden um Daten auf eine andere Plattezu spiegeln. Das folgende Skript synchronisiert bei jedem Herunterfah-ren des Rechners per ACPI-Schalter ein CVS-Repository mit einer zweitenPlatte. Dazu muss lediglich ein NetBSD-Kernel mit ACPI verwendet wer-den, powerd=yes in der /etc/rc.local gesetzt und /etc/powerd/scripts/power\_button wie in Listing 5.16 angepasst werden.1 case "${2}" in2 pressed)3 /usr/pkg/bin/pg_dumpall -Upgsql > \4 /usr/home/back/pgdump.`date +%y%m%d`5 /usr/pkg/bin/pg_ctl stop -D /usr/pkg/pgsql/6 /usr/pkg/bin/rsync -a /home/cvs/ /usr/home/back/7 echo "System wird heruntergefahren."8 /sbin/shutdown -p now "power button pressed"9 exit 010 ;;11 *)Listing 5.16: /etc/powerd/scripts/power_button505.10.1. MS Windows als ClientZuerst wird ein pg_dump erzeugt und PostgreSQL heruntergefahren.Anschlieend wird mit Rsync das lokale CVS-Repository (/home/daten/cvs/) mit der zweiten Platte synchronisiert.Rsync untersttzt mit der Option -c die Prfung bertragener Dateienmit einer MD4-Prfsumme. Anders als cp(1) kann es so verifizieren, ob diebertragenen Dateien korrekt sind. Daher sollte man Rsync mit Prfsum-menvergleich verwenden, wenn man sicherstellen will, da Daten korrektbertragen wurden.5.10.1 MS Windows als ClientMchte man einen Windowsclient mit einem NetBSD-Server synchronisieren,bietet sich cwRsync4 an.Es ermglicht den kompletten Betrieb als Rsync-Client und/oder Server,da es alle bentigten Komponenten (SSH, Cygwin) integriert.Nach der Installation kann man eine Batchdatei erstellen, die bspw. beijedem Systemstart oder Login aufgerufen wird und bestimmte Verzeichnissemit dem Server synchronisiert.1 c:\CWRSYNC\rsync -e C:\CWRSYNC\ssh -av --delete2 --delete-excluded3 --exclude "[Tt]emp*" --exclude "privat"4 --exclude 'Temporary Internet Files'5 "Eigene Dateien", "Lokale Daten"6 uni@192.168.2.1:/home/uniListing 5.17: cwRsync auf Windows einsetzenAm einfachsten konfiguriert man SSH fr die Benutzer per Schlssellogin,indem man die Schlsseldateien nach c:\Eigene Dateien\ssh kopiert. AusSicherheitsgrnden sollte man auf dem NetBSD-Server einen eigenen sshdauf einem anderen Port als 22 starten und den Zugriff darauf per sshd.confund ipf begrenzen.Die Batchdatei kann nun explizit, oder ber schtasks, der Windows XPVariante von cron, aufgerufen werden:1 schtasks /create /SC BEIANMELDUNG /TN taeglbackup2 /TR c:\CWRSYNC\backup.bat /SD 14/12/2004Listing 5.18: Windows-Programme zeitgesteuert ausfhren5.11 rdiff-backupSynchronisationsmechanismen haben ein Problem - auch Fehler werden syn-chronisiert. Strzt bspw. eine Anwendung ab und vernichtet dabei den Inhalteiner Datei, wird diese fehlerhafte Datei bei der Synchronisation bertragen.Um dieses Problem zu umgehen, ist eine Archivierung der synchronisiertenDaten erforderlich. Dies kann mit einer nchtlichen Sicherung des Spiegelsgeschehen - oder aber vom Sicherungsprogramm selbst erledigt werden.Basierend auf der Rsync-Bibliothek wurde Rdiff-backup entwickelt. Eserstellt wieder eine Spiegelung der Daten, hlt aber zustzlich eine Reihe anMetadaten und Diffs der Dateien vor. Somit wird ab Beginn der Sicherungjede Version der Sicherung vorgehalten und kann wiederhergestellt werden.Werden Dateien in der Quelle gendert und Rdiff-backup erneut aufgeru-fen, legt es im Zielverzeichnis rdiff-backup-data/increments an, in dem4 http://sourceforge.net/project/showfiles.php?group_id=69227&package_id=6808151http://sourceforge.net/project/showfiles.php?group_id=69227&package_id=680815.13. Ghost for Unix (g4u)die verschiedenen Diffs der Versionen abgelegt sind. Man kann jede dieserVersionen durch Angabe des Zeitpunkts wiederherstellen lassen.1 1$ rdiff-backup /etc/ /usr/back/etc/2 2$ rdiff-backup -l /usr/back/etc/3 Found 6 increments:4 increments.2006-01-01T12:35:24+01:00.dir Sun Jan 1 12:35:24 20065 increments.2006-01-04T12:35:37+01:00.dir Wed Jan 4 12:35:37 20066 increments.2006-01-28T12:35:31+01:00.dir Sat Jan 28 12:35:31 20067 increments.2006-02-03T12:35:28+01:00.dir Fri Feb 3 12:35:28 20068 increments.2006-02-04T12:35:50+01:00.dir Sat Feb 4 12:35:50 20069 increments.2006-02-06T12:35:27+01:00.dir Mon Feb 6 12:35:27 200610 Current mirror: Sun Feb 26 12:35:29 200611 3$ rdiff-backup -r 2B --force /usr/back/etc/ /etc/Listing 5.19: rdiff-backupDer erste Befehl sichert alle Dateien aus /etc nach /usr/back/etc. Derzweite Befehl zeigt die inkrementellen Sicherung und deren Daten an.Der dritte Befehl stellt die Sicherung wieder her, und zwar mit -r 2B denZustand der zweitletzten inkrementellen Sicherung. force erlaubt dabeidas Dateien im Zielverzeichnis berschrieben werden drfen.5.12 dd(1)Dd(1) ist kein eigentliches Sicherungsprogramm, sondern es dient dazuDateien zu konvertieren. Dd kann jedoch auch auf Raw Devices schreibenund von ihnen lesen, dies ermglicht es, echte 1:1-Kopien von Gerten zuerstellen und zu schreiben, so kann man z. B. mit den Befehlen in Listing5.20 ein Image einer Floppydiskette erstellen, die Partition /dev/wd1a\path1:1 auf /dev/wd2a kopieren oder den MBR der ersten Platte sichern. Somiteignet es sich hervorragend um an Rohdaten, bspw. von Magnetbndern,heranzukommen oder komplette Systemplatten zu sichern. Da dd die ge-samten Blcke einer Partition einliest, wird das erzeugte Image genau sogro wie die Partition werden. Mchte man das Image komprimieren, sollteman vorher im laufenden System den leeren Festplattenplatz mit Nullenberschreiben.Dd ist ebenfalls in der Lage Dateien zu konvertieren, so kann man mit derOption conv=swab die Byte-Order vertauschen lassen.1 # dd if=/dev/zero of=/nullen && rm /nullen2 # dd if=/dev/fd0a of=floppy.iso3 # dd if=/dev/wd1a of=/dev/wd2a bs=2m | split -b 695M4 # dd if=/dev/wd0d of=mbr.dd count=1Listing 5.20: Daten mit dd schreiben5.13 ghost for unix (g4u)Ghost for Unix5 (g4u) ist eine NetBSD-Diskettenvariante, die von HubertFeyrer entwickelt wurde um Festplatten zu spiegeln und im Netz via FTP zuverteilen. Es verwendet dd (siehe Kap. 5.12) um auf Platten zuzugreifen undkann daher jedes Datei-/Betriebssystem spiegeln. Es verwendet zum Betriebeinige Shellskripte, so das es auch ein ungebter NetBSD-Anwender einfachanwenden kann. Es eignet sich insbesondere hervorragend um mehreregleich aufgebaute Systeme zu verteilen, so dass man bspw. in Laboren,5 http://www.feyrer.de/g4u/52http://www.feyrer.de/g4u/Klassenrumen oder Clustern (siehe Regensburger Marathon-Cluster6) einSystem nur einmal aufsetzt und dieses dann auf mehrere Rechner verteilt.Es wird lediglich das Disketten- oder CD-Image bentigt um ein bootbaresMedium zu erstellen. Davon wird g4u gebootet und anschlieend knnenFestplatten und/oder Partitionen gesichert und restauriert werden.1 # uploaddisk benutzer@ftp.server.local Imagename.gz wd12 # slurpdisk benutzer@ftp.server.local Imagename.gz wd03 # copydisk sd0 sd1Listing 5.21: Festplatten-Images mit g4u erstellenIn Listing 5.21 wird die zweite IDE-Platte (wd1) als backup.los./Imagename.gz|auf ftp.server.local gesichert. Der zweite Befehl installiert das Image auf derersten IDE-Platte, der dritte Befehl kopiert lokal die erste SCSI auf die zweiteSCSI-Platte.G4u ist ein ausgezeichnetes System um komplette Platten zu sichernund zu verteilen. Fr Datenbackups eignet es sich nur bedingt, da immerkomplette Platten oder Partitionen mit dd gesichert werden.Auf der Homepage des Systems findet sich eine ausfhrliche Anleitung.6 http://www.feyrer.de/marathon-cluster/53http://www.feyrer.de/marathon-cluster/5.13. Ghost for Unix (g4u)54Teil IIISICHERUNG VERTEILTER SYSTEME6SICHERUNG VERTEILTER SYSTEME IN NETZWERKENStay the patient courseOf little worth is your wireThe network is down6.1 amandaAmanda steht fr Advanced Maryland Network Disk Archiver und eignetsich, wie der Name schon sagt, hervorragend zur Sicherung in Netzen. Es ver-wendet dazu ein Client-/Server-Modell um Unix-Clients und SMB-Shares1auf Bandlaufwerk zu sichern. Inzwischen verfgt es auch ber die Fhigkeitdie Sicherung auf Platten abzulegen oder Platten als Spoollaufwerk einzu-setzen. Zur Sicherung eines Unixclients kann es GNU Tar oder das nativedump des Clients verwenden. Um Daten von MS-Windows Rechnern zusichern, mssen diese als Freigabe ins Netzwerk exportiert werden, um dannvom Server aus mit smbtar kopiert werden zu knnen. Fr Unixclients kannAmanda auf den Clients selbst die Daten vor der bertragung komprimierenoder diese nach der bertragung auf dem Server komprimieren. Je nachdemob die Auslastung der Clients oder die des Netzes wichtiger ist, kann maneine passende Strategie whlen. Da Amanda ein eigenes Netzprotokoll zurbertragung der Daten verwendet, kann es an verschiedenen Punkten Datenabgreifen oder verndern (bspw. komprimieren, verschlsseln oder auf Virenprfen).Die Zyklen der Sicherungsstrategie (also wann welches Level eingesetztwird) berechnet Amanda selbstndig aus den Statistiken der vorangegange-nen Lufe, so das ein Optimum an Platzersparnis und Sicherungsaufwanderrechnet wird. Bei manuellen Sicherungen lautete die Devise im allgemeinenFreitags ein Komplettbackup, das archiviert wird.. Mit Amandas automati-scher Strategieberechnung lautet diese Devise: Gib mir ein Komplettbackupin 7 Tagen.. Durch diese Definition des dumpcycle verteilt Amanda die Si-cherungen selbstndig auf die Bnder was dazu fhrt das den Logdateienerhebliche Bedeutung zukommt. Die Berechnung der Sicherungsstrategieerfolgt aus mehreren Daten, zum einen dem Dumpcycle, also wieviel Tagefr einen Zyklus verwendet werden sollen. Ist ein Dumpcycle sieben Tagelang, werden pro Tag ein Siebentel der Daten gesichert. Zustzlich sichertAmanda aber noch jene Daten inkrementell, die seit der ersten Sicherungverndert wurden.Wie schon bereits im Kapitel 3.7 erwhnt, sind Festplatten heutzutage inder Regel hinreichend gro und auch sehr billig, so das der Einsatz einerSpoolingplatte als Zwischenspeicher wrmstens empfohlen werden kann.Sichert Amanda direkt auf Band und die Daten kommen nicht schnell genugheran, fngt ein Streamer an Schuhe zu putzen, also immer wieder vor-und zurckzuspulen. Das tut der Mechanik und dem Band nicht wirklichgut und vermindert den weiteren Durchsatz dramatisch. Amanda untersttzteine Vielzahl an Bandlaufwerken und Wechseleinheiten, die ber Skripteangesteuert werden knnen.Seit geraumer Zeit verfgt Amanda ber RAIT - dem Redundant Array ofInexpensives Tapes. hnlich dem RAID fr Festplatten werden hier einfachmehrere Bnder eingesetzt und die Kapazitt und Ausfallsicherheit zu erh-hen, indem man bsp. einfach fnf Bnder verwendet vier fr Daten undeines fr eine XOR-Prfsumme. So kann man Partitionen sichern, die viermalso gro sind wie ein einzelnes Band und zustzlich noch die Integritt derSicherung erhhen. Da ein RAIT nicht einfach nacheinander die Sicherungen1 Windows-Freigabenhttp://www.amanda.org/6.1. Amandaauf Bnder schreibt, sondern parallel, bentigt es in diesem Falle auch fnfBandlaufwerke. Wenn das Sicherungssystem entsprechende Durchsatzratenerzeugt, erhht dieses Verfahren auch den Datendurchsatz.Allerdings kann Amanda einen dump-Lauf nicht auf mehrere Bnderverteilen. Ist der dump einer Partition grer als das Band, kann dump zumsichern dieser Partition nicht verwendet werden. Stattdessen kann man GNUTar verwenden und mittels Include/Exclude-Liste2 die Partition stckenund so auf mehrere Bnder verteilen.6.1.1 Einrichtung des ServersAmanda wird komplett per Konsole bzw. per Dotconf-Dateien konfiguriert.Nach der Installation aus pkgsrc/misc/amanda werden in /usr/pkg/etc/amanda die Standard-Konfigurationsdateien angelegt. Amanda erwartet nunfr jeden Konfigurationssatz ein eigenes Verzeichnis der Art /usr/pkg/etc/amanda/\emph{konfigname}.In jeder Konfiguration erwartet Amanda einige Dateien:.amandahosts Konfiguriert den Netzwerkzugriff hnlich /etc/hostsamanda.conf Allgemeine Konfiguration, Gerte, Zyklus etc.disklist zu sichernde Platten/Verzeichnisse (DLE = Disk List Entry)tapelist Liste der Bnder, von Amanda selbst verwaltet/etc/amandates Amandas quivalent zu /etc/dumpdates, sollte mit touch(1)angelegt werden/etc/inetd.conf Amandas Dienste mssen ber den inetd gestartet werdenDie Datei amanda.conf enthlt folgende Parameter:org Betreffzeile fr Berichtmailsmailto Empfnger der Berichtmailsdumpuser Benutzer der die Dumps durchfhrt. Standard ist [backup]inparallel Maximale Anzahl parallell laufender Dumps. (0-63)dumporder Priorisierungskriterium der Dumpreihenfolge. Mglich sindGre, Bandbreite und Zeit, jeweils auf- oder absteigend.netusage Maximal belegbare Bandbreite.dumpcycle Anzahl der Tage/Wochen fr einen Sicherungszyklus.runspercycle Durchlufe pro Zyklus, zum Beispiel (Wochen des dumpcy-cle) mal Werktagetapecycle Anzahl der Bnder Amanda bentigt, entspricht runspercycle +Sicherheitszuschlagruntapes Bnder je einzelnem Amandalauftpchanger Skript fr den Bandwechslertapedev Bandlaufwerk oder Verzeichnis, wenn auf Platte gesichert werdensoll (z. B: file:/mnt/amanda)tapetype Bandtyp, z. B. HP-DAT, DLT oder harddisk. Beispiele sind bereitsin der amanda.conf enthalten.reserve Reserviert n% der Spoolplatte fr inkrementelle Backups2 http://www.amanda.org/docs/topten.html#id255239958http://www.amanda.org/docs/topten.html#id25523996.1.2. Einrichtung der Clientslabelstr Ein RegEx der das Label fr die Bnder festlegt.Wie bereits erlutert, sollte Amanda unbedingt mit einer Spoolplatte be-trieben werden. Diese kann ebenfalls in der amanda.conf definiert werden.Ist eine Spoolplatte konfiguriert, benutzt Amanda diese um erst Clientdatenzu sammeln und dann von der Platte auf Band zu schreiben. Definiert manmehrere Spoolplatten, benutzt Amanda diese nach eigenem Gutdnken. Istein dump zu gro fr die Spoolplatte, wird er direkt aufs Band geschrieben.Wenn ein Band nicht beschrieben werden kann, weil es bspw. defekt oderschreibgeschtzt ist, wird ein sogenannter degraded mode erzeugt, die Siche-rung also nur auf die Spoolplatte geschrieben und nicht auf das Band. Hatman den Bandfehler behoben, kann man mit amflush die Spooldatei auf einBand schreiben. Eine Spoolplatte wird beispielhaft in Listing 6.1 definiert.1 holdingdisk hd1 { # Name der Platte2 comment "erste SCSI als Spoolplatte"3 directory "/mnt/sd0a/" # Mountpoint der Platte4 use 5500 MB # Maximal verfgbarer Platz5 #use -100 MB # Nutze gesamte Platte bis auf 100MB6 chunksize 1Gb # Gre einzelner Dateien, wenn der dump7 # auf mehrere Dateien verteilt werden sollListing 6.1: Spoolplatten fr Amanda definierenDie Konfiguration der Sicherungsparameter findet in den sogenanntendumptypes (Listing 6.2) statt. Hier wird bspw. festegelegt ob beim Sicherungs-lauf komprimiert werden sollDie eigentlichen zu sichernden Pfade legt man nun in der ./disklist (Listing6.3) an:Zu guter Letzt muss man noch die Amandadienste via /etc/inetd.conf(Listing 6.4) starten6.1.2 Einrichtung der ClientsAuf den Clients muss das Amanda-client Paket (pkgsrc/sysutils/amanda-client) installiert werden. Anschlieend wird in der /etc/inetd.conf (Lis-ting 6.5) der Amanda-Server gestartet und in der /usr/pkg/etc/amanda/.amandahosts (Listing 6.6) die Zugriffsrechte hnlich einer .rhosts vergeben.6.1.3 Programme im Amanda-PaketAmanda verfgt ber mehrere Programme, die mit dem Paket installiertwerden:amadmin Verwaltungsprogramm fr die Amandadaten. Kann bspw. Bnderfreigeben, lschen oder suchen und die Datenbank im-/exportieren.amcheck berprft die Konfigurationsdateien auf Fehler. Sollte zu denBrozeiten durchgefhrt werden.amcheckdb berprft die Banddatenbank auf Konsistenz, also ob alle auf-gefhrten Bnder in der Bandliste sind.amcleanup Bereinigt den Server nach einem Absturz. Normalerweise auto-matisch ausgefhrt wird es nur nach einem Systemfehler bentigt.amdd Amandas dd.amdump Startet den Sicherungslauf mit allen DLEs einer Konfiguration. DasProgramm fr den nchtlichen Cronlauf.amflush Schreibt dumps von der Spoolplatte auf Band.596.1. Amanda1 define dumptype always-full { # Name der Konf.2 global # dumptype global einbinden3 comment "Full dump of this filesystem always"4 compress none5 priority high6 dumpcycle 07 }89 define dumptype stantar {10 global # dumptype "global" einbinden11 program "GNUTAR" #gtar verwenden12 comment "standardtar"13 compress client fast # auf Client schnell komprimieren14 holdingdisk yes # Spoolplatte verwenden15 index # Inhaltsverzeichnis erstellen16 priority # high17 dumpcycle 7 # eine Woche Zyklus18 exclude list "/mnt/amanda.exclude"19 }2021 define dumptype root-tar {22 global23 program "GNUTAR"24 comment "root partitions dumped with tar"25 compress none26 index27 exclude list "/usr/amanda/exclude.gtar"28 priority low29 }Listing 6.2: dumptypes in amanda.conf definieren1 balmung.net-tex.de /mnt/source stantar2 balmung.net-tex.de /home always-full3 kusanagi.net-tex.de /home always-full4Listing 6.3: Zu sichernden Pfade in der disklist festlegen1 amanda dgram udp wait amanda \2 /usr/pkg/libexec/amandad amandad3 amandaidx stream tcp nowait amanda \4 /usr/pkg/libexec/amindexd amindexd5 amidxtape stream tcp nowait amanda \6 /usr/pkg/libexec/amidxtaped amidxtapedListing 6.4: Amanda-Server-Dienste starten1 amanda dgram udp wait amanda /usr/pkg/libexec/amandad amandadListing 6.5: Amanda-Client-Dienste starten1 localhost backup2 localhost rootListing 6.6: Zugriffsrechte auf dem Client konfigurieren606.1.4. Praktischer Einsatzamgetconf Gibt Parameter der Konfigurationsdateien wieder.amlabel Labelt ein Band. Amanda berschreibt kein gelabeltes Band undbenutzt keines ohne Label.ammt Amandas mt.amoverview Listet eine Tabelle auf in der angezeigt wird wann welchePartition mit welchem Level gesichert wurde. (hnlich dump -W)amrecover Durchsucht die Amanda Indizes um wiederherzustellende Da-teien auszuwhlen. Dateien knnen bspw. nach Datum gesucht werden.amrestore Spielt ein Backup vom Band zurck, so das es native zurckge-sichert werden kann.amrmtape Entfernt ein existierendes Band aus der Datenbank. Nur notwen-dig wenn das Band zerstrt wurde.amstatus Zustand der laufenden Sicherung.amtape Zugriff auf Bandwechsler, bspw. Band auswerfen oder das Laufwerkreinigen.amtoc Perlskript das ein Inhaltsverzeichnis aus einer Logdatei erzeugt.Kann idealerweise mit amdump in einem Cronjob kombiniert werden.amverify berprft ein Band auf Fehler.amverifyrun berprft alle Bnder des letzten Laufs auf Fehler.6.1.4 Praktischer EinsatzZuerst sollte man mit amcheck(8) die Konfiguration auf Fehler berprfen.Man kann dies auch automatisiert per Cron zu den blichen Brozeitenausfhren, so das rechtzeitig auftretende Probleme erkannt werden knnen.Anschlieend sollten alle Bnder, die verwendet werden soll, gelabelt werden.Dies kann man mit amlabel(8) tun, indem man es ggf. in ein Shellskripteinbindet (ntzlich fr Bandwechsler oder wenn man auf Festplatte sichert).Mit amdump(8) kann man vorerst von Hand den Sicherungslauf anstoenund die Benachrichtigungsemail studieren. Nach einem erfolgreichen Siche-rungslauf sollte das Band mit amverify(8) oder amverifyrun(8) berprftwerden. Mit amtoc(8) kann man nun aus dem Inhaltsverzeichnis des Siche-rungsbandes eine menschenlesbare ASCII-Datei machen, was recht ntzlichist, falls man nicht auf den Katalog zugreifen kann.Hat das System von Hand funktioniert, sollte man es in ein Shellskriptgieen (dokumentieren und sichern nicht vergessen) und von Cron aufrufenlassen.6.1.4.1 RcksicherungEinzelne Dateien, Verzeichnisstrukturen oder ganze Platten lassen sich mitamrestore zurckspielen. Als Optionen erwartet amrestore optional mehrereHostnamen, Plattennamen und Zeitstempel. Wird eine Option nicht gesetzt,werden alle Dateien getroffen und zurckgespielt, bergibt man also garkeine der Optionen, werden alle verfgbaren Sicherungen zurckgespielt.Hat man den Amanda-Index nicht mehr zur Verfgung, kann man Bnderauch mit amrecover auslesen. Normalerweise spielt amrecover die Dateiender Sicherungen nicht zurck an ihren alten Platz, sondern spielt nur dieArchivdateien von Band auf Festplatte. Mchte man die Archivdateien gleichentpacken und die Sicherungen so zurckspielen, brgibt die Option -p (wiePipe) und in einer Pipe das entsprechende Restoreprogramm, also GNU Taroder restore fr dump. Neben -p kann man auch -h angeben, um die Header616.2. Baculades Bandes auslesen zu knnen, oder -r um die Archive im Rohformat zuDebuggingzwecken vom Band lesen zu knnen.Hat man nicht einmal mehr amrecover zur Verfgung, ist dies wohl derGAU der Datensicherung. Solange die Bnder aber unbeschdigt sind, kannman die Images auch mit dd(1) vom Band herunterziehen. Dabei hilft Aman-das Headerdatei (Listing 6.7) am Anfang des Bandes, denn dort wird imKlartext angezeigt, wie man mit dd(1) und GNU Tar oder restore(8) dieDaten rcksichert.1 # mt rewind2 # dd if=/dev/nrst0 bs=32k count=1Listing 6.7: Amanda Header vom Band restaurierenWeitere Informationen zu Amanda finden Sie in (Weichinger und AmandaCore Team, 2006; leen Frisch, 2002) und zur Sicherung auf Festplatten in(Barth, 2004).6.2 baculaBacula ist ein System zur Datensicherung, das speziell fr verteilte Systemeentiwckelt wurde. Es besteht aus verschiedenen Dmons, die relativ einfachden Client-Server-Betrieb ermglichen.Bacula besteht aus folgenden Dmons: Director (bacula-dir) Storage (bacula-sd) File (bacula-fd) Catalog (PostgreSQL) Console (bconsole)Der Director luft als Steuerungsprozess im Hintergrund und koordi-niert alle Sicherungsaktivitten. Er wird eingesetzt um Daten zu sichern undwiederherzustellen und um Aufgaben zu planen.Der Storage-Dmon bernimmt das Schreiben der Daten auf die Bn-der3 und ggf. das Wiedereinlesen der Bnder.Der File-Dmon liefert die Daten des zu sichernden Rechners auf Befehldes Directors an den Storage-Dmon. Der File-Dmon ist betriebssyste-mabhngig. Fr NetBSD kann er via pkgsrc installiert werden, fr andereUnix-artige steht er ebenfalls zur Verfgung. Weiterhin existiert ein Client-Programm fr MS-Windows Rechner.Der Catalog speichert alle Metadaten zu den Sicherungslufen, alsoDaten wie: welche Datei wurde in welcher Version wann auf welches Bandgesichert und hat dabei folgenden Prfsumme?. Mit ihm ist es mglich dieSicherungsbnder zu organisieren und ggf. im Falle einer Rcksicherung dasgewnschte Band zu finden.Da hierzu mehr als eine einfache Textdatei notwendig ist, kann sich Baculaan SQLite, PostgreSQL oder MySQL binden. Ich beschrnke mich hierbeiauf PostgreSQL4. Der Catalog ist wichtig, wenn man Dateien zur Rcksiche-rung suchen will. Daher sollte er zwingend gesichert werden, das Bacula-Handbuch zeigt wie mann den Katalog sichert und fr eine Notfall-CDaufbereitet. Auerdem kann man PostgreSQL-eigene Funktionen verwenden,um den Katalog zu sichern.3 oder auch CDs, DVDs, Festplatte, 8-Disketten4 Niemand will seine Datensicherung MySQL anvertrauen.SQLite ist hinreichen, wenn man keinen Wert auf umfangreiche Datenbankfunktionen legt.62http://dev.mysql.com/doc/refman/5.0/en/blackhole-storage-engine.html6.2.1. InstallationDie Console ermglicht den Zugriff auf die Bacula-Dienste. Neben einereinfachen Shell-basierten Textkonsole existieren auch klicki-bunte Variantenfr Gnome, Java oder mit wxWidgets.Alle Komponenten kommunizieren ber das Netz miteinander und kn-nen so auf verteilten Systemen eingesetzt werden. Zur Authentifizierungverwenden sie CRAM-MD5 und zur Verschlsselung kann TLS eingesetztwerden.Bacula untersttzt Bandlaufwerke, Bandwechsler und Sicherungen aufFestplatte. Tgliche Bandrotation wird durch multiple Pools ermglicht.Um die Konfiguration zu vereinfachen, wird sie in verschiedene Direktivenzerlegt, das FileSet definiert was gesichert wird, der Client welcher Rechnergesichert wird, der Schedule wann gesichert wird und der Pool wohingesichert wird.Bacula verwendet keine Level wie dump, stattdessen wird im Schedule einZeitpunkt und die Sicherungsart (Full, Incremental und Differential) festgelegt.6.2.1 InstallationBacula ist als pkgsrc/sysutils/bacula in Pkgsrc erhltlich. Ein Windows-Client existiert ebenfalls, er ist auf der Bacula-Seite erhltlich und wird wieein Uniix-bacula-fd konfiguriert.Bacula wird standardmig mit SQLite als Katalog kompiliert. Um Post-greSQL anzubinden, muss man die Paketoptionen in /etc/mk.conf aufPKG_OPTIONS.bacula= -catalog-sqlite catalog-pgsql setzen.Mit dem blichen make install clean wird bacula nun installiert.Fr den Einsatz auf Clients, kann man pkgsrc/sysutils/bacula-clientonlyverwenden.Um die Datenbank einzurichten, liegen in /usr/pkg/libexec/bacula ver-schiedene Shellskripte bereit. PostgreSQL wird gem Listing 6.8 eingerich-tet.1 # mkdir /usr/postgres && chown -R pgsql.pgsql /usr/postgres2 # su - pgsql3 pgsql$ initdb /usr/postgres4 [...]5 pgsql$ /usr/pkg/libexec/bacula/create_postgresql_database6 pgsql$ /usr/pkg/libexec/bacula/make_postgresql_tables7 pgsql$ /usr/pkg/libexec/bacula/grant_postgresql_privileges8 [...]9 CREATE USER10 pgsql$ psql bacula11 Welcome to psql 8.0.4, the PostgreSQL interactive terminal12 bacula=#Listing 6.8: PostgreSQL fr Bacula einrichten6.2.2 KonfigurationZur Konfiguration verwendet Bacula verschiedene Direktiven in den D-mons. Bevor man sich an die Konfiguration macht, sollte man ein vorhande-nes Bandlaufwerk auf Kompatibilitt mit Bacula testen. Dazu gibt (Sibbald,2006b, Kap. Testing Your Tape Drive With Bacula) eine ausfhrliche Schritt-fr-Schritt-Anleitung. Um PostgreSQL zu starten, kann man/usr/bin/su -mpgsql -c '/usr/pkg/bin/pg_ctl -D /usr/postgres/ -l /usr/postgres/logfilestart&' in /etc/rc.local einfgen. Fr Baculas Dmons existieren insgesamtdrei rc-Skripte, die man nach /etc/rc.d kopieren und in /etc/rc.conf startenkann, siehe Listing 6.9.636.2. BaculaTabelle 10.: Baculas PostgreSQL-DatenbankSchema Name Type Ownerpublic basefiles table baculapublic basefiles_baseid_seq sequence baculapublic cdimages table baculapublic client table baculapublic client_clientid_seq sequence baculapublic counters table baculapublic device table baculapublic device_deviceid_seq sequence baculapublic file table baculapublic file_fileid_seq sequence baculapublic filename table baculapublic filename_filenameid_seq sequence baculapublic fileset table baculapublic fileset_filesetid_seq sequence baculapublic job table baculapublic job_jobid_seq sequence baculapublic jobmedia table baculapublic jobmedia_jobmediaid_seq sequence baculapublic media table baculapublic media_mediaid_seq sequence baculapublic mediatype table baculapublic mediatype_mediatypeid_seq sequence baculapublic path table baculapublic path_pathid_seq sequence baculapublic pool table baculapublic pool_poolid_seq sequence baculapublic status table baculapublic storage table baculapublic storage_storageid_seq sequence baculapublic unsavedfiles table baculapublic version table baculaTabelle 11.: Baculas Table public.fileColumn Type Modifiersfileid integer not null default nextval(public.file_fileid_seq::text)fileindex integer not null default 0jobid integer not nullpathid integer not nullfilenameid integer not nullmarkid integer not null default 0lstat text not nullmd5 text not nullIndexes:"file_pkey" PRIMARY KEY, btree (fileid)"file_fp_idx" btree (filenameid, pathid)"file_jobid_idx" btree (jobid)646.2.2. Konfiguration1 #cp /usr/pkg/share/examples/rc.d/bacula /etc/rc.d/2 # echo 'bacula=yes' >> /etc/rc.conf3 #cp /usr/pkg/share/examples/rc.d/bacula-dir /etc/rc.d/4 # echo 'baculadir=yes' >> /etc/rc.conf5 #cp /usr/pkg/share/examples/rc.d/bacula-sd /etc/rc.d/6 # echo 'baculasd=yes' >> /etc/rc.conf7 #cp /usr/pkg/share/examples/rc.d/bacula-fd /etc/rc.d/8 # echo 'baculafd=yes' >> /etc/rc.confListing 6.9: Bacula per rc.d startenSind alle notwendigen Prozesse gestartet, kann man mit der bconsole Ver-bindung zum Server aufnehmen. Allerdings sucht bconsole standardmigim aktuellen Verzeichnis nach der Konfigurationsdatei bconsole.conf. EineBeispieldatei befindet sich in /usr/pkg/share/examples/bacula/bconsole.conf, so das man die Datei bspw. ins Homeverzeichnis kopieren und anpas-sen kann oder einfach ein passendes Alias in der Shell erzeugt.Man kann hier Sicherungslufe starten, stoppen oder auch berwachen.Stattdessen kann man Bacula auch in gewohnter Manier mit vi(1) in den .conf-Dateien anpassen. Standardmig hat Bacula bereits zwei FileSets definiert,nmlich Full Set, das das Quellverzeichnis von Bacula sichert, und Catalog,das den Index von Bacula sichert.1 $ bconsole -c /usr/pkg/share/examples/bacula/bconsole.conf2 Connecting to Director balmung:91013 1000 OK: balmung-dir Version: 1.38.2 (20 November 2005)4 Enter a period to cancel a command.5 *time6 17-Jan-2006 21:55:387 *version8 balmung-dir Version: 1.38.2 (20 November 2005)9 *show filesets10 FileSet: name=Full Set11 O M12 N13 I /usr/pkgsrc/sysutils/bacula/work/bacula-1.38.214 N15 E /proc16 E /tmp17 E /.journal18 E /.fsck19 N20 FileSet: name=Catalog21 O M22 N23 I /var/spool/bacula/bacula.sql24 NListing 6.10: Baculas bconsole startenNeue Filesets werden in /usr/pkg/etc/bacula/bacula-dir.conf defi-niert. Dazu gibt es eine einfache Grammatik, die ausfhrlich im Handbuch(Sibbald, 2006b) beschrieben ist. Listing 6.11 zeigt eine Beispielkonfiguration.Jedes FileSet kann beliebig mit JobDefs kombiniert werden. So kann manbspw. verschiedene Jobs definieren in dem in einem Job ber einen lngerenZeitraum Komplett und Inkrementell sowie sonntags Komplett gesichertwird. Die sonntglichen Bnder knnen dann archiviert oder ausgelagertwerden.656.2. BaculaTabelle 12.: Baculas Table public.filenameColumn Type Modifiersfilenameid integer not null default nextval(public.filename_filenameid_seq::text)name text not nullIndexes:"filename_pkey" PRIMARY KEY, btree (filenameid)"filename_name_idx" btree (name)Tabelle 13.: Baculas bconsole-BefehleBefehl Wirkungadd add media to a poolautodisplay autodisplay [on/off] console messagesautomount automount [on/off] after labelcancel cancel job=nnn cancel a jobcreate create DB Pool from resourcedelete delete [pool= | media volume=]estimate performs FileSet estimate debug=1 give full listingexit exit = quithelp print this commandlabel label a tapelist list [pools | jobs | jobtotals | media |files jobid=]; from catalogllist full or long list like list commandmessages messagesmount mount prune prune expired records from catalogpurge purge records from catalogquery query catalogquit quitrelabel relabel a taperelease release restore restore filesrun run setdebug sets debug levelshow show (resource records) [jobs | pools | ... | all]sqlquery use SQL to query catalogstatus status [storage | client]=time print current timeunmount unmount update update Volume or Pooluse use catalog xxxvar does variable expansionversion print Director versionwait wait until no jobs are running666.2.2. Konfiguration1 FileSet {2 Name = "home"3 Include {4 Options {5 signature = MD56 compression = GZIP7 verify = pins58 onefs = no9 sparse = yes10 }11 File = /home12 File = /etc13 File = /usr/pkg/etc14 File = /var/15 }16 Exclude {17 File = /home/stefan/temp18 File = /var/tmp19 }20 }2122 JobDefs {23 Name = "HomeRun"24 Type = Backup25 Level = Incremental26 Client = balmung-fd27 FileSet = "home"28 Schedule = "WeeklyCycle"29 Storage = File30 Messages = Standard31 Pool = Default32 Priority = 1033 }3435 Schedule {36 Name = "WeeklyCycle"37 Run = Full sun-sat at 21:0038 Run = Differential 2nd-5th sun at 21:0039 Run = Incremental mon-sat at 21:0040 }Listing 6.11: Beispiel einer Konfiguration fr Bacula676.2. BaculaWeitere Informationen zu Bacula finden Sie in (Sibbald, 2006b,a,c,d).6.2.3 RcksicherungZur Rcksicherung verwendet Bacula ebenfalls wieder JobDefinitions, dieseknnen aber manuell in der Konsole angepasst werden. In der Konsole gibtes den Befehl restore, dessen Ausgabe in 6.12 gezeigt wird.1 *restore23 First you select one or more JobIds that contain files4 to be restored. You will be presented several methods5 of specifying the JobIds. Then you will be allowed to6 select which files from those JobIds are to be restored.78 To select the JobIds, you have the following choices:9 1: List last 20 Jobs run10 2: List Jobs where a given File is saved11 3: Enter list of comma separated JobIds to select12 4: Enter SQL list command13 5: Select the most recent backup for a client14 6: Select backup for a client before a specified time15 7: Enter a list of files to restore16 8: Enter a list of files to restore before a specified time17 9: Find the JobIds of the most recent backup for a client18 10: Find the JobIds for a backup for a client before a specified time19 11: Enter a list of directories to restore for found JobIds20 12: CancelListing 6.12: Daten mit Bacula rcksichern (1)Es bestehen die in Tabelle 14 automatisch konfigurierten Mglichkeitenzur Rcksicherung (gem Listing 6.12):686.2.3. RcksicherungTabelle 14.: Daten mit Bacula rcksichern (2)1. Die letzten 20 Jobs knnen restauriert werden2. Es werden alle Jobs angezeigt, die eine bestimmte Datei gesichert haben.Einer der Jobs kann restauriert werden.3. Eine kommaseparierte Liste mit JobIds wird bergeben.4. Man kann SQL-Anfragen stellen um die passende JobId zu finden.Diese ID kann dann mit Punkt 3 restauriert werden.5. Sichert den letzten Stand eines Clients zurck, in dem alle notwendigenSicherungen identifiziert werden.6. Wie 5.), allerdings kann man ein Datum spezifizieren7. Eine Datei mit zurckzusichernden Dateinamen wird eingelesen8. Man kann Dateinamen und ein korrespondierendes Datum angeben9. Wie 6.), man kann danach aber mit den JobIds wie in Punkt 11.) weiter-machen10. Wie 9.), die JobIds werden aber intern bergeben11. Man kann JobIDs und Pfadnamen bergeben. Es werden dann alleangegebenen Verzeichnisse (ohne Unterverzeichnisse) wiederhergestellt12. Bricht restore ab.696.2. Bacula70Teil IVPOSTGRESQL7SICHERUNG EINES POSTGRESQL-SERVERSThree things are certain:Death, taxes, and lost data.Guess which has occurred.7.1 den datenbankcluster sichernDie Sicherung einer Datenbank ist einer der wichtigsten Punkte beim Be-trieb eines Datenbankservers. PostgreSQL bietet verschiedene MglichkeitenAnwendungsdaten zu sichern.PostgreSQL legt alle Daten im sogenannten Cluster, also einem bestimm-ten Verzeichnis, ab. Es ist mglich dieses Verzeichnis wie normale Dateienzu sichern, nach der Wiederherstellung des Servers zurckzuspielen undPostgreSQL dann mit diesem Cluster zu starten. Problematisch bei der Siche-rung ist die Konsistenz des Dateisystems, da im Cluster die Schreibaktivittentsprechend hoch ist. Abhilfe schaffen hier Dateisystem-Snapshots (sieheKap. 5.3), die einen konsistenten Zustand des Dateisystems als Pseudogerteinbinden, das anschlieend gesichert werden kann.Ein gesicherter PostgreSQL-Cluster kann allerdings nur mit genau derselben PostgreSQL-Version gelesen werden, mit der er erzeugt wurde. Diesbedeutet das nach einem Totalausfall des Systems wieder die alte PostgreSQL-Version installiert werden muss.Es empfiehlt sich den PostgreSQL-Cluster auf eigenen Partitionen, oderbesser noch, eigenen Festplatten abzulegen. Dies verringert den Administra-tionsaufwand und kann den Datendurchsatz des Servers erhhen.Seit Version 8.0 untersttzt PostgreSQL sog. Table-Spaces, d.h. da kom-plette Datenbanken, aber auch einzelne Tabellen, Indizes oder Schemas aufbeliebige Verzeichnisse verteilt werden knnen. Dies ermglicht den Einsatzmehrerer Festplatten, was Kapazitt und Durchsatz erhhen kann. Allerdingssollte beim Sichern des PostgreSQL-Clusters dann auch bedacht werden alleeingesetzten Table-Spaces mitzusichern.Listing 7.1 zeigt wie man PostgreSQLs Cluster sichert und wieder zurck-spielt.1 # fssconfing -x -c fss0 /pgcluster02 # fssconfing -x -c fss1 /pgcluster13 # dump -0a -f /mnt/nfs/back/pcluster0.0 /dev/fss04 # dump -0a -f /mnt/nfs/back/pcluster1.0 /dev/fss15 # fssconfig -u fss0 && fssconfig -u fss167 # restore -r -f /mnt/nfs/back/pcluster0.08 # restore -r -f /mnt/nfs/back/pcluster1.09 # chown pgsql.pgsql /pgcluster0 /pgcluster110 # su -m pgsql -c 'pg_ctl -D /pgcluster0 -l /pgcluster0/logfile start&'11 # su -m pgsql -c 'pg_ctl -D /pgcluster1 -l /pgcluster1/logfile start&'Listing 7.1: PostgreSQL-Cluster mit dump sichern7.2 point-in-time-recoveryDer Einsatz von Point-in-Time-Recovery Mechanismen ermglicht das Zu-rcksetzen der Datenbank in einen konsistenten Zustand, der an einembeliebigen Zeitpunkt vorgelegen hat.7.2. Point-in-Time-RecoveryPostgreSQL ab Version 8.0 verwendet die sogenannten Write Ahead Logs(WAL) um jede nderung am Datenbestand mitzuschneiden. Muss dasSystem zurckgesetzt/-sichert werden, knnen die nderungen seit demletzten Checkpoint abgespielt werden, um den letzten konsistenten Zustandzu erreichen. Befindet sich der Cluster in einem inkonsistenten Zustand,wird durch einspielen der WALs wieder ein konsistenter Zustand erreicht.Die WALs werden hnlich dem Journal eines Journaling-Dateisystemsfortlaufend weitergeschrieben. So werden alle Transaktionen1 protokolliertund knnen bei Bedarf neu eingespielt werden. Innerhalb einer bestimmtenZeit werden die Transaktionen dann auf den eigentlichen Datenbestandbernommen. Dies erhht dabei sogar den Datendurchsatz, da es einfacherist Daten einfach an eine Datei anzuhngen, als stndig im Datenbestand derDatenbank hin- und herzuspringen.Wenn man den Datenbankcluster und alle WAL-Logs danach sichert,kann man einen beliebigen Zustand der Datenbank im Zeitfenster der Logswiederherstellen.Da alle Transaktionen im Log sequentiell fortgeschrieben werden, wr-den die Protokolle unaufhrlich wachsen und irgendwann das Dateisystemberlaufen lassen. Daher werden die Logs ganz einfach rotiert, das heitman definiert2 einfach wieviele Dateien es geben soll, und wenn diese Zahlerreicht ist wird wieder in die erste Datei geschrieben. Um die Logdateienzu sichern, muss man daher die Logs vor der Rotation auf einen anderenDatentrger koperien. Dies geschieht, in dem man in der postgresql.conf dieOption archive_command wie in Listing 7.2 beschrieben setzt, so das die Log-dateien vor dem berschreiben in ein anderes Verzeichnis kopiert werden.Dabei sollte darauf geachtet werden, da der Befehl auch ausgefhrt wird,da ihn PostgreSQL sonst bis zum Gelingen wiederholt. So kann es unterUmstnden vorkommen, da das Dateisystem mit WAL-Dateien volluft, dadie Rotation der Logs nicht durchgefhrt werden kann.1 archive_command = 'cp %p /usr/backup/postgres-wal/%f'Listing 7.2: postgresql.conf-Konfig zur Sicherung der LogsUm eine Sicherung des Datenbankclusters durchzufhren, muss man dieDatenbank vor- und nachbereiten. Dazwischen kann der Datenbankclustergesichert werden. Dies geschieht mit den SQL-Befehlen in Listing 7.3, dortwird der Datenbankcluster zur Sicherung vorbereitet und gesichert, anschlie-end wird der Backup-Checkpoint entsperrt und es knnen die neuen WALsrotiert werden. Hat man einen derart gesicherten Datenbankcluster, reicht esaus die WALs die danach erzeugt werden zu sichern.1 $ echo "select pg_start_backup('Label');" | psql -U pgsql template12 # fssconfig -x -c fss0 /pgcluster /3 # dump -0 -f /usr/backuppgcluster.0 /dev/fss04 # fssconfig -u fss05 $ echo "select pg_stop_backup();" | psql -U pgsql template1Listing 7.3: PostgreSQL-Datenbankcluster und WALs sichernUm ein derartig gesicherten Datenbestand zurckzuspielen, sind folgendeSchritte notwendig:1. PostgreSQL neu installieren oder anhalten2. Sicherung des Datenbankclusters zurckspielen1 PostgreSQL behandelt jede DML-Aktion als ACID-konforme Transaktion in Sinne derDatenbankentheorie2 Standardmig existieren in pg_xlog/ drei WAL Dateien mit je 16MB Gre. Diese Grekann beim kompilieren des Servers angegeben werden, die Anzahl in postgresql.conf743. recovery.conf erstellen und4. restore_command und recovery_target_time setzen5. PostgreSQL startenPunkt 2 wird erledigt, indem man den Dump aus Listing 7.3 mit restore-r -f /usr/backuppgcluster.0 zurckspielt und ggf. die Dateirechte an-passt.Punkt 3 und 4 setzen die entsprechende Befehle, die der Postmaster ausfh-ren soll. restore_command ist der Befehl, um die WALs zurckzukopieren, al-so etwas derart: restore_command=cp /usr/backup/postgres-wal/%f %p,recovery_target_time erwartet einen Zeitstempel, bis zu dem rckgesi-chert werden soll.7.3 pg_dump, pg_dumpall und pg_restorePostgreSQL verfgt auch ber ein Werkzeug um logische Backups zu er-zeugen. Dabei werden SQL-Befehle zum Erstellen der Datenbank(en) ineine einfache ASCII-Textdatei oder ein Archiv geschrieben. Die entstandeneASCII-Datei kann danach mit Sicherungsmechanismen fr Dateisystemegesichert werden.Um eine Datenbank zu sichern, benutzt man pg_dump(1), um alle Daten-banken in eine Datei zu sichern existiert pg_dumpall(1).1 $ /usr/pkg/bin/vacuumdb -Upgoperator -f -z meineDB23 $ /usr/pkg/bin/pg_dump -Fc -Upgoperator -meineDB >4 /home/pgsql/meineDB_`date +%y%m%d`56 $ /usr/pkg/bin/pg_dumpall > pg_`date +%y%m%d`Listing 7.4: PostgreSQL-Datenbanken sichernDer erste Befehl in Listing 7.4 bereinigt die Datenbank meineDB alsPostgreSQL-Benutzer pgoperator. Der dritte Befehl schreibt die Datenbankmit LOBs komprimiert in eine Sicherungsdatei.Der letzte Befehl verwendet pg_dumpall(1) um alle Datenbanken in eineDatei zu sichern.1 $ createdb meineDB2 $ pg_restore -d meineDB -f meineDB_0512063 $ psql -f pg_051206 template1Listing 7.5: Rckspielen von PostgreSQL-SicherungenZum Rckspielen einer mit pg_dump(1) erzeugten Sicherung verwendetman pg_restore(1). Dazu muss die rckzusichernde Datenbank vorher al-lerdings schon mit createdb(1) erstellt worden sein. Anders verhlt es sichmit pg_dumpall(1), denn dessen Sicherung enthlt alle Befehle um die gesi-cherten Datenbanken neu anzulegen, so das man sich mit einer beliebigenDatenbank verbinden kann.7.4 replikationReplikationssysteme synchronisieren den Datenbestand von mehreren Ser-vern. Dies kann auf verschiedene Arten geschehen, beispielsweise synchron/asynchron oder voll/teilweise.757.4. ReplikationSomit ist es mglich ein Ersatzsystem bereitzuhalten, das per Replikationauf dem aktuellen Stand des Originals gehalten wird und bei dessem Ausfalldessen Funktion bernehmen kann.Asynchrone Replikation verteilt die Daten erst nach einem erfolgrei-chen BEGIN ... COMMIT-Block auf die angeschlossenen Replikanten. Diesschrnkt das System aber etwas ein: nur ein einziger Master sinnvoll, da sonst Konsistenzprobleme drohen(OIDs, Primrschlssel) keine Lastverteilung vorgebbarSynchrone Replikation hingegen verteilt die Daten sofort bei Beginn derTransaktion, so das diese auf allen Rechnern ausgefhrt wird. Hierbei istallerdings die Konsistenz der Rechner untereinander ein Problem, dennes muss auf allen Maschinen ein erfolgreicher COMMIT garantiert werden.Die Slaves informieren nach einem erfolgten Schreibzugriff den Master vonder Transaktion, so das weitere Schreibtransaktionen ausgefhrt werdenknnen. Dieses Verfahren wird Zwei-Phasen-Commit genannt, da der Masterjedesmal auf die Slaves warten muss, bevor eine Transaktion endgltig frden gesamten Rechnerverbund als commited markiert wird. So wird zwareine sofortige Replikation des Datenbestandes erreicht, allerdings auf Kostendes Durchsatzes, da diese Transaktion eben auf jedem Rechner erfolgen mussund der Erfolg an den Master zurckgemeldet werden muss.7.4.1 Synchrone Replikation mit PgpoolPgpool fungiert als sogenannter Connection Pool, d.h. er klinkt sich zwi-schen den eigentlichen PostgreSQL-Server und die Anwendungen. Diesfunktioniert im Prinzip wie bei einem transparenten Proxy. Pgpool cachedVerbindungen zum Datenbankserver, um so Lasten durch Verbindungsauf-und -abbau zu reduzieren. Weiterhin kann sich Pgpool mit zwei PostgreSQL-Servern verbinden und und so im Falle eines Ausfalls auf den anderen, nochfunktionierenden, Server umschalten.Zwischen den beiden PostgreSQL-Servern kann Pgpool auerdem als syn-chroner Replikationsserver fungieren, d.h. alle Datenbankenanfragen werdenan beide Postmaster geschickt. Dies ermglicht eine einfache Replikationdes Datenbestandes auf zwei verschiedene Rechner, die lediglich durch dasNetzwerk miteinander verbunden sein mssen. Diese Methode schliet al-lerdings einige Operationen aus die bspw. Abhngig vom Server (Abfrageder OID, eines Zeitstempels oder hnliches) oder eben nicht deterministisch(z. B. Zufallsgenerator) sind.Pgpool lsst sich aus pkgsrc/databases/pgpool installieren. Zur Konfi-guration gengt es /usr/pkg/share/examples/pgpool.conf.sample nach/usr/pkg/etc/pgpool.conf zu kopieren und anzupassen. Die Konfigurati-onsdatei ist wohldokumentiert und recht einfach zu verstehen. Wichtig sindfolgende Optionen: listen_addresses und port zu benutzende Netzwerkadresse und Port backend_host_name und backend_port Netzadresse und Port desPostgreSQL-Servers secondary_backend_host_name und secondary_backend_port Netz-adresse und Port des zweiten PostgreSQL-Servers (Slave) replication_mode Einsatz als Replikationssystem replication_strict Wenn aktiviert, werden Deadlocks vermieden, wasauf Kosten des Durchsatzes geht.767.4.1. Synchrone Replikation mit Pgpool replication_timeout Wenn replication_strict deaktiviert ist knntenDeadlocks auftreten. Dieser Wert gibt den Timeout in s an, nachdemdie blockierte Transaktion abgebrochen wird. replication_stop_on_mismatch Der Replikationsmodus soll bei inkon-sisten Daten zwischen Master und Slave abgebrochen werden.Hat man Pgpool wie in Listing (7.6) konfiguriert, kann man sich an local-host:9999 mit dem Datenbankterminal verbinden. Alle DML-Operationenwerden dann auf beiden PostgreSQL-Servern ausgefhrt.Mit pgpool switch kann man die Server umschalten, bspw. mit pgpool -smaster switch die Verbindung zum Master beenden und auf den SecondaryServer umschalten.1 listen_addresses = 'localhost'2 port = 999934 socket_dir = '/tmp'56 backend_host_name = '192.168.2.1'7 backend_port = 543289 backend_socket_dir = '/tmp'1011 secondary_backend_host_name = '192.168.2.2'12 secondary_backend_port = 54321314 replication_mode = true15 replication_strict = true16 replication_timeout = 50001718 replication_stop_on_mismatch = false1920 reset_query_list = 'ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT'2122 print_timestamp = trueListing 7.6: Pgpool-Konfiguration fr die Replikation777.4. Replikation78Teil VSONSTIGE PROGRAMME8SONSTIGE PROGRAMMENarrensichere Systeme sind meist nicht vonNarren geprft.(Erhard Blanck)8.1 magnetbnder ansteuern mit mt(1)mt(1) ist kein eigentliches Sicherungsprogramm, sondern das Magnetic TapeManipulation Programme. Dieses Programm dient dazu Bandlaufwerke zubedienen indem diese bspw. zurckgespult und offline geschaltet oder 3Dateien vorgespult werden.12 # mt rewoffl3 # mt -f /dev/nrst0 fsf 3Listing 8.1: Bnder mit mt manipulierenDer erste Befehl spult das Band zurck und schaltet es offline, der Zweitespult drei Dateien auf dem Nonrewinding Tapedevice /dev/nrst0 vor.Befehl Wirkungasf spule n Dateien vom Anfang des bandes voreof, weof schreibe n EOF-Marken an jetziger Bandpositionfsf spule n Dateien vorfsr spule n Blcke vorbsf spule n Dateien zurckbsr spule n Blcke zurckrewind zurckspulenoffline, rewoffl Zurckspulen und Streamer offline schalten (Band auswerfen)status Status des Streamers angebenretension Band spannen (gerteabhngig)erase Band lschen (gerteabhngig)eew end-of-media Frhwarnung mit 0 deaktivieren, 1 aktivierteom Bis zum Ende der Aufzeichnung (EOF-Marke) vorspulenblocksize, setblk Setzt die Blockgre auf n, 0 ist variable Blockgredensity, setdensity Setzt die Banddichterdspos logische Bandposition anzeigen (gerteabhngig)rdhpos physikalische Bandposition anzeigen (gerteabhngig)setspos logische Bandposition setzen (gerteabhngig)sethpos physikalische Bandposition setzen (gerteabhngig)compress 1 aktiviert Komprimierung, 0 deaktiviertListing 8.2: mt(1)-Optionen8.2 datenstrme puffernBandlaufwerke arbeiten mit einer festen Laufgeschwindigkeit des Bandes.Kommt der schreibende Prozess nicht mit dem Anliefern der Daten nach,wird das Band vor- und zurckgespult. Dies ist schlecht fr den Durchsatz8.4. Dateien mit find(1) findenund belastet das Band und das Laufwerk mechanisch. Um derartiges Verhal-ten zu verhindern, gibt es Programme, die den Datenstrom zwischenpuffern.Lediglich dump(8) verfgt ber eingebaute Pufferungsmechanismen.Team und Buffer sind aus pkgsrc/misc installierbar. Sie werden einfachin eine Pipe zwischengeschaltet (siehe Listing 8.3) und leiten die Ausgabeentsprechend auf das Bandlaufwerk um.Problematisch ist hierbei die Fehlerbehandlung in Skripten, da ja nunmehrere Programme in der Pipe verkettet werden. Auerdem funktioniertdie EOM-Erkennung der Sicherungsprogramme nicht mehr. Lediglich Bufferist in der Lage das Bandende selbstndig zu erkennen.1 # tar c f - /home | buffer -o /dev/nrst0Listing 8.3: Datenstrme puffern8.3 dateien mit split(1) zerlegenIst eine Datei zu gro um auf ein Medium, bspw. eine CD oder ein Band,zu passen, kann man sie mit split(1) zerlegen. Split erwartet lediglich dieGre der zu erzeugenden Dateien (in Byte, Kilobyte oder Megabyte), denNamen der zu zerlegenden Datei und optional einen Prfix fr die erzeugtenDateien. Standardmig generiert split Dateinamen fr die Ausgabe selbst,und zwar nach dem Muster x[a-z][a-z]. Gibt man einen Prfix an, wird dieserder Art prfix[a-z][a-z] gebraucht. Gesplittete Dateien lassen sich einfachmit cat(1) wieder zusammensetzen.1 $ split -b 3m netbsd kernel2 $ ls -lh3 total 17M4 -rw-r--r-- 1 stefan stefan 3.0M Feb 18 20:34 kernelaa5 -rw-r--r-- 1 stefan stefan 3.0M Feb 18 20:34 kernelab6 -rw-r--r-- 1 stefan stefan 2.5M Feb 18 20:34 kernelac7 -rwxr-xr-x 1 stefan stefan 8.5M Feb 18 20:33 netbsd89 $ for i in kernela*10 > do11 > cat $i >> neu ;12 > done13 $ md5 netbsd neu14 MD5 (netbsd) = 06c31725e23e432e4e040c1e37ac0e1615 MD5 (neu) = 06c31725e23e432e4e040c1e37ac0e1616 $Listing 8.4: Dateien zerlegen und zusammensetzen8.4 dateien mit find(1) findenFind kann dazu benutzt werden Dateien zu finden. Es kann mit verschiede-nen Optionen gefttert werden, bspw. Regulren Ausdrcken zum Datein-amen oder Zeitpunkte, an denen Dateien gendert wurden.Listing 8.5 zeigt einige Beispiele fr find(1). Der erste Befehl gibt die Pfadealler *.tex und *.pdf in /home aus. Dabei kann anstatt des Sterns auch einbeliebig komplexer Regulrer Ausdruck verwendet werden.Zeile 2 und 3 verknpfen find(1) mit grep(1) allerdings mit einem kleinenUnterschied. Zeile 2 sucht nach test im Dateinamen findet also nur Datei-en die irgendwie test heien. Zeile 3 hingegen bergibt den Pfadnamen dergefundenen Dateien an grep(1), so da grep(1) den Dateiinhalt untersucht.821 1$ find /home/ -name '*.tex' -or -name '*.pdf'2 2$ find /home/ -name '*.tex' -printx | grep test3 3$ find /home/ -name '*.tex' -printx | xargs grep test4 4$ find /home -mtime 75 5$ find /home/ -user wwwListing 8.5: Dateien mit find(1) findenDie 4. Zeile sucht nach Dateien, die vor 7 Tagen gendert wurden. Zeile 5schlielich, sucht nach Dateien die dem Benutzer www gehren.8.5 das kryptographische dateisystem cfsCFS ist das Cryptographic Filesystem von AT&T. Die Dateien liegen hierbeiverschlsselt auf der Festplatte und werden ber einen NFS hnlichen Me-chanismus entschlsselt zur Verfgung gestellt. Fr ein Backup heisst dies,das die Dateien entweder entschlsselt gesichert werden und das Archiv da-nach entsprechend zu schtzen ist, oder aber das die verschlsselten Dateiengesichert werden. Dabei ist es aber nachteilig das die verschlsselten Dateienauch einen verschlsselten Dateinamen haben und so nicht sehr einfach zuidentifizieren sind. Daher sollte man hierbei auf find(1) oder entsprechendeDatumsmechanismen der Programme vertrauen und inkrementell nach Zeitsichern.Ich setze CFS in meinem Homeverzeichnis seit mehreren Jahren ein undkonnte bisher keine Probleme mit Dump/Restore und verschiedenen Levelnfeststellen, da sich cfs-verschlsselte Verzeichnisse wie ganz normale Dateienverhalten.8.6 das kryptographische pseudogert cgdcgd(4) ist der Cryptographic Devicedriver, der den Einsatz verschlsselterPartitionen ermglicht. Wird cgd(4) verwendet um eine Partition zu scht-zen, ist die Backupstrategie anzupassen d.h. die Partition muss entschlsselteingebunden und die erzeugten Archive verschlsselt werden.Als Beispiel wird in Listing 8.6 auf einem Rechner die Partition /dev/wd0evia cgd(4) verschlsselt und als /dev/cgd0d nach /home gemountet.Die Sicherung erfolgt im eingemounteten Zustand, die Partition ist alsoerst eingebunden worden. Danach kann wie gewohnt mit dump gesichertwerden. Damit die Sicherung nicht ungeschtzt geschrieben wird, wird sieper Pipe durch mcrypt verschlsselt.1 # cgdconfig cgd0 /dev/wd0e && mount /dev/cgd0d /home2 # dump -0au -f - /dev/cgd0d | mcrypt -flush > home0.ncListing 8.6: eine CGD-Partition verschlsselt dumpen8.7 symmetrische verschlsselung mit mcryptmcrypt ist als Ersatz und Nachfolger fr das alte bdes(1) gedacht unduntersttzt eine Vielzahl an symmetrischen Kryptoalgorithmen. Es ist rechtschnell und bietet sich als symmetrisches Verschlsselungsprogramm fr dieerstellten Backups an. Es ist in pkgsrc/security/mcrypt enthalten und lsstsich problemlos installieren.Listing 8.7 fragt nach einem Passwort und erzeugt damit die Datei 1.txt.nc,die standardmig mit Rijndael (AES) verschlsselt wird. mcrypt untersttzt838.8. Versionsverwaltung mit CVS1 $ ls -l2 total 203 -rw-r--r-- 1 stefan stefan 9143 Jan 16 11:55 1.txt4 $ mcrypt 1.txt5 Enter the passphrase (maximum of 512 characters)6 Please use a combination of upper and lower case7 letters and numbers.8 Enter passphrase:910 Enter passphrase:111213 File 1.txt was encrypted.14 $ ls -l15 total 4016 -rw-r--r-- 1 stefan stefan 9143 Jan 16 11:55 1.txt17 -rw------- 1 stefan stefan 9245 Jan 16 11:55 1.txt.nc18Listing 8.7: symmetrische Verschlsselung mit mcryptmehrere Algorithmen und Chiffremodi, diese lassen sich in der manpagenachlesen oder mit mcrypt list anzeigen.1 $ mdecrypt 1.txt.nc2 Enter passphrase:34 File 1.txt.nc was decrypted.5 $ ls -l6 total 407 -rw------- 1 stefan stefan 9143 Jan 16 11:55 1.txt8 -rw------- 1 stefan stefan 9253 Jan 16 11:55 1.txt.nc9 $Listing 8.8: Datei mit mcrypt entschlsseln8.8 versionsverwaltung mit cvsCVS (Concurrent Version System) ist eigentlich kein Backupprogramm, son-dern ein System aus verschiedenen Programmen, das entwickelt wurdeum Quellcodeprojekte fr mehrere Entwickler zu verwalten. Da CVS aberauch eine Versionierung der Dateien vornimmt, kann man es hervorragendverwenden um die verschiedenen Entwicklungsstadien einer Datei vorzuhal-ten. Prinzipiell kann man in CVS alle Arten von Quellcode (also plaintext)vorhalten, von Perl ber Java zu HTML.Entwickelt man nun ein greres Projekt, bspw. dieses Dokument, kannman ein neues CVS-Modul anlegen und den Quellcode dort einfgen. Vern-dert man die Quellen, kann man sie in das CVS Repository einfgen undbei Bedarf wieder auschecken. Man kann also bspw. den Quellcode vom19.04.2004 auschecken und mit dem vom 01.01.2005 vergleichen.CVS ist in NetBSD standardmig enthalten und kann sofort benutztwerden.848.9 dateisystemintegritt prfenmtree(8) ist ein Programm um die Eigenschaften einer Dateisystemhierarchiein eine einfache Textdatei zu schreiben. Es wird hauptschlich eingesetzt umbei der Installation von NetBSD-Sets deren Korrektheit zu berprfen, dabspw. ein defektes /bin/sh fatale Folgen htte.Mtree kann auch genutzt werden um die Integritt eines Backups zu testen,in dem man einen Fingerabdruck der zu sichernden Daten erstellt und mitder Sicherung vergleicht.1 # mtree -L -c -K sha1,rmd160,gname,uname,mode \2 -p / -X /etc/mtree.excl > /root/mtree.origListing 8.9: Fingerabdruck eines Systems mit mtree erstellenListing 8.9 erzeugt eine Liste mit den entsprechenden Dateieigenschaften,wobei die Pfade in /etc/mtree.excl ausgeschlossen werden. Die zu bear-beitenden Dateieigenschaften werden ber die Schlsselwrter sha1, rmd160,gname, uname, mode definiert, hier sind dies die beiden PrfsummenverfahrenSHA1 und RipeMD 160 sowie der Name der Gruppe und des Besitzers sowieder Dateizugriffsrechte im Oktalmodus. Weitere Schlsselwrter kann mander manpage entnehmen, sind aber meiner Meinung nach nicht notwendig.Ein Teil der erzeugten Liste ist exemplarisch in Listing 8.10 abgedruckt.Mit Listing 8.11 knnen Dateien verglichen werden, dazu gibt mtree einenBericht der Art 8.12 aus. Die Datei new1 ist neu, existiert also im alten Finger-abdruck nicht, die Datei removed.txt existiert zwar im Fingerabdruck, abernicht im System. 3.txt wurde verndert, sie beinhaltet nun 6489 Byte statt6460. Dadurch vernderten sich auch die Zugriffszeit und die Prfsummen.1 cat size=10550 time=1117454217.0 \2 rmd160=1665d6dc5bee4c14fd4f74a3c8c9197e9006d761 \3 sha1=428bff79c7a1c7c925a584ba5a983411a42befa74 chio size=13730 time=1117454217.0 \5 rmd160=dbff324c1b19d37e9281805c6deeb8b6479742a6 \6 sha1=37c78289531ec99489bc8b1aaeb60fc1b8a5fb8f7 chmod size=8594 time=1117454217.0 \8 rmd160=436ff626a61fecf9569abb89aebb8dac060096da \9 sha1=e390a28d3726aedd472838f8f55e67287970272b10 [...]Listing 8.10: Beispiel eines mtree-Reports1 mtree -L -p / -X /etc/mtree.excl -f /root/mtree.origListing 8.11: Dateisystem mit Fingerabdruck vergleichenAlles in allem ist mtree also ein vorzgliches Mittel um die Korrektheiteines Dateisystems zu prfen und zu vergleichen.8.10 prfsummen einzelner dateien erstellenUm einzelne Dateien zu vergleichen reicht ein einfaches Prfsummenverfah-ren wie sha1(1) aus.858.10. Prfsummen einzelner Dateien erstellen1 3.txt: size (6460, 6489)2 modification time (Wed Feb 9 18:48:17 2005,\3 Wed Feb 9 18:54:52 2005)4 rmd160 (0xf30de94ae188d9114a00118e80bbedf8e2c6c6ed, \5 0x6a5b3781799b09e2b8d8037e89fe03957ebca247)6 sha1 (0x4c499470dcaed01c2681eb0676ddac8cf3024d5a, \7 0xc04159927a4e9ca5f521161d2cc8daa019fca19a)8 extra: new19 missing: removed.txtListing 8.12: Ergebnisse eines Dateisystemvergleichs1 # dump -0 -f home.dump /home2 # sha1 home.dump >> SHA1.dump3 # bzip2 -9 home.dump4 # sha1 home.dump.bz2 >> SHA1.dump5 # mount /dev/sd0a /mnt/zip6 # cp home.dump.bz2 SHA1.dump /mnt/zip7 # sha1 /mnt/zip/home.dump.bz2Listing 8.13: Dateien mit SHA1 vergleichen86Teil VIDER TEST9DER TESTNobody gonna take my headI got speed inside my brain(Deep Purple)Elizabeth D. Zwicky hat in ihren Artikeln (1991; 2003) zur Zuverlssigkeitvon Datensicherungsprogrammen verschiedene Pakete auf Unix-Systemengetestegetestett. Dazu erstellte sie ein Perlskript um ein Testverzeichnis mitverschiedenen Problemedateien zu generieren. Ich habe dieses Perlskript1verwendet um ein Testverzeichnis (Quelle) zu erstellen und es mit verschie-denen Programmen zur Datensicherung getestet.9.1 problemfelderZwicky bechreibt die Tests und deren Hintergrnde ausfhrlich in ihrem o.g.Artikel, ich gebe hier lediglich eine kurze Zusammenfassung wieder.9.1.1 DatumsproblemeEine Datei hat eine mtime vor 1970, eine weitere in der Zukunft.9.1.2 DateigrenEine leere Datei, ein leeres Verzeichnis und eine Datei mit 4098 MB wurdeerstellt.9.1.3 Verschiedene DateitypenEs wurden drei verschiedene Dateitypen erzeugt: block, character undnamed pipe (auch als FIFO bezeichnet).9.1.4 ZeichenstzeEs wurden Verzeichnisse, Dateinamen, Hardlinks und Symlinks angelegt, indem einfach die 7-Bit-ASCII-Tabelle und UTF8 von 128 255 durchiteriertwurde.Beim Erzeugen der Quelle gab es hierbei sechs Fehler, da Dateien bzw.Pfade mit . oder / als Namen nicht erzeugt werden knnen. Trotzdemknnen andere Betriebssysteme derartige Dateinamen mit NFS, AFS oderSamba erzeugen.9.1.5 Lcher in DateienLcher in Dateien werden erzeugt, wenn Blcke referenziert werden, dieDaten enthalten, die Referenz aber NULL ist.Erzeugt werden sie im Allgemeinen von Coredumps oder bspw. in Daten-bankpools oder explizit mit seek(2), in dem man n Blcke vorspult.1 http://greatcircle.com/~zwicky/torture.tar in der Version vom 04.11.2005http://greatcircle.com/~zwicky/torture.tar9.1. Problemfelder9.1.6 lange PfadnamenDie Lnge eines Dateinamens oder einzelnen Verzeichnisses (MAXNAME-LEN) ist auf 255 Zeichen, und der gesamte Pfad (MAXPATHLEN) auf 1023(MAXPATHLEN1) Zeichen begrenzt.bersteigt ein Element des Pfadnamens MAXNAMELEN oder der gesamtePfad MAXPATHLEN wird mit Fehler 63 ENAMETOOLONG File name toolong abgebrochen. Nheres dazu findet sich in errno(2).Einige Sicherungsprogramme haben eingebaute maximale Pfadlngen, paxverweigerte sich bspw. ab 100 Zeichen.Leider ist es mglich berlange absolute Pfadnamen zu erzeugen, dazwar der relative, nicht aber der absolute Pfad beim erzeugen einer Dateiberprft wird. Das heit, ein Benutzer kann eine Datei oder ein Verzeichnismit 255 Zeichen langem Namen problemlos erzeugen und dies beliebig oftaneinanderreihen, wenn er relative Pfade verwendet.Ein Beispiel zur Illustration, ([1-7]NAME, [1-2]DATEI sei je genau 250Zeichen lang):1# cd /2# mkdir 1NAME && cd 1NAME3# mkdir 2NAME && cd 2NAME4# mkdir 3NAME && cd 3NAME5# mkdir 4NAME && cd 4NAME6# mkdir 5NAME && cd 5NAME9# date > 1DATEI10# cp 1DATEI /2DATEI11# cd /12# cp /1NAME/2NAME/3NAME/4NAME/5NAME/1DATEI /3DATEIcp: 1NAME/2NAME/3NAME/4NAME/5NAME/1DATEI File name too longJeder Dateiname bzw. jede Pfadkomponente ist 250 Zeichen lang, was aucherlaubt ist. Wenn die Datei aber wie in Zeile 12 absolut referenziert wird,ergibt sich ein Pfadname von 6 250+ 6 = 1506 Zeichen, was vom Kernelnicht mehr verarbeitet wird. Ein mgliche Gegenmanahme wre das begren-zen der maximalen Pfadlnge auf MAXPATHLENMAXNAMELEN 1 =1024 255 1 = 768 Zeichen.9.1.7 ZugriffsrechteEinige Programme haben Probleme mit komischen Zugriffsrechten, wennbspw. ein Verzeichnis nicht gelesen oder beschrieben werden darf aber troz-dem schon Dateien beinhaltet. Die korrekte Vorgehensweise zur Sicherung isthierbei einfach: Verzeichnis mit rwxrwxrwx erstellen, Dateien ins Verzeichnisrcksichern, Zugriffsrechte setzen. tar ist hierbei bspw. grandios mit 100%Fehlerquote gescheitert.9.1.8 Testgestellung und TestdurchfhrungNetBSD 3.0_BETA vom 04.11.2005 mit GENERICPentium III 500MHz, 2*128MB SDRAM 100MHz20GB IDE Systemplatte40GB IDE Festplatte, eine Partition mit FFSv1Der Rechner wurde Acht Stunden mit prime95 erfolgreich einem Be-lastungstest unterzogen. Hierbei werden groe Primzahlen berechnet undverglichen, so das bei einem Hardwaredefekt (insbesondere RAM/CPU)sehr schnell Fehler auftreten. Zustzlich wurden insegesamt fnf je 10GBgroe Dateien mit OpenSSL verschlsselt, entschlsselt und verglichen umHardwarefehler auszuschlieen.Auf dem Testsystem wurde mit perl maketestdir.pl das Quellverzeich-nis erstellt. Das Quellverzeichnis wurde vermessen (Gre mit du und Anzahl90http://www.mersenne.org1 wd1 at atabus1 drive 0: 2 wd1: drive supports 16-sector PIO transfers, LBA48 addressing3 wd1: 38204 MB, 77622 cyl, 16 head, 63 sec, 512 bytes/sect x 78242976 sectors4 wd1: 32-bit data port5 wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)6 wd1(piixide0:1:0): using PIO mode 4, Ultra-DMA mode 2 (Ultra/33) (using DMA)Listing 9.1: Testgestellung fr den Belastungstestder Dateien mit ls -laR | wc -l) und mit mtree wurde ein Fingerabdruckder Quellen erstellt, um die Korrektheit des Dateiinhalts zu prfen.Mit jedem Sicherungsprogramm wurde eine Sicherung durchgefhrt unddie gesicherte Datei wieder zurckgespielt. Dabei wurden mit script alleAusgaben2 zur Auswertung mitgeschnitten und mit time die Zeit genommen.Anschlieend wurde die Quelle mit dem Ziel verglichen, zuerst wurde mitmtree die Korrektheit der Daten verifiziert und danach die Quelle wiedergren- und zahlenmig vermessen.Jedes Programm wurde dreimal getestet, es konnten aber keine Unterschie-de in der Fehlerquote festgestellt werden.9.2 testergebnisseIn den folgenden Tabellen sind die Ergebnisse des Vergleichs von Quelle undZiel wiedergegeben. Zu jedem getesteten Programm wurde die Anzahl derDateien und deren Gre je Testverzeichnis aufgelistet. Zustzlich wird dieDifferenz zur Quelle und die Erfolgsquote in Prozent angegeben.2 Teilweise mehr als 80MB919.2.TestergebnisseTabelle 15.: Auswertung von star und BaculaOriginal star BaculaVerzeichnisse Gre Anzahl Gre Anzahl Gre Anzahl dates 6 5 6 0 5 0 6 0 5 0filesize 4195364 11 4195364 0 11 0 4195364 0 11 0filetypes 2 6 2 0 6 0 2 0 6 0funnydirnames 2036 3556 2036 0 3556 0 2036 0 3556 0funnyfilenames 1022 512 1022 0 512 0 1022 0 512 0funnyhard 1022 510 1022 0 510 0 1022 0 510 0funnysym 14 1013 14 0 1013 0 14 0 1013 0holes 196 7 10 -186 7 0 X X X Xlongfilenames 1098 510 1098 0 510 0 1098 0 510 0longhardlinks 2 3 2 0 3 0 2 0 3 0longpathnames 280550 131071 93124 -187426 46639 -84432 280478 -72 131039 -32longsymlinks 259936 131827 259936 0 131827 0 259936 0 131827 0overmaxpathlen 22 33 9 -13 4 -29 8 -14 21 -12permissions 24722 32819 24722 0 32819 0 24722 0 32819 0plainfilenames 514 258 514 0 258 0 514 0 258 0Summe 4766506 302141 4578881 -187625 217680 -84461 4766224 -282 302090 -51Quote 100% 100% 96,06% 72,05% 99,99% 99,98%Legende:Gre = Gre der Datei / des Verzeichnisbaumes in KB, gemessen mit du -sk;Anzahl = Anzahl aller Dateien / Verzeichnisse, gemessen mit ls -laR | wc -l; = Differenz zwischen Quelle und Sicherung Es wurden zwar alle Dateien wiederhergestellt, jedoch mit vllig falschen Gren. Daher unbrauchbar. In den Standardeinstellungen konnte Bacula die Dateien mit Lchern nicht sichern, da der Sicherungspool anschwoll bis das Dateisystem voll war. Daher habe ich den Test ohne holes wiederholt.929.3 auswertung9.3.1 dumpDump ist der unangefochtene Gewinner des Vergleichs. Es konnte lediglich23 Dateien (ca. 38KB) nicht sichern, welche allesamt zu lange Dateinamenhatten.Das entspricht einer Sicherungsquote von ber 99,99%. Problematischwar hier longpathnames und overmaxpathlen, also berlange Pfade. Dumpverwendet absolute Pfadnamen von / aus, kann also betriessystembedingtkeinen Pfad ber MAXPATHLEN ansprechen.Die Datensicherung dauerte 13 Minuten, die Rcksicherung 32 Minuten,wobei hier als Option -y angegeben wurde, um trotz der Fehlermeldung zuden berlangen Pfadnamen die Rcksicherung fortzusetzen.9.4 fazitDas Sicherungswerkzeug fr den Einzelrechner und kleinere Netzwerke istDump. Es ist robust, zuverlssig, jahrelang verbessert worden und speziellfr die Datensicherung ausgelegt.Hat man keine Root-Rechte und kann Dump nicht einsetzen, bietet sichStar an. Es ist wesentlich mchtiger und stabiler als Tar/Cpio/Pax.Die beiden Netzwerksysteme Amanda und Bacula hatten im Allgemeinenkeine groen Probleme mit dem Test. Amanda ist mit Dump robuster alsmit Gtar, daher sollte auch hier, sofern es die Bandgre erlaubt, Dumpverwendet werden.Abschlieend lsst sich zum Test noch anmerken, da die Problemflle diehier betrachtet wurden, zwar existieren, im Allgemeinen in der freien Wild-bahn aber eher selten auftreten. Trotzdem sollte man sich nie in Sicherheitwiegen und immer Verfikationsmethoden einsetzen.939.4. Fazit94Teil VIIANHANGAEINEN EINZELNEN RECHNER SICHERNDie meisten Heimrechner verfgen ber einen CD- oder DVD-Brenner, sodas man am einfachsten Dumps erstellt, die sich anschlieend brennen lassen.Das folgende Shellskript verwende ich seit Jahren auf meinem Produktivrech-ner.1 #!/bin/sh2 ## backup.sh - a shellskript to prepare a dump-driven backup3 ## written by Stefan Schumacher . 0xb3fbae334 ## Id: backup.sh,v 1.38 2006/02/14 11:32:26 stefan Exp56 ## determines the dump level by the day of week (Mon=0,Tue-Fri=1,Sat/Sun=2)7 ## cleans up PostgreSQL8 ## calculates the size of dump files to be generated (so they can fit on a DVD)9 ## creates a tarball with system config files in $SRC10 ## generates a mtree fingerprint of the data11 ## creates a snapshot12 ## dumps the snapshot, emails me if an error occured13 ## gzip's the dumped files14 ## creates ISO-images and copies them to a dircetory exported with samba1516 ## get the date to generate filenames17 DATE=`date +%y%m%d-%a`18 DOW=`date +%a`1920 ## dir that should be dumped, target to dump to21 SRC=/home/22 TGT=/usr/home/backups/23 PGUSER=pgsql2425 ## Size of the media to generate26 ## 715000=>698MB, 2042880 => 1995MB, 4398000 => 4294MB27 MEDSIZE=4398000 # for a DVDListing A.1: Shellskript fr Dump (1/3)9.4. Fazit1 ## Level 0 at Monday, Level 1 Tu-Fr, 2 Else2 if [ $DOW = "Mon" ]3 then LEVEL=04 elif [ $DOW = "Sun" ] || [ $DOW = "Sat" ]5 then LEVEL=26 else7 then LEVEL=18 fi9 #############################################10 ## PostgreSQL Maintenance and Backup11 ## vacuum all databases to collect garbage and update analyzer12 /usr/pkg/bin/vacuumdb -U$PGUSER -f -z -a13 /usr/pkg/bin/pg_dumpall -U$PGUSER | bzip2 -9 > \14 /home/pgsql/pg_`date +%y%m%d-%a`.bz21516 #############################################17 ## Calc size of source in KB, respect the NODUMP flag (-n)18 MEDIA=`du -snk $SRC | awk '{print $1}'`1920 ## compute size of the media, without modulo21 MEDIA=$(($MEDIA/$MEDSIZE))22 ## add 2 to the number of media as security premium23 MEDIA=$(($MEDIA+2))2425 ## generate filenames for the media26 FILENAME=$TGT$DATE-L$LEVEL-F027 i=028 while [ $i -lt $MEDIA ]29 do30 i=`expr $i + 1`31 # generate next filename32 FILES=${TGT}${DATE}-L${LEVEL}-F$i33 # concat filenames to one string34 FILENAME=${FILENAME},${FILES}35 done36 ## remove kommas from filenames for BZIP237 GZFILENAME=`echo $FILENAME | sed 's/,/ /g'`3839 #############################################40 ## tar up config files to be backuped within the dump41 /bin/tar cfj $SOURCE/back.tbz2 /etc/ /root/ /usr/pkg/etc/ \42 /var/cron /var/log /var/backupsListing A.2: Shellskript fr Dump (2/3)981 ## Generate filesystem fingerprint with mtree2 /usr/sbin/mtree -c -K mode,gname,uname,mode -X mtree-exclude.nodump \3 -p $SRC | gzip > logs/mtree.$DATE.gz45 ############################################6 ## create a file system snapshot7 /usr/sbin/fssconfig -x fss0 /home /89 ## dump /home, the messages are redirected to a file10 /sbin/dump -$LEVEL -u -h0 -b 1 -B $MEDSIZE -L '8677.'$LEVEL'.'$DATE \11 -f $FILENAME /dev/fss0 2> $TGT/logs/dumplog.$DATE1213 ## email the admin about dump problems14 [ $? = 1 ] && cat logs/dumplog.$DATE | mail -s 'DUMP Fehlgeschlagen' stefan ;1516 /usr/sbin/fssconfig -u fss017 ## create SHA1 checksum18 for i in $FILENAME19 do20 sha1 $i >> logs/sha1list21 done2223 ## compress dumps and generate SHA1 cksum24 /usr/bin/gzip -f $GZFILENAME2526 ## create SHA1 checksum27 for i in $GZFILENAME28 do29 sha1 $i.gz >> logs/sha1list30 done3132 ## create an ISO image to be burnt33 ## iterate all created GZ files34 for i in $GZFILENAME35 do36 /usr/pkg/bin/mkisofs -o $i.iso -rTJ $i.gz /usr/home/backups/logs37 done3839 ## notify syslog40 /usr/bin/logger 'backup.sh finished'Listing A.3: Shellskript fr Dump (3/3)999.4. Fazit100BPRFLISTE ZUR STRATEGIEOrt, Datum: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wer ist verantwortlich?Name: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Email, Raum, Telefon: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Name: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Email, Raum, Telefon: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wie wird gesichert?tglich / wchentlich / monatlichKomplett / Inkrementell / Differentiell Was wird gesichert?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Welche Medien und Gerte werden verwendet?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wo werden die Medien gelagert?im Hause: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .extern: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wie lange werden die Medien gelagert?Rotationszyklus im Hause: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Rotationszyklus extern: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wann wird gesichert? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wie/Wann wird die Integritt der Sicherung geprft?Prfsummenverfahren: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vor/nach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Testrcksicherung (am/um/von): . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9.4. Fazit Welche Backupstrategie? (Wann welche Level?) taegl. Level: Montag: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dienstag: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mittwoch: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Donnerstag: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Freitag: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sonnabend: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sonntag: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inventur Welche Zyklen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wann fllig? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wer prft? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mediendatenbank Onlineadresse: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sicherungskopie der DB: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Offline-Version: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wo ist die Dokumentation zur Backupstrategie?online: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .offline: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102LITERATURVERZEICHNISNur wenige wissen, wie viel man wissen muss,um zu wissen, wie wenig man wei.(Werner Heisenberg)Die Literaturangaben sind alphabetisch nach den Namen der Autoren sortiert.Bei mehreren Autoren wird nach dem ersten Autor sortiert.[Barth 2004] Barth, Wolfgang: Netzwerkweite Datensicherung mit Aman-da auf Festplatte statt auf Band. (2004). URL http://linux.swobspace.net/misc/linuxtag/2004/index.html. Zugriffsdatum: Okt. 2006[Dowdeswell 2003] Dowdeswell, Roland C.: The Cryptographic DiskDriver. (2003). URL http://www.imrryr.org/~elric/cgd/cgd.pdf[leen Frisch 2002] Frisch leen: Die Top Fnf Open Source-Pakete frSystemadministratoren. (2002). URL http://www.oreilly.de/artikel/amanda_1.html. Zugriffsdatum: Okt. 2006[Group 2006] Group, The PostgreSQL Global D.: PostgreSQL 8.2.0 Docu-mentation. The PostgreSQL Global Development Group, 2006[Gutmann 1996] Gutmann, Peter: Secure Deletion of Data from Magneticand Solid-State Memory. In: USENIX Security Symposium Proceedings. SanJose, California : USENIX, July 1996. URL http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html. Zugriffsdatum: Jan. 2007[Lupi und The NetBSD Foundation 2006] Lupi, Federico ; The NetBSDFoundation: The NetBSD Guide. 2006. http://netbsd.org/guide/en/[Preston 1999] Preston, W. C.: UNIX Backup and Recovery. 1. Auflage.Sebastopol : OReilly Media, 1999. 734 S. ISBN 978-1565926424[Reinke 2004] Reinke, Dr. T.: Sicheres Lschen ma-gnetischer Datentrger. (2004). URL http://fhh.hamburg.de/stadt/Aktuell/weitere-einrichtungen/datenschutzbeauftragter/informationsmaterial/informationstechnik/sicheres-loeschen-pdf,property=source.pdf. Zugriffsdatum: Jan. 2007[Schumacher 2004] Schumacher, Stefan: Einfhrung in kryptographi-sche Methoden. 2004. URL http://www.cryptomancer.de/21c3/21c3-kryptograhie-paper.pdf. Zugriffsdatum: 06.01.2005[Schumacher 2006a] Schumacher, Stefan: Sicherung verteilter Systememit Bacula. 4 (2006), S. 14 20. URL http://kaishakunin.com/publ/guug-uptimes-bacula.pdf. Zugriffsdatum: 2009-11-07. ISSN 1860-7683[Schumacher 2006b] Schumacher, Stefan: Verschlsselte Dateisystemefr NetBSD. 4 (2006), S. 25 31. URL http://kaishakunin.com/publ/guug-uptimes-cgd_cfs.pdf. Zugriffsdatum: 2009-11-07. ISSN 1860-7683[Schumacher 2007a] Schumacher, Stefan: Daten sicher l-schen. 1 (2007), S. 7 16. URL http://kaishakunin.com/publ/guug-uptimes-loeschen.pdf. Zugriffsdatum: 2009-11-07. ISSN1860-7683http://linux.swobspace.net/misc/linuxtag/2004/index.htmlhttp://linux.swobspace.net/misc/linuxtag/2004/index.htmlhttp://www.imrryr.org/~elric/cgd/cgd.pdfhttp://www.oreilly.de/artikel/amanda_1.htmlhttp://www.oreilly.de/artikel/amanda_1.htmlhttp://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.htmlhttp://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.htmlhttp://netbsd.org/guide/en/http://fhh.hamburg.de/stadt/Aktuell/weitere-einrichtungen/datenschutzbeauftragter/informationsmaterial/informationstechnik/sicheres-loeschen-pdf,property=source.pdfhttp://fhh.hamburg.de/stadt/Aktuell/weitere-einrichtungen/datenschutzbeauftragter/informationsmaterial/informationstechnik/sicheres-loeschen-pdf,property=source.pdfhttp://fhh.hamburg.de/stadt/Aktuell/weitere-einrichtungen/datenschutzbeauftragter/informationsmaterial/informationstechnik/sicheres-loeschen-pdf,property=source.pdfhttp://fhh.hamburg.de/stadt/Aktuell/weitere-einrichtungen/datenschutzbeauftragter/informationsmaterial/informationstechnik/sicheres-loeschen-pdf,property=source.pdfhttp://www.cryptomancer.de/21c3/21c3-kryptograhie-paper.pdfhttp://www.cryptomancer.de/21c3/21c3-kryptograhie-paper.pdfhttp://kaishakunin.com/publ/guug-uptimes-bacula.pdfhttp://kaishakunin.com/publ/guug-uptimes-bacula.pdfhttp://kaishakunin.com/publ/guug-uptimes-cgd_cfs.pdfhttp://kaishakunin.com/publ/guug-uptimes-cgd_cfs.pdfhttp://kaishakunin.com/publ/guug-uptimes-loeschen.pdfhttp://kaishakunin.com/publ/guug-uptimes-loeschen.pdfLiteraturverzeichnis[Schumacher 2007b] Schumacher, Stefan: PostgreSQLs Datenbestndesichern. 2 (2007), Jun, S. 4 7. URL http://kaishakunin.com/publ/guug-uptimes-postgresql.pdf. Zugriffsdatum: 2009-11-07. ISSN 1860-7683[Sibbald 2006a] Sibbald, Kern: Bacula Developerss Manual. Bacula, 2006. URL http://www.bacula.org/bacula.pdf. Zugriffsdatum: Okt. 2006. Nur als PDF verfgbar[Sibbald 2006b] Sibbald, Kern: Bacula Users Manual. Bacula, 2006. URLhttp://www.bacula.org/rel-bacula.pdf. Zugriffsdatum: Okt. 2006. Nur als PDF verfgbar[Sibbald 2006c] Sibbald, Kern: Supported Autochangers. (2006). URLhttp://www.bacula.org/dev-manual/Supported_Autochangers.html. Zugriffsdatum: Okt. 2006[Sibbald 2006d] Sibbald, Kern: Supported Tape Drives. (2006). URL http://www.bacula.org/dev-manual/Supported_Tape_Drives.html. Zugriffsdatum: Okt. 2006[Vernooij und Weichinger ] Vernooij, Jelmer R. ; Weichinger, Stefan G.:Samba-HOWTO-Sammlung. URL http://gertranssmb3.berlios.de/output/Backup.html[Weichinger und Amanda Core Team 2006] Weichinger, Stefan G. ;Amanda Core Team: The Official AMANDA Documentation. (2006). URL http://www.amanda.org/docs/AMANDA-HOWTO-Collection.pdf. Zugriffsdatum: Okt. 2006[Wennmacher 1999] Wennmacher, Alexandre: File Flags Proposal.(1999). URL http://mail-index.netbsd.org/tech-security/1999/02/01/0000.html. Zugriffsdatum: Okt. 2006. Archiv einer Mailinglisten-Diskussion[Zwicky 1991] Zwicky, Elizabeth D.: Torture-testing Backup and ArchivePrograms: Things You Ought to Know But Probably Would Rather Not.In: Proceedings of the 5th Large Installation Systems Administration Conference.San Jose, California : USENIX, October 1991, S. 1 13. URL http://www.usenix.org/events/lisa03/tech/fullpapers/zwicky/zwicky.pdf[Zwicky 2003] Zwicky, Elizabeth D.: Further Torture: More Testing ofBackup and Archive Programs. In: Proceedings of the 17th Large InstallationSystems Administration Conference. San Jose, California : USENIX, Octo-ber 2003, S. 1 13. URL http://www.usenix.org/events/lisa03/tech/full_papers/zwicky/zwicky.pdf104http://kaishakunin.com/publ/guug-uptimes-postgresql.pdfhttp://kaishakunin.com/publ/guug-uptimes-postgresql.pdfhttp://www.bacula.org/bacula.pdfhttp://www.bacula.org/rel-bacula.pdfhttp://www.bacula.org/dev-manual/Supported_Autochangers.htmlhttp://www.bacula.org/dev-manual/Supported_Tape_Drives.htmlhttp://www.bacula.org/dev-manual/Supported_Tape_Drives.htmlhttp://gertranssmb3.berlios.de/output/Backup.htmlhttp://gertranssmb3.berlios.de/output/Backup.htmlhttp://www.amanda.org/docs/AMANDA-HOWTO-Collection.pdfhttp://mail-index.netbsd.org/tech-security/1999/02/01/0000.htmlhttp://mail-index.netbsd.org/tech-security/1999/02/01/0000.htmlhttp://www.usenix.org/events/lisa03/tech/fullpapers/zwicky/zwicky.pdfhttp://www.usenix.org/events/lisa03/tech/fullpapers/zwicky/zwicky.pdfhttp://www.usenix.org/events/lisa03/tech/full_papers/zwicky/zwicky.pdfhttp://www.usenix.org/events/lisa03/tech/full_papers/zwicky/zwicky.pdfINDEX/etc/daily, 41/etc/security, 41/var/backups/etc, 41Ablagesystematische, 22Ablaufsteuerung, 40ACPI, 50Administrationdokumentieren, 23vereinfachen, 23Administratorenfehler, 20afio, 49Amanda, 57Clients, 59Einsatz, 61Konfiguration, 58Programme, 59Rcksicherung, 61Server, 58Sicherungsstrategie, 57Sisklist, 59Spoolplatte, 59Statistik, 57Anacron, 39Anwenderdaten, 22Anwendungsdaten, 22Archivierung, 19Archivierungsdauermaximale, 25minimale, 19at, 40Ausfallzeiten minimieren, 27AutomatisierungProgramme, 39Zeitgesteuert, 39Backup, 19differentielles, 29inkrementelles, 29Backupsinkrementelle, 44Bacula, 62Client, 63Konfiguration, 63Rcksicherung, 68rc.d, 63Sicherungsart, 63Verschlsselung, 63bacula, 65baculadir, 65baculafd, 65baculasd, 65Basissystemsichern, 41batch, 40Batchjob, 23bconsole, 65Bedrohungen, 20Bedrohungsszenarien, 19, 20BenutzerEinweisung, 22Benutzerfehler, 20Betriebssystemsichern, 52, 53Binaries, 22buffer, 81Bzip2Verifikation, 24cfs, 83cgd, 83cpio, 49cron, 39Cronjob, 23crontab, siehe cronCryptographic Devicedriver, 83Cryptographic Filesystem, 83CVS, 84cwrsync, 51Dateizerlegen, 82zusammensetzen, 82Dateienfinden, 82suchen, 82DateisystemAbbild, 43verschlsselndes, 31Dateisystemeverifizieren, 24Dateisystemintegritt, 85Dateisystemkorruption, 20Datenbewerten, 21nicht wiederherstellbare, 21Verifikation, 24wichtige, 21Datenbanknachbereiten, 74vorbereiten, 74Datenrettung, 28Datenrettungsunternehmen, 28Dauer der Rcksicherung, 33dd, 52diff(1), 49Disaster Recovery, 19Dokumentation, 19, 23, 26dump, 29, 44Dateien ausschlieen, 44Details, 46IndexFileflag respektieren, 44Header, 48Inkonsistenzen, 48Level, 29LogInhalt, 46pass, 47Testauswertung, 93dump_lfs, 44exustar, 48Fehlertypen, 20Feiertage, 25Festplattedefekt, 20spiegeln, 53Fileflag, 44Filesystem Snapshots, 43find(1), 82fss, 43g4u, 52GAU, 24Gerteschreiben auf, 52Ghost for Unix, 52GnuPG, 31grep, 82GzipVerifikation, 24HanoiTrme, 30Hardwarekomprimierung, 31Homeverzeichnis, 21Image, 52InventarDatenbank, 20Inventarisierungssystem, 34Attribute, 34Inventur, 19, 20Komplettbackup, 29Kompressionsrate, 31Komprimierung, 30, 31Konfigurationsdateien, 21KopieEins-zu-Eins, 52Lschensicher, 31Laufgeschwindigkeit, 81Live-CD, 25Logdateien, 24Manahmensoziale, 22mcrypt, 31, 83Medienwiederherstellen, 28Medium, 32Dauer der Rcksicherung, 33Geschwindigkeit, 32Integritt, 33Kapazitt, 33Kosten, 33Lagerung, 34Organisation, 34Spezifikation, 34vergleich, 34Verlsslichkeit, 32mklivecd, 25mt, 81mtree, 49, 85Naturkatastrophen, 21NODUMP, 44Notfallplan, 19OpenSSL, 31pax, 49pg_dump, 75pg_dumpall, 75pg_restore, 75Pgpool, 76umschalten, 77Point-in-Time-Recovery, 73PostgreSQLBackup-Checkpoint, 74Rcksicherung, 75Replikation, 75Sicherung, 73Cluster, 73Table-Spaces, 73WALzurckspielen, 74Prfsumme, 24, 85Puffer, 81Quellcode, 22RcksicherungSituationen, 27Test, 26Ragnark, 24RAIT, 57RCS, 41rdiff-backup, 51Versionierung, 52Replikation, 27Asynchrone, 76Synchrone, 76Replikationsmechanismen, 28Replikationsserver, 76restore, 44-x, 46bestimmte Dateien, 46Dateien finden, 46Lauf fortsetzen, 46106IndexRsyncPrfsumme, 51rsync, 50MS Windows, 51schtasks, 51SicherungOrganisation, 22physikalische, 34Sicherungskreise, 25SicherungssoftwareAnforderungen, 20Sicherungsstrategie, 19Test, 27SicherungssystemEinweisung, 26SicherungssystemeIndex, 22Sicherungsvarianten, 29Snapshotkonfigurieren, 43Snapshots, 43Spiegelung, 19, 27split(1), 82SSHTunnel, 50star, 48Header, 48StrategieBeispiel, 29Differentiell, 30Inkrementell, 30Komplett, 30Prfliste, 34Streamersteuern, 81symmetrische Verschlsselung, 83Synchronisation, 50Archivierung, 51Problem, 51SystemInformation, 42Systemdaten, 21Systemeeingesetzten, 20hochverfgbare, 27homogene, 23Systemfehler, 20Systempfade, 22Systemverzeichnisse, 42Trme von Hanoi, 30tar, 48team, 81TestauswertungFazit, 93Testen, 19Testlufe, 25, 26Testsysteme, 25Time to Data, siehe Dauer der Rck-sicherungToleranzen, 23TransaktionenProtokolle, 74Verschlsselung, 30symmetrische, 83Versionsverwaltung, 84Verzeichnissesynchronisieren, 50Weltenbrand, 24WindowsMS, 51Write Ahead Log, 74xargs, 82Zerlegen/Zusammensetzen, 82107InhaltsverzeichnisQuellcode- und Befehlsverzeichnis1 Vorwort1.1 Danksagung1.2 Vortrge1.3 Warnung1.4 UrheberrechtshinweisStrategie und Organisation2 Strategie und Organisation2.1 Definitionen2.2 Vorbereitung der Strategie2.3 Inventur2.4 Bedrohungsszenarien analysieren2.5 Wichtige Daten finden und organisieren2.6 Sicherung der Sicherungssysteme2.7 Organisation der Sicherung2.7.1 Einweisung der Benutzer2.7.2 Cronjob vs. Batchjob2.7.3 Homogene Systeme2.7.4 Dokumentation der Adminstration2.7.5 Shellskripte statt Handarbeit2.7.6 Logdateien erstellen und auswerten2.7.7 Verifikation der Daten2.7.8 Den GAU erwarten2.7.9 Alles sichern2.7.10 Testsysteme und -lufe2.7.11 Verschiedene Sicherungskreise2.7.12 Maximale Archivierungsdauer2.7.13 Wochenenden und Feiertage beachten2.8 Dokumentation2.9 Testen, Testen, Testen2.10 Verminderung von Ausfllen und Ausfallzeiten2.11 Datenrettung3 Sicherungsvarianten3.1 Komplettbackup3.2 Differentielles Backup3.3 Inkrementelles Backup3.4 Dump-Level3.5 Beispielstrategie3.6 Komprimierung und Verschlsselung3.7 Medien3.7.1 Organisation und Lagerung der Medien3.8 Prfliste zur StrategieSicherung einzelner Systeme4 Programme automatisieren4.1 Zeitgesteuert4.2 Ablaufgesteuert5 Sicherung einzelner Systeme5.1 Tgliche Sicherungsmechanismen im Basissystem5.2 Das Basissystem sichern5.3 Filesystem-Snapshots5.3.1 Praktischer Einsatz5.3.2 Sicherung eines Snapshots5.4 dump(8)/dump_lfs(8) und restore(8)5.4.1 restore5.4.2 Dump im Detail5.5 tar(1)5.6 star5.7 cpio(1)5.8 afio(1)5.9 pax(1)5.10 Verzeichnisse synchronisieren mit rsync(1)5.10.1 MS Windows als Client5.11 rdiff-backup5.12 dd(1)5.13 Ghost for Unix (g4u)Sicherung verteilter Systeme6 Sicherung verteilter Systeme in Netzwerken6.1 Amanda6.1.1 Einrichtung des Servers6.1.2 Einrichtung der Clients6.1.3 Programme im Amanda-Paket6.1.4 Praktischer Einsatz6.2 Bacula6.2.1 Installation6.2.2 Konfiguration6.2.3 RcksicherungPostgreSQL7 Sicherung eines PostgreSQL-Servers7.1 Den Datenbankcluster sichern7.2 Point-in-Time-Recovery7.3 pg_dump, pg_dumpall und pg_restore7.4 Replikation7.4.1 Synchrone Replikation mit PgpoolSonstige Programme8 Sonstige Programme8.1 Magnetbnder ansteuern mit mt(1)8.2 Datenstrme puffern8.3 Dateien mit split(1) zerlegen8.4 Dateien mit find(1) finden8.5 Das kryptographische Dateisystem CFS8.6 Das kryptographische Pseudogert CGD8.7 symmetrische Verschlsselung mit mcrypt8.8 Versionsverwaltung mit CVS8.9 Dateisystemintegritt prfen8.10 Prfsummen einzelner Dateien erstellenDer Test9 Der Test9.1 Problemfelder9.1.1 Datumsprobleme9.1.2 Dateigren9.1.3 Verschiedene Dateitypen9.1.4 Zeichenstze9.1.5 Lcher in Dateien9.1.6 lange Pfadnamen9.1.7 Zugriffsrechte9.1.8 Testgestellung und Testdurchfhrung9.2 Testergebnisse9.3 Auswertung9.3.1 dump9.4 FazitAnhangA Einen einzelnen Rechner sichernB Prfliste zur StrategieLiteraturverzeichnisIndex

Recommended

View more >