Vnode Schnittstelle - Frank Kardel

BackStage
3.4.2 Archivmanager
Der Archivmanager stellt bei der langfristigen Datenhaltung die zentrale Komponente
dar. Mit dem Archivmanager werden zusammengehörige Datensammlungen, wie sie
sich in heutigen Dateisystemen antreffen lassen, verwaltet.
Verfolgt man die Entwicklung eines Dateisystems, so stellt man bei den meisten Datenmengen
eine ständige Veränderung fest. Zu bestimmten Zeitpunkten stellt sich auch
ein mehr oder weniger konsistenter Zustand der Datenmenge ein. Das ist dann der
Fall, wenn eine offizielle Version eines Programmsystems fertiggestellt ist. Zu diesen
Zeitpunkten ist es meistens auch wünschenswert, diesen Zustand zur späteren Referenz
zu dokumentieren; also zu archivieren.
Meistens erstreckt sich die Lebensdauer solcher Datenmengen aber über mehr als einen
konsistenten Ausgabestand hinaus, was zu mehreren “konsistenten” Zuständen
einer Datenmenge führt. Daher sollten diese Versionen möglichst auch gemeinsam in
einem Archiv gespeichert werden.
Deshalb ist es für ein Archiv geboten, mehrere Versionen einer dateisystemartig strukturierten
Datenmenge zu speichern. Ein Archiv beherbergt die Entwicklung eines Programmsystems,
einer Datenbasis oder eines Forschungsprojekts. Aufgabe des Archivmanagers
ist es also, die Mechanismen zur Speicherung und zeitlichen Dokumentation
von zusammengehörigen Datenbeständen aus Dateisystemen auf Abruf
bereitzuhalten.
Die Orientierung an den Dateisystemstrukturen ergibt sich aus der Beobachtung, daß
sich die meisten heute verbreiteten Dateisysteme mit erträglichem Aufwand in eine
gemeinsame Darstellungsform überführen lassen. Die zu archivierenden Daten sind
meistens auch von der Dateisystemstruktur abhängig, in der sie abgelegt sind. Sie werden
entsprechend der verfügbaren Dateisysteme organisiert. Ein Beispiel mag hier die
Namensgebung von Dateien auf MS/DOS basierten Systemen oder die möglichen Namenslängen
auf den verschiedenen Unixdateisystemen sein. Es ist nicht sinnvoll, sich
von den ursprünglichen Dateisystemstrukturen zu weit zu entfernen. Zumindest die
Möglichkeit der weitgehenden Rekonstruktion der ursprünglichen Dateisystemstruktur
muß gegeben sein. 1
Als Ziel sollte die Rekonstruktion von Eigenschaften der normalen Dateisystemschittstelle
angestrebt werden.
54
1. Bestimmte Eigenschaften, wie zum Beispiel die Lokalisation einer Unixdatei auf einer bestimmten
Inode wären allerdings eine zu scharfe Forderung. Selbst die meisten Backupsysteme
erfüllen sie nicht. Eigenschaften wie Inodenummern gehören auch nicht zu der normalen
Dateisystemschnittstelle eines Unixsystems, sondern stellen vielmehr eine Implementationseigenschaft
dar. Es gibt allerdings Fälle, wo diese Informationen von den Programmen genutzt
werden (Lizenzmechanismen). Jedoch sind solche Programmsysteme schon im
normalen Betrieb administrativ schwer zu handhaben.