LuKII FAQ

Wissenschaftliche Informationen werden heute mehrheitlich digital erstellt und ebenfalls digital angeboten. Aus diesem Grund ist eine effektive Strategie zur digitalen Langzeitarchivierung für Forscher und Wissenschaftler aller Disziplinen essentiell notwendig. Viele Wissenschaftler wissen um diese Notwendigkeit, verlassen sich aber darauf, dass andere -insbesondere Bibliotheken- sich diesem Problem annehmen. Dies geschieht bisher nicht in zufriedenstellendem Maße.

Die Langzeitarchivierung digitaler Inhalte ist eine wichtige und keinesfalls triviale Aufgabe. Mehrfache backups bieten eine gewisse Sicherheit, berücksichtigen aber nicht in vollem Maße wesentliche Voraussetzungen, wie die Integrität, Authentizität oder die Benutzbarkeit von Objekten. Seit einigen Jahren findet darum umfangreiche Forschung auf diesem Gebiet statt. Projekte wie LOCKSS (Lots of Copies Keep Stuff Safe) und KOPAL (Kooperativer Aufbau eines Langzeitarchivs digitaler Informationen) leisten einen wesentlichen Beitrag zur Entwicklung digitaler Langzeitarchivierungsstrategien.

Ziel des LuKII-Projektes ist der Aufbau einer Netzwerk-Infrastruktur basierend auf der Bitstrom-Speicherung digitaler Objekte bei gleichzeitiger Wahrung der Integrität und Lesbarkeit.

Die wesentliche Aufgabe in LuKII (LOCKSS und KOPAL Infrastruktur und Interoperabilität) ist es, die Interoperabilität zwischen den Open-Source Elementen der beiden existierenden Archivierungssystemen (LOCKSS und KOPAL) herzustellen. Auf diesem Weg soll mit Hilfe etablierter Werkzeuge eine kostengünstige und effektive Bitstrom-Archivierung gewährleistet werden.

Organisatorisches 

1. Was sind die drei Hauptzielsetzungen von LuKII?

1. ein kostengünstiges LOCKSS Netzwerk mit einer Infrastruktur für technischen Support und Management für LOCKSS und Varianten (z.B. CLOCKSS) zu entwickeln,

2. die Interoperabilität zwischen LOCKSS und KOPAL herzustellen, um kostengünstige und effektive Bitstrom-Archivierung mit entwickelten Preservation-Tools zu verbinden,

3. den im Projekt hergestellten, vollständig entwickelten Prototypen (“LuKII prototype”) mit Hilfe von Daten aus deutschen institutionellen Repositorien zu erproben.

Indem man einen Prototyp entwickelt, der getestet ist und kostengünstig archiviert, wird man Open Access Repositories in Deutschland robuster zu machen. Dabei wird Bitstrom-Integrität (LOCKSS) mit einem gut entwickelten Mechanismus für Formatmigration und Datenweitergabe verbunden, um die Lesbarkeit zu sichern.

2. Wer sind die Projektpartner?

Die Projektpartner sind, neben der Humboldt Universität zu Berlin und der Deutschen Nationalbibliothek, die Bayrische Staatsbibliothek, hbz - Hochschulbibliothekszentrum NRW, Karlsruher Institut für Technologie, Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden, Universität Konstanz, Universitätsbibliothek Stuttgart, Universitäts- und Landesbibliothek Münster, Niedersächsische Staats- und Universitätsbibliothek Göttingen und die Staatsbibliothek zu Berlin - Preussischer Kulturbesitz.

3. Welche Rolle spielt die Humboldt Universität zu Berlin in LuKII?

Die Humboldt Universität zu Berlin, bzw. das Institut für Bibliotheks- und Informationswissenschaft (IBI) und der Computer- und Medien Service (CMS) ist in Zusammenarbeit mit der Deutschen Nationalbibliothek (DNB) Hauptinitiator von LuKII. Die technische und administrative Koordination und Entwicklung wird komplett von der HU und DNB übernommen.

