Agenda

• Christian Pietsch: Digitale Langzeitarchivierung mit LOCKSS
• Vitali Peil: Zeitreisen mit Memento

Digitale Langzeitarchivierung mit LOCKSS

Langzeitverfügbarkeit

• analog (z.B. Papier, Mikrofilm, Steintafel): mehrere hundert Jahre bei optimaler Beschaffenheit, Luftfeuchtigkeit, Temperatur, Benutzererziehung

• digital (z.B. magnetisch, optisch, Halbleiter): 2—30 Jahre, daher: bitstream preservation, content preservation

  mehr dazu: Einführung in die digitale Langzeitarchivierung (Natascha Schumann, nestor-Geschäftsstelle)

Digitalisierung: unausweichlich

Vorteile:

• einfacher, schneller und billiger Transport per Datennetz
• verlustfreies Kopieren und Nachnutzen
• geringe Herstellungskosten
• schnell durchsuchbar und auffindbar z.B. mit Suchmaschinen

Nachteile:

• Retrodigitalisate erfassen das Original nur näherungsweise
• komplexe Abhängigkeiten zwischen Hardware, Firmware, Betriebssystem und Anwendungssoftware -> bedroht die Langlebigkeit
• Privatspäre bedroht bei Anschluss ans Internet

Lebensdauer eines Datenträgers

• Medium Decay Time (MDT), Mean Time To Data Loss (MTTDL) oder Mean Time Between Failures (MTBF) abhängig von Ein-Ausschalt-Zyklen, Alter, Betriebsdauer, Temperatur, ...

  Herstellerangaben dazu sind mitunter um mehrere Größenordnungen übertrieben; s. Rosenthal (2010b).

  Magnetische Trägermedien halten höchstens 30 Jahre, im laufenden Betrieb 2–10 Jahre; im Mittel (MTBF) ca. 5 Jahre; s.a. Tabelle „Haltbarkeit der Trägermedien“ in der Wikipedia.

• Medium Expected Lifetime (MEL): “The estimated amount of time the media will be supported and will be operational within the electronic deposit system.”

  Fazit: Datenträger gehen irgendwann kaputt. Sie müssen ausgetauscht werden, und die Daten müssen repariert werden.

Digitale Erhaltungsstrategien

nestor-Empfehlungen (Handbuch Kap. 8):

1. Redundante Datenhaltung
2. Diversität eingesetzter Speichertechnik
3. Standards
4. Regelmäßige Medienmigration

Datenmigration

(nach nestor-Handbuch und OAIS-Referenzmodell)

Bitstream Preservaton:

• Refreshment (z.B. Festplatte ersetzen durch eine des gleichen Typs)
• Replication (z.B. Daten auf ein neues RAID-Speichersystem migrieren)

Migration:

• Repackaging (z.B. Daten in TAR-Archive statt in ZIP-Archive speichern)
• Transformation (z.B. Formatmigration von MS Office 97 nach OpenDocument-Format oder PDF) — oft verlustbehaftet, also Pristine copy aufbewahren!

Redundante Datenhaltung durch RAID

• RAID („Redundant Array of Inexpensive/Independent Disks“) ist die übliche Vorsichtsmaßnahme in Servern: erhöhte Ausfallsicherheit (außer bei RAID-0) durch mehrere Festplatten in einem Gerät, logisch zusammengefasst

Aber:

• fehlende räumliche Verteilung
• fehlende Diversität eingesetzter Speichertechnik, d.h.
• Fehler im RAID-Controller können alle Festplatten gleichzeitig zerstören

Redundante Datenhaltung durch Backups

• Backups sind nicht für die dauerhafte Speicherung bestimmt
• Backups-Lösungen können i.d.R. nicht automatisch feststellen, ob das Original beschädigt ist

Redundante Datenhaltung durch LOCKSS

Ziele von LOCKSS

(nach Rosenthal 2010a)

• Änderungen an rechtlichen Vereinbarungen möglichst unnötig machen
• das Kaufmodell von Papierpublikationen auf e-Publikationen übertragen: jede Bibliothek darf behalten, was sie gekauft hat — auch nachdem eine (e)Zeitschrift abbestellt wurde oder Konkurs ging
• Originale bewahren, wie sie zum Publikationszeitpunkt waren, inkl. historischem Kontext
• den LeserInnen einen transparenten Zugang zum archivierten Material gewähren

Bedrohungsmodell

(nach Rosenthal 2010a)

• bit rot
• format obsolescence
• censorship
• natural disasters (fire, flood)
• operator error
• insider abuse

Entwurfsprinzipien von LOCKSS

(lt. Maniatis et al. 2005)

• Cheap storage is unreliable.
• Use no long-term secrets. (Diffie [2003]: “The secret to strong security: less reliance on secrets.”)
• Use inertia. (Use rate limiting because we have no need for speed.)
• Avoid third-party reputation. (Fremdzertifikate usw.)
• Reduce predictability. (Angriffsfläche verringern durch pseudozufälliges Verhalten)
• Integrate intrusion detection intrinsically.
• Assume a strong adversary.

