ARCHIV- und BACKUP SYSTEM

Transkript

1 ARCHIV- und BACKUP SYSTEM des Leibniz-Rechenzentrums Dr. Bernd Reiner Datenhaltungsdienste am LRZ (1) Datensicherung (Backup) Zusätzliche Zweitkopie Kurzfristige Aufbewahrung Wieso Backup? Fehler in der Hard- oder Software menschliches Versagen sonstige Katastrophen 2 1

2 Datenhaltungsdienste am LRZ (2) Archive (Archivierung) sichere Aufbewahrung günstige Speichermedien mittelfristige Lagerung großer, bzw. sehr großer Datenmengen z.b. E/A-Daten der Programme an den Supercomputern, Video-Daten, 3D-Simulationen Langzeitarchivierung großer Datenmengen z.b. Datenbestände von Bibliotheken Breitengrad Zeit Längengrad 3 Sind die Daten wirklich sicher? Argon-Löschanlage Feuer wird erstickt Kein Wasserschaden Modernste Klimatechnik optimierte Temperatur & Luftfeuchtigkeit 4 2

3 Sind die Daten wirklich sicher? Zweitkopie von Archivdaten wird in einem geographisch entfernten Rechenzentrum gespeichert! 5 Prinzip der verteilten Datensicherung Disk Cache Network Server Clients Administrator Tape Library 6 3

4 IBM Tivoli Storage Manager Der Allrounder 7 IBM Tivoli Storage Manager Der Allrounder TSM-Server/Client Architektur für heterogene Plattformen/Protokolle TSM verwendet automatisierter Bandlaufsysteme TSM-Server: Verwaltet alle gespeicherten Daten, Rechner (nodes), Admins, Verwaltung der Medien Start der automatischen Sicherung Automatisches Laden/Entladen der Magnetbänder Automatisches Recycling der Magnetbänder (bei Fragmentierung) usw. 8 4