4. Wer ist unser erster Kontakt bei technischen oder administrativen Problemen?

Für den ersten Kontakt nutzen Sie bitte: LuKII.IBI(at)hu-berlin.de 

Für technische Fragen können Sie auch das Deutsche LOCKSS Kompetenzzentrum nutzen: http://www.carpet-project.net/en/forum/themen/lockss/ 

Weitere Informationen finden Sie auch unter: http://www.lukii.hu-berlin.de

5. Wie funktioniert ein LOCKSS Netzwerk?

Ein LOCKSS Netzwerk speichert Kopien von Bitströmen verteilt auf mehreren Servern. Diese Server werden als “LOCKSS-Boxen” bezeichnet.

6. Was ist ein Private LOCKSS Network (PLN)?

Im Gegensatz zum globalen LOCKSS Netzwerk, das von dem an der Universität Stanford angesiedelten Team gepflegt und verwaltet wird, ist ein Private LOCKSS Network ein unabhängiges Netzwerk, das von einer Interessengemeinschaft betrieben wird. Während das globale LOCKSS Netzwerk durch die Mitglieder der LOCKSS Allianz finanziert wird, werden PLNs durch die jeweilige Community getragen. Das LOCKSS Team der Universität Stanford bietet hinsichtlich der Hardware-, Netzwerk- und Pluginkonfiguration Unterstüzung für PLNs an.

7. Welche Hardwarevoraussetzungen bestehen an eine LOCKSS-Box?    

Grundveraussetzung ist eine linuxkompatible, zweckbestimmte oder virtuelle Maschine mit mindestens zwei Kernen, 2GB RAM und 2TB Speicherplatz, welcher erweiterbar ist.

8. Muss ein Private LOCKSS Network (PLN) eine Mindestanzahl von LOCKSS-Boxen haben?    

Ja, es sollten mindestens 7 Boxen vorhanden sein, die geographisch verteilt sind. Zu beachten ist allerdings, dass dies lediglich technisch ausreichend ist. Um evtl. vorhandene sensitive Inhalte zu schützen, kann es notwendig sein, diese wesentlich weiter zu verteilen. Nur so kann eine Manipulation besser unterbunden werden.

9. Für wen werden die Inhalte einer LOCKSS-Box freigegeben?

Dies ist letztendlich eine Grundsatzentscheidung des Betreibers einer LOCKSS-Box. Üblich ist es, den Zugriff jenen zu gewähren, die auch Zugriff auf die Originalinhalte haben/hatten, wie etwa Benutzern einer Universitätsbibliothek. Die Konfiguration erfolgt über die Einstellungen für den LOCKSS Proxy.

10. Wie findet der Zugriff auf Inhalte einer LOCKSS-Box statt?

LOCKSS fungiert als sog. transparenter Proxy, d.h. Anfragen an Server mit archivierten Inhalten werden durch die LOCKSS-Box geleitet. Ist der Originalinhalt verfügbar, greift die LOCKSS-Box nicht weiter in den Netzwerkverkehr ein. Erst wenn der Inhalt nicht mehr verfügbar ist, liefert die LOCKSS-Box die archivierte Version des angeforderten Bitstroms aus. Dies geschieht für den Benutzer völlig transparent.

Personal/Finanzierung

1. Welche Schätzungen bestehen hinsichtlich der benötigten Personalressourcen für die Administration sowie für bibliothekarische Aufgaben?    

Die Betreuung einer LOCKSS-Box im globalen LOCKSS Netzwerk wird von dem LOCKSS Team der Universität Stanford mit ca. 1-2 Stunden im Monat bedacht. Innerhalb eines PLN können es je nach Aufgabenspektrum des PLN auch ein paar Stunden mehr werden, da es eventuell mehr Updates oder neue Plugins zum Installieren gibt.

2. Wie wird die Wartung und Entwicklung der Software gewährleistet? Muss man in der LOCKSS Allianz sein, um Einfluss an der Weiterentwicklung der Software nehmen zu können?