Begriffsklärung

• AIP (Archival Information Package) — Behälter für das zu archivierende Dokument (z.B. TAR, ZIP, BagIt)
• LOCKSS (Lots Of Copies Keep Stuff Safe) — ein Speichersystem mit Langzeitarchivierungsanspruch.
• Cache: ein Computer in einem LOCKSS-Netzwerk
• AU (Archival Unit) ist typischerweise eine Sammlung, die einen Jahrgang umfasst.
• GLN (Global LOCKSS Network) — das ursprüngliche LOCKSS-Netzwerk
• PLN (Private LOCKSS Network) — weitere, geschlossene LOCKSS-Netzwerke mit z.T. anderen Inhalten

Begriffsklärung

• Title database — XML-Datei, die den Inhalt einer AU beschreibt
• Plugin — legt fest, wie das Crawling (Filterregeln) und die Überprüfung geschehen sollen
• Manifest page – HTML-Seite mit der Genehmigung zum Crawling
• OAIS — Reference Model for an Open Archival Information System nach ISO 14721

Funktionsweise von LOCKSS

FOSS in Java für Linux mit Web-Interfaces

• Daemon: crawling/ingest z.B. von http://lockss.ub.uni-bielefeld.de/lockss/manifest.html
• Daemon: berechet kryptographische Prüfsummen (SHA-1)
• Daemon: macht regelmäßige automatische Integritätsprüfungen durch Abgleich mit anderen Caches (majority voting) und bei Bedarf automatische Reparatur, alles via LCAP (Library Content Audit Protocol)
• Web-Proxy: transparenter Zugriff bei Ausfall der Originalquelle (“direct first”) oder immer (“proxy first”). Der Web-Proxy unterstützt Linkresolver wie ezProxy/SFX/openURL und Memento

SAFE — Safe Archiving FEderation

PLN bestehend aus der Universität Bielefeld (UniBi, 1 Knoten) und belgischen Universitäten in

• Brüssel (ULB, 3-4 Knoten)
• Gent (UGent, 1-2 Knoten)
• Löwen (KUL, 1 Knoten)

und seit Ende 2013 der Memorial University of Newfoundland (MUN, Kanada, 1 Knoten).

Bielefelder LOCKSS-Knoten

• lockss.ub.uni-bielefeld.de
• Xen-VM z.Z. mit 2 virtuellen CPU-Kernen und 4 GB RAM
• anfänglich 1 TB, inzwischen 2 TB RAID-Speicher
• CentOS (binärkompatibel mit Red Hat Enterprise Linux)

Aktueller Stand des SAFE-PLN

• eingespeist durch Bielefeld: 5 AUs mit PDF-Dateien aus PUB aus den Jahren 2009—2013 (8 GB)
• z.Z. max. 200 GB Speicherplatz für jeden Partner
• diverse Hardware oder VMs im Einsatz -> gut!

Alternativen zu LOCKSS

• iRODS: steht für „integrated Rule Oriented Data System“ und ist ein „open source data grid, helping people organize and manage large collections of distributed digital data“. Grundlage u.a. des DA-NRW
• Rosetta von Ex Libris
• Portico: Dienstleister mit <1000 teilnehmenden Bibliotheken (alle außerhalb Deutschlands) und >200 Verlagen
• kopal (Kooperativer Aufbau eines Langzeitarchivs digitaler Informationen): DNB, GWDG, IBM
• DIMAG (Digitales Magazin des Landesarchivs Baden Württemberg): LAMP-Stack, RAID, MD5-Hashdateien
• Digitales Archiv des Bundesarchivs: OAIS-Implementierung von HP (DIN ISO 14721:2003)

Zusammenfassung

Erklärvideo über LOCKSS von Karen G. Schneider, University Librarian, Holy Names University, San Francisco

Literatur

• Neuroth H, Oßwald A, Scheffel R, Strathmann S, Huth K (Hrsg., 2010). nestor-Handbuch: Eine kleine Enzyklopädie der digitalen Langzeitarchivierung.
• Rosenthal DSH (2010a). “LOCKSS: Lots Of Copies Keep Stuff Safe”, Presented at the NIST Digital Preservation Interoperability Framework Workshop, Gaithersburg, MD.
• Rosenthal DSH (2010b). Keeping bits safe: how hard can it be? Communications of the ACM, 53(11), 47–55.
• Maniatis P, Roussopoulos M, Giuli TJ, Rosenthal DSH, Baker M (2005). The LOCKSS peer-to-peer digital preservation system. ACM Transactions on Computer Systems, 23(1).
• Beiträge des Workshops „Digitale Langzeitarchivierung“ auf der Informatik 2013 am 20.09.2013 in Koblenz