LOCKSS FAQ

1 Organisatorisches
1.1 Wie funktioniert ein LOCKSS Netzwerk?
1.2 Was ist ein Private LOCKSS Network (PLN)?
1.3 Welche Hardwarevoraussetzungen bestehen an eine LOCKSS-Box?
1.4 Muss ein Private LOCKSS Network (PLN) eine Mindestanzahl von LOCKSS-Boxen haben?
1.5 Für wen werden die Inhalte einer LOCKSS-Box freigegeben?
1.6 Wie findet der Zugriff auf Inhalte einer LOCKSS-Box statt?

2 Personal/Finanzierung
2.1 Welche Schätzungen bestehen hinsichtlich der benötigten Personalressourcen für die Administration sowie für bibliothekarische Aufgaben?
2.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?

3 Technik
3.1 Wie läuft der Import von Inhalten ab?
3.2 Was will das LuKII-Projekts über ein deutschlandweites LOCKSS Netzwerk hinaus erreichen?
3.3 Wie werden die Inhalte gespeichert?
3.4 Was geschieht, wenn gleich benannte Dateien eingeliefert werden?
3.5 Was geschieht, wenn identische Inhalte eingeliefert werden? Wie wird das geprüft?
3.6 Wie skalierbar ist das Netzwerk hinsichtlich der Anzahl der LOCKSS-Boxen und des verwalteten Speicherplatzes?
3.7 Wie wird geprüft, dass die verteilt gespeicherten Inhalte integer sind?
3.8 Welche Metadaten werden unterstützt?
3.9 Kann eine Formatmigration inner- und/oder außerhalb des PLN durchgeführt werden? Bleiben dabei die Zusammenhänge zum ursprünglichen Bitstream gewahrt?
3.10 In welchen Sprachen ist die LOCKSS-Software geschrieben?

Organisatorisches

1.1 Wie funktioniert ein LOCKSS Netzwerk?
Ein LOCKSS Netzwerk speichert Kopien von Bitstreams verteilt auf mehreren Servern. Diese Server werden als “LOCKSS-Boxen” bezeichnet.

1.2 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 Alliance 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.

1.3 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.

1.4 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.

1.5 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 (siehe unten).

1.6 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 Bitstreams aus. Dies geschieht für den Benutzer völlig transparent.

Personal/Finanzierung

2.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.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-Alliance 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-Projektes für zwei Jahre durch die DFG finanziert. Mittelfristig gilt es, eine sich selbst tragende Finanzierung durch ein der LOCKSS Alliance ähnliches Modell zu erreichen.

Technik

3.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.

3.2 Was will das LuKII-Projekts über ein deutschlandweites LOCKSS Netzwerk hinaus erreichen?
LuKII hat zum Ziel, die Bitstream-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.3 Wie werden die Inhalte gespeichert?
LOCKSS basiert auf der Speicherung von Webinhalten und nutzt einen Web Crawler um diese über HTTP einzusammeln. Jeder Bitstream wird genau so abgespeichert, wie sie er dem Herkunftsserver vorliegt. Aus logischer Sicht werden Inhalte in sogenannten Archival Units, etwa nach Jahrgang, zusammengefasst.

3.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 Bitstream, der unter einer URL vorliegt, verändert wird, speichert LOCKSS diese neue Version, ohne dabei die alte zu verwerfen. Wird ein Bitstream unter eine neue URL "verschoben", so handelt es sich aus LOCKSS Sicht dabei um einen neuen Bitstream, der archiviert wird.

3.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 Bitstream bereits unter einer anderen URL archiviert wurde.

3.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.

3.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 Bitstreams untereinander ab. Gibt es einen Dissens, so wird eine Wahl angestoßen - die Prüfsumme der Mehrheit gewinnt. Die korrupten Bitstreams 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.

3.8 Welche Metadaten werden unterstützt?
Während der Fokus von LOCKSS auf der Bitstream Preservation 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.

3.9 Kann eine Formatmigration inner- und/oder außerhalb des PLN durchgeführt werden? Bleiben dabei die Zusammenhänge zum ursprünglichen Bitstream 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 Bitstream 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 Bitstreams 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.

3.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.