Das durch die Mitglieder der LOCKSS Allianz finanzierte Projektteam in Stanford entwickelt die LOCKSS Software bereits seit über einem Jahrzehnt. Um eine die Nachhaltigkeit der Entwicklungen zu gewährleisten, wurde sich bewusst für eine Open Source Veröffentlichung entschieden. Regelmäßigen Updates aus Stanford stehen damit allen LOCKSS Anwendern, auch PLNs, kostenfrei zur Verfügung. Eine Mitgliedschaft in der kostenpflichtigen LOCKSS Allianz beinhaltet neben der Wartung des globalen LOCKSS Netzwerks bestimmte Programmierarbeiten, wie z.B. das Erstellen von Plugins. Im Rahmen des LuKII-Projekts werden jedoch die HU und die DNB die nötigen Programmierungsarbeiten vornehmen. Dezentralität spielt für LOCKSS nicht nur auf technischer, sondern auch auf organisatorischer Ebene eine Rolle. Das deutsche LOCKSS Netzwerk ist im Rahmen des LuKII-Projekts für zwei Jahre durch die DFG finanziert. Mittelfristig gilt es, eine sich selbst tragende Finanzierung durch ein der LOCKSS Allianz ähnliches Modell zu erreichen.

3. Welcher Software-/Hardware-/Administrationsaufwand entsteht für eine aus Sicherheitsgründen notwendige Dislozierung der redundanten Speicherung?

Der Vorteil von einem LOCKSS Netzwerk ist gerade die räumliche Verteilung. Deshalb muss man nicht zusätzlich Speicherplatz für den LOCKSS Server an einem Standort räumlich verteilen. Ist dies trotzdem gewünscht, so ist dies problemlos möglich, die Kosten entsprechen denen bei einem "normalen" Linux-Server, den man etwa an ein SAN anbindet.

Technik

1. Wie läuft der Import von Inhalten ab?

Um Inhalte durch die LOCKSS Software sammeln und archivieren zu lassen, muss man als Institution (d.h. Rechteinhaber und Server-Verwaltung) durch ein entsprechendes "Permission Statement" dem LOCKSS System die Erlaubnis erteilen. Dieses "Permission Statement" wird auf dem selben Server abgelegt, auf dem sich auch die zu archivierenden Inhalte befinden. Der Import von Inhalten erfolgt durch die LOCKSS Software. Die genauen Regeln für das Sammeln werden durch Plugins und deren Konfiguration bestimmt. So entsteht im Rahmen des LuKII-Projekts etwa ein Plugin für die Archivierung von Inhalten aus in Deutschland weit verbreiteten OPUS-Repositorien. Ist das Plugin einmal auf einer LOCKSS-Box installiert und konfiguriert, erfolgt der Import von Inhalten automatisch. Es gibt generell keine Einschränkungen auf Dateiformate, LOCKSS ist neutral gegenüber jedweden Formattypen.

2. Was will das LuKII-Projekts über ein deutschlandweites LOCKSS Netzwerk hinaus erreichen?

LuKII hat zum Ziel, die Bitstrom-Archivierung seitens LOCKSS durch die im Rahmen des kopal-Projektes entstandene Open Source Bibliothek für das Preservation Management - "KoLobRI" - zu ergänzen. Dazu werden nach der Archivierung durch LOCKSS die Inhalte exportiert und von KoLibRI analysiert. KoLibRI extrahiert technische Metadaten und spielt diese zurück nach LOCKSS.

3. Wie werden die Inhalte gespeichert? 

LOCKSS basiert auf der Speicherung von Webinhalten und nutzt einen Web Crawler um diese über HTTP einzusammeln. Jeder Bitstrom wird genau so abgespeichert, wie sie er dem Herkunftsserver vorliegt. Aus logischer Sicht werden Inhalte in sogenannten Archival Units, etwa nach Jahrgang, zusammengefasst.

4. Was geschieht, wenn gleich benannte Dateien eingeliefert werden?    