5 Die Daten-Lieferanten SGI Interim System(Altix) S11-S56 S56 Linux-Cluster SGI HLRB2 (Altix( Altix) MWN SERVER 9 Betriebssysteme der Clients 10 5

6 Verfahren beim Backup Full Backup Alles wird gesichert Differential Backup Sichert Änderungen seit letztem Full Backup Incremental Backup Sichert Änderungen seit letztem Backup Partial Backup 11 Verfahren beim Backup (Differential Backup) Full Diff. Diff. Diff. Diff. Diff. Diff. BOOM So. Mo. Di. Mi. Do. Fr. Sa. Weniger Platzverbrauch als Full-Bkp. Kompletter Restore (2 Bänder) Restore schneller als bei Inc.-Bkp. Backup langsamer als bei Inc.-Bkp. Redundante Daten im Backup Hohe Medienanzahl & Kosten 12 6

7 Verfahren beim Backup (Incremental Backup) Full Inc. Inc. Inc. Inc. Inc. Inc. BOOM So. Mo. Di. Mi. Do. Fr. Sa. Weniger Platzverbrauch als Diff.-Bkp. Keine redundanten Daten im Bakup Schnellstes Backup-Verfahren Restore dauert länger als bei Diff./Full Bei Restore mehrere Bänder notwendig Weniger Datensicherheit (0 Redundanz) 13 TSM Bedienung (Client-Seite) Sehr einfache Installation & Bedienung Web-Interface, GUI oder Command Line LRZ-Online Dokumentation als Hilfe Beispiel Command Line: dsmc tsm> archive /home/reiner/datei1.txt tsm> query archive -subdir=yes /home/reiner/* tsm> retrieve replace=yes/no ARCHIVDATEI ZIELDATEI Beispiel GUI: dsm 14 7

8 TSM Bedienung (Client-Seite) 15 Archiv- & Backup Konfiguration LABS System 1 7 Server LABS System 2 13 Server HABS System 5 x IBM DS4500 (FastT900) IBM TS3500 IBM TS Server 2 x STK FLX TByte Disk Storage STK SL

9 LABS LTO Archiv- & Backup System 17 HABS High Performance ABS 18 9

10 HLRB2 High Performance Archiv 19 2 x Magnetband-Speichersysteme von IBM (1) IBM TS3500 (3584) 20 LTO II Laufwerke 35 MByte/s Transferrate Bandplätze 200 GByte pro Band 990 TByte Gesamtkapazität 2 Systeme Maximalausbau: Bandplätze TByte Kapazität 20 10

11 2 x Magnetband-Speichersysteme von IBM (2) 21 Unsere Schnelle: StorageTek SL Titanium Laufwerke 120 MByte/s Transferrate Bandplätze 500 GByte pro Band TByte Gesamtkapazität (entspr. 3,8 Mill. CD`s) (entspr. 1 Mrd. Bücher) (in PDF, 10 KB/Seite, 200 Seiten/Buch) Maximalausbau: Bandplätze TByte Gesamtkapazität 22 11

12 StorageTek Titanium Laufwerk Titanium T10000 Laufwerk 120 MByte/s Transferrate 500 GByte pro Band 23 Magnetband-Speichermedien 9 Spur Band 100MB QIC Kassette 250MB 8 mm Kassette 20GB 4 mm Kassette 2GB IBM 3590 Band 40GB IBM 3570 Kassette 7GB STK SD-3 Band 50GB 24 12

13 Den Daten auf der Spur 25 Aktuelle Tape-Technologien IBM Magstar 3592B: 500 GB, 80 MB/s (Mitte 2005) LTO II (IBM, HP, CERTANCE) 200 GB, 35 MB/s LTO III (IBM, HP, CERTANCE) 400 GB, 80 MB/s (Mitte 2005) STK T10000A (Next Generation Tape) 500 GB, 120MB/s (März 2006) Super DLT 600 (Quantum, HP) 300 GB, 72MB/s (Beginn 2005) 26 13

14 Zukünftige Entwicklung 27 Entwicklung Anzahl der Dateien Anzahl in Millionen Anzahl Backup & Archiv Dateien (Mio.) Anzahl Backup Dateien (Mio.) Anzahl Archiv Dateien (Mio.) Januar 2001: 229 Millionen Dateien 650 Nodes März 2007: 2,4 Milliarden Dateien 4268 Nodes Jahr 28 14

15 Entwicklung des Speichervolumens Datenvolumen in Terabyte Backup & Archiv Volumen (TByte) Backup Volumen (TByte) Archiv Volumen (TByte) Jahr Januar 2001: 39 Terabyte 650 Nodes März 2007: Terabyte 4268 Nodes Verdopplung des Datenvolumens ca. jedes Jahr!!! 29 Entwicklung des Speichervolumens (2) Annahme: 1 KByte entspricht 1 Liter Wasser Chiemsee, das Bayerische Meer (März 2007) Walchensee (Dezember 2002) * Mil. Kubikmeter (bzw. 125 TByte) Millionen Kubikmeter (bzw TByte) 30 15

16 Entwicklung des Speichervolumens (3) Annahme: 1 KByte entspricht 1 Liter Wasser Chiemsee, (März 2007) Bodensee (Dezember 2010) Mil. Kubikmeter (2.047 TByte) Mil. Kubikmeter ( TByte = 48,5 PByte) * Entwicklung des Speichervolumens (4) Annahme: 1 KByte entspricht 1 Liter Wasser Bodensee (Dezember 2010) Mil. m³ ( TByte = PByte = 21,6 EByte) Ostsee (Mitte 2019) * Mil. Kubikmeter ( TByte = 48,5 PByte) 32 16

17 Sicherung eines Backup-Systems Single Point of Failure: die interne Datenbank RAID 5 Plattensystem Hotspare-Mechanismus SW-Spiegelung der Datenbank gespiegeltes Recovery-Log tägliche Backups, Rollforward-Verfahren Bandkopien der Archivdaten Sicherung der Server-Images 33 Langzeitarchivierung (LZA): Was ist das? Normale Archivierung (eher unproblematisch) Aufbewahrungsdauer bis 10 Jahre Langzeit = Eine unbegrenzte in die Zukunft reichende Zeitspanne. Problemfelder: starke technologische Veränderungen Geändertes Nutzungsverhalten Langzeitarchivierung ( long-term digital preservation ) = Aktivitäten, die dem Erhalt der Verfügbarkeit der Dokumente über die Lebensdauer der Trägermedien und die Grenzen des technologischen Wandels hinweg dienen. Aufbewahrungsdauer größer 10 Jahre 34 17

18 LZA: Lebensdauer von Daten Lebensdauer begrenzt durch: Haltbarkeit des Datenträgers Verfügbarkeit der Hardware (Rechner und R/W) Verfügbarkeit des Betriebsystems Verfügbarkeit des Dateisystems Verfügbarkeit der Applikations-Software Verfügbarkeit des Dateiformates 35 LZA: Lebensdauer von Daten (Beispiel 1) Datenträger: 5 ¼ Zoll Floppy Disk Aufzeichnungsstandard: MS-Word, Version? Geschrieben: um 1985 Lesbar: 15 Jahre später (sehr) problematisch Datenträger: LTO Ultrium 1 Aufzeichnungsstandard: MS-Word, Version? Geschrieben: 2000 Lesbar: 15 Jahre später problematisch 36 18

19 LZA: Lebensdauer von Daten (Beispiel 2) Datenträger: Pergament (Codex Sinaiticus) Aufzeichnungsstandard: griechische Majuskel Geschrieben: um 350 Lesbar: 1650 Jahre später problemlos Datenträger: Stein Aufzeichnungsstandard: Ägyptische Hieroglyphen Geschrieben: 4000 v. Chr. bis 300 v. Chr. Lesbar: 6000 Jahre später problemlos 37 LZA: Was kann man tun? HW und SW Museum Originalzustand HW & SW erhalten Beibehaltung der ursprünglichen Datenformate Emulation Beibehaltung der ursprünglichen Datenformate HW und SW (Betriebssystem, Anwendung) nachbilden Migration Periodisches überführen der Datenformate in neue Formate Anpassung an neue HW und SW Lesbarkeit des Speichermediums Periodisches kopieren auf neue Medien (alle 3 bis 10 Jahre) Generationswechsel der Speichertechnologien berücksichtigen Durch bessere und schnellere Hardware machbar Nicht möglich! Möglich? Aufwändig! Möglich! 38 19

20 LZA: Notwendige Schritte Reduzierung der verwendeten Dateiformate Aufwand steigt mit Anzahl der Dateiformate Standardisierung Dateiformate für LZA PDF/A (ISO , seit Sept. 2005) Metadaten Object Identifier Open Source Dateiformate Lesbar von unterschiedlicher SW OAIS (Open Archival Information Systems) Referenz Modell Datenimport, Speicherung, Zugriff, Datenverwaltung Administration, Archivierungsstrategien (z.b. Migration) 39 LZA: Weitere Anforderungen Automatisierung Migration der Daten und Umkopieren der Medien entsprechend der Alterung der Daten (Band) über Metadaten Verschlüsselung der Daten Schutz vor fremden Zugriffen Signatur der Daten Authentizität der Daten auch nach Jahren eindeutig bestimmen Prüfsummen Übereinstimmung Original und Kopie kann sichergestellt werden Historienführung Alle relevanten Arbeitsschritte protokolliert. Über Signatur und Prüfsummen kann eine lückenlose Historie der Zugriffe erfolgen

21 Scan-Roboter Projekt Ziel: Digitalisierung und Archivierung Schriften des 16. Jahrhunderts Umfang der Digitalisierung Titel aus BSB-Bestand Seiten Zwei Scan-Roboter mit je 1100 Seiten/h Archivierungsvolumen Ca MByte/Seite Ca. 500 GByte/Tag Ca. 200 TByte Datenvolumen nach 2 Jahren 41 Vielen Dank! Es Es muss auf einem dieser muss Bänder auf sein! einem dieser Bänder sein! Dr. Bernd Reiner reiner@lrz.de 42 21