Es spielt für LOCKSS keine Rolle, was der ursprüngliche Dateiname eines Inhalts ist. Zentrales Organisationsprinzip ist nicht ein Dateiname sondern vielmehr die URL. Falls der Bitstrom, der unter einer URL vorliegt, verändert wird, speichert LOCKSS diese neue Version, ohne dabei die alte zu verwerfen. Wird ein Bitstrom unter eine neue URL "verschoben", so handelt es sich aus LOCKSS Sicht dabei um einen neuen Bitstrom, der archiviert wird.

5. Was geschieht, wenn identische Inhalte eingeliefert werden? Wie wird das geprüft?

LOCKSS archiviert die Inhalte, die unter einer spezifischen URL ausgeliefert werden. Wenn eine Institution zufällig zwei identische Inhalte an zwei verschiedene URLs setzt, dann archiviert LOCKSS beide mit ihren verschiedenen URLs. Es wird nicht überpfüft, ob der Bitstrom bereits unter einer anderen URL archiviert wurde.

6. Wie skalierbar ist das Netzwerk hinsichtlich der Anzahl der LOCKSS-Boxen und des verwalteten Speicherplatzes?    

Das Netzwerk ist theoretisch unbegrenzt erweiterbar. Das globale LOCKSS Netzwerk ist derzeit das größte seiner Art und besteht aus über 200 LOCKSS-Boxen.

7. Wie wird geprüft, dass die verteilt gespeicherten Inhalte integer sind?

Die Integrität der Inhalte wird in regelmäßigen Intervallen geprüft. LOCKSS-Boxen, die die gleichen Archival Units archivieren, gleichen die Prüfsummen der jeweiligen Bitströme untereinander ab. Gibt es einen Dissens, so wird eine Wahl angestoßen - die Prüfsumme der Mehrheit gewinnt. Die beschädigten Bitströme werden auf den jeweiligen Boxen durch integere ersetzt. All dies wird von den LOCKSS-Boxen geloggt, so dass jederzeit nachvollzogen werden kann, welche Probleme vorlagen und welche Maßnahmen ergriffen wurden.

8. Welche Metadaten werden unterstützt?

Während der Fokus von LOCKSS auf der Bitstrom Archivierung liegt, gibt es dennoch Unterstützung für deskriptive Metadaten nach einem OpenURL kompatiblen Schema. Im Rahmen des LuKII-Projekts soll die Metadatenunterstützung auf technische Metadaten ausgeweitet werden. Es werden die von KoLibRI erzeugten technischen Metadaten verwendet werden. Im Projekt wird METS als Standard verwendet werden.

9. Kann eine Formatmigration inner- und/oder außerhalb des PLN durchgeführt werden? Bleiben dabei die Zusammenhänge zum ursprünglichen Bitstrom gewahrt? 

LOCKSS implementiert für die Formatmigration eine ad-hoc Lösung. Diese on-the-fly Migration basiert auf dem auf HTTP-Ebene standardisierten Konzept der Content-Negotiation: kann ein vom Browser unterstütztes Dateiformat nicht ausgeliefert werden, so wird der entsprechende Bitstrom ad-hoc in ein unterstütztes Format umgewandelt. Die migrierte Datei wird nicht in das Langzeitarchiv aufgenommen, kann aber gecached werden. Im LuKII-Projekt soll dieses Konzept um das der prophylaktischen Migration ergänzt werden. Dazu soll wieder die im Rahmen des kopal-Projektes entwickelte KoLibRI-Bibliothek verwendet werden. Droht eine Formatveraltung, so werden alle Bitströme des entsprechenden Formats von KoLibRI aus LOCKSS ausgelesen und migriert. Die migrierte Version wird zurück in das LOCKSS Netzwerk gespielt, wobei die Vorgängerversionen immer aufbewahrt und die Migrationshistorie dokumentiert wird.

10. In welchen Sprachen ist die LOCKSS Software geschrieben? 

In Java (50K+ lines Code plus weitere 55K lines Unit Test Code), XML (Plugins, Manifest). Die KoLibRI Bibliothek ist ebenfalls in Java implementiert.