Während ein Backup dazu dient, einen kurz- oder mittelfristigen Datenverlust zu verhindern, soll ein Archiv wichtige Daten langfristig speichern. Anders als bei Backups stellt das Archiv dabei keine Kopie der Livedaten dar, sondern das Original genau dieser Daten. Für die Archivierung gelten daher andere Regeln als für ein Backup. Je nach Format erhält ein Archiv keine oder nur sehr sporadische Updates und die Daten werden oft jahrelang überhaupt nicht angerührt – und falls doch, dann um einen bestimmten Datensatz daraus zu extrahieren oder die Lagerstätte zu wechseln. Um die Sicherheit der archivierten Informationen zu gewährleisten, sollten Anwender zudem nicht nur ein Archiv, sondern mindestens eine weitere Kopie an einem anderen Ort sichern.

Früher schrieben Unternehmen eine Kopie ihrer Archive auf Magnetbänder – und streng genommen wäre das selbst heute keine schlechte Idee. Im Jahr 2006 las der Autor dieses Beitrags die Daten von einer Reihe von QIC-Tapes (Quarter Inch Cartridges) zurück, die er 20 Jahre zuvor unter MS-DOS 3.2 beschrieben hatte. Wenige werden sich noch an die QIC-Streamer erinnern, die damals anstelle eines zweiten Floppy-Laufwerks in den Computer geschraubt und deren Bänder mit 40 bis 60 MByte Kapazität beschrieben wurden. Trotz unsachgemäßer Lagerung hatten diese Bänder samt der Daten die Zeit überstanden. Den Test wiederholte der Autor zwischen 2002 und 2022, dann aber mit LTO-1/2- und AIT-Bändern. Das Ergebnis war identisch: Alle Daten hatten überlebt.

Doch mit welchem Tool lassen sich Daten wiederherstellen, die 20 Jahre zuvor geschrieben wurden – besonders, wenn das OS oder die damals üblichen Backupprogramme nicht mehr existieren? Die Antwort ist simpel: Das 1986 verwendete DOS-Backup-Programm hieß "Resq" und war eine Implementierung des GNU-Tape-Archivers: Tar [1]. Exakt dasselbe Tool, das 2002 die Daten auf LTO und AIT schrieb und 2022 wiederherstellte. Im nun folgenden Artikel möchten wir Ihnen dieses mittlerweile 45 Jahre alte Werkzeug genauer vorstellen und zeigen, warum Sie auch heute noch Archive mit Tar und ein paar zusätzlichen Helfern erstellen sollten, wenn Sie diese für die nächsten 20 Jahre oder länger behalten möchten.

Warum sollten Sie sich im Jahr 2024 mit einem Backup- und Archivtool von 1979 auseinandersetzen, wo es doch so viele scheinbar einfache und moderne Produkte mit Cloudanbindung gibt? Der Grund ist simpel: Werfen Sie einen Blick zurück auf das Jahr 2004 und die damals verfügbaren Tools und Medien. Keine produktive IT-Abteilung hat heute noch Hard- oder Software von 2004 im Einsatz, aber auf die Archivdaten von damals sollten Sie noch Zugriff haben. Eine Archivstrategie funktioniert nur dann über einen so langen Zeitraum, wenn Sie die Daten in einem Format sichern, das sowohl von der Hard- als auch der Software oder dem Netzwerkprotokoll und besonders von einem bestimmten Softwarehersteller unabhängig funktioniert. Ein Archiv von 2004 hat in der Zwischenzeit (hoffentlich) etwa fünf bis acht Mal den Datenträger gewechselt. Wenn dabei das Format unverändert blieb, stellt das kaum ein Problem dar. Schwieriger wird es natürlich, wenn die Hersteller von Backup- und Archivprogrammen Ihre Tools einstellen oder größere Änderungen an der Datenspeicherung vornehmen.

In der aktuellen Zeit mögen Cloud-Speichersysteme mit S3-Protokoll eine gute Zielplattform sein. Allerdings gilt das nur dann, wenn sich die Anwender nicht auf proprietäre Formate und Zugänge der Hersteller verlassen oder diese gar mit Zugangsbeschränkungen daherkommen. Etliche der aktuellen Cloudanbieter offerieren zwar vergleichsweise günstige Langzeit-Archivspeicher, machen aber Einschränkungen beim Zugang zum Archiv, um den Anwender den Umzug des kompletten Archivs zu erschweren. Amazon beispielsweise erlaubt Kunden des "Glacier"-Diensts nur eine begrenzte Lesekapazität pro Monat. Wer mehr von seinen eigenen Daten herunterladen will, muss eine Abrufgebühr zahlen.

Tar fügt Dateien in einem simplen, sequenziellen Dateiformat zusammen. Eine Tar-Datei lässt sich problemlos in mehrere Teile zerlegen und später wieder zusammenfügen, entweder via Tar selbst mit dem Tape-Length-Parameter oder mit einem externen Tool wie split. Dabei muss Tar nicht schon von Beginn an wissen, wie groß die Einzelteile ausfallen. Ein Archiv kann daher aus einer oder mehreren Dateien bestehen. Ein großes Problem des Tar-Formats ist allerdings, dass ihm ein Inhaltsverzeichnis fehlt. Das Tool weiß beim Start noch nicht, welche Dateien in das Archiv kommen und in welchem Segment sie letzten Endes stehen werden. Daher kann das Tool auch nicht an den Anfang der Datei ein Verzeichnis schreiben. Wer also eine einzelne Datei aus einem Archiv extrahieren möchte, braucht dafür Zugriff auf das komplette Archiv. Dieser Nachteil ist akzeptabel, wenn man davon ausgeht, dass Anwender nur selten auf das Archiv zugreifen müssen.

Das fehlende Verzeichnis erschwert es dem Anwender, zu einem bestehenden Tar-Archiv inkrementell geänderte Daten hinzuzufügen. Der Prozess muss zuerst das komplette Archiv einlesen. Diese Funktion benötigen Sie bei Archiven eher selten, aber falls doch, gibt es einen simplen Trick, um den Vorgang massiv zu beschleunigen. Neuere Varianten des Tar-Tools können ein Snapshot-File mit der Endung ".snar" erzeugen, das das in der Tar-Datei fehlende Inhaltsverzeichnis enthält. Mithilfe des SNAR-Files lassen sich dann zügig geänderte Dateien hinzufügen. Zudem gibt es Tools, die eine SNAR-Datei auslesen. Somit lässt sich das Inhaltsverzeichnis einsehen, ohne das Archiv selbst zu öffnen.

Je nachdem, welchen Typ Daten Sie archivieren möchten, kann Tar verschiedene Kompressionstools einbeziehen. Das klassische GNU-Zip-Tool verwendet den quelloffenen "Deflate"-Kompressionsalgorithmus (eine Kombination von LZ77 und Huffman Coding), wie er auch in Dateiformaten wie PNG oder PDF seit Jahrzehnten zum Einsatz kommt. Optional verspricht das ebenfalls quelloffene bzip2-Format eine bessere Kompression mit moderneren Algorithmen, braucht dafür aber merklich länger. Noch effizienter arbeitet die XZ-Komprimierung, die unter anderem der Komprimierung von Linux-Kerneln und Initial-Ramdisk-Images dient, ebenfalls auf Kosten der Performance. Ohne zusätzliche Tricks auf der Kommandozeile nutzen die Kompressionsprogramme übrigens immer nur einen CPU-Kern. In einem kurzen Test fügen wir 21 GByte an PDF-Dateien in ein Tar-Archiv. Mit gzip-Kompression dauert das auf einem Core-i7 von 2019 etwa zehn Minuten und hat ein 18 GByte großes TGZ-File zur Folge. Mit XZ als Kompressionstool allerdings dauert die Archiverstellung ganze zwei Stunden, wobei das "tar-xz"-File am Ende auch nicht kleiner als 18 GByte ausfällt.

Ob die Kompression Sinn ergibt, hängt von den Quelldaten und deren Komprimierbarkeit ab. PDF-Dateien setzen bereits Kompression ein und profitieren nur wenig von gzip und Co. Datenbank-Dumps hingegen lassen sich hervorragend schrumpfen. Außerdem ist es deutlich aufwendiger, ein beschädigtes Archiv mit Kompression zu reparieren als ein unkomprimiertes. Tar offeriert eine Reihe von Funktionen, um Daten aus beschädigten unkomprimierten Archiven wiederherstellen zu können. Hier bietet es sich also eher an, eine Kopie des Archivs auf einem deduplizierenden Speicher zu lagern.

Mit oder ohne Komprimierung kann ein weiteres freies Tool dabei helfen, ein beschädigtes Archiv wiederherzustellen oder Revisionssicherheit zu gewährleisten. Interessanterweise wurde dieses Parchive-Tool eigentlich entwickelt, um das Filesharing via Binary Usenet zu verbessern – eine Plattform, die jahrelang hauptsächlich der illegalen Verbreitung urheberrechtlich geschützter Inhalte diente.

Das Usenet ist, ähnlich wie E-Mail, für ASCII-codierte Nachrichten mit einer limitierten Größe gedacht. Binary Usenet Groups codieren Binärdateien mit Base64 (binary-to-text encoding) und verteilten Sie auf Dutzende oder gar Hunderte einzelne Usenet-Posts. Das Fehlen eines einzigen Posts beschädigt die Quelldatei irreparabel. Das Parchive-Tool berechnet aus den Quelldaten via Erasure Coding zusätzliche Paritätsinformationen und sichert diese in einer oder mehreren PAR2-Dateien. Erasure Coding ist damit prinzipiell RAID 5/6 auf Dateiebene und kommt auch bei SDS-Speichersystemen wie Ceph oder GlusterFS zum Einsatz.

Der Anwender bestimmt dabei, wie viel Paritätsinformationen das Parchive-Tool zu seinen Daten hinzufügt. Mehr Parität braucht entsprechend mehr Speicher, erlaubt aber auch die Korrektur größerer Beschädigungen am Archiv. Somit lässt sich ein PAR2-Datensatz auch nutzen, um die Integrität und Revisionssicherheit eines Archivs zu gewährleisten. Nachträgliche Änderungen eines Archivs spürt Parchive auf und kann diese korrigieren, falls nicht zu viele der Originaldaten betroffen sind. Das quelloffene Par gibt es in verschiedenen Varianten für alle gängigen Betriebssysteme, wobei in diesem Artikel hauptsächlich das par2cmdline-Tool für alle gängigen Linux-Distributionen zum Einsatz kommt. Für Windows-Anwender gibt es Tools wie Quickpar oder das neuere MultiPar.

Die Kombination aus Tar und Par arbeitet komfortabel, wenn Sie Ihr Tar-Archiv in eine Reihe gleich großer Segmente splitten und dazu passend gleich große PAR-Dateien erstellen. Ein Tipp am Rande für Hobbyfotografen: Parchive eignet sich hervorragend, um Ordner voller JPG-, DNG- und CR2/3-Digitalfotos vor Beschädigungen, unbeabsichtigten Änderungen oder Dateiverlusten abzusichern.

Moderne Cloudanbieter versprechen, Ihre Daten verschlüsselt abzulegen. Das bringt jedoch aus mehreren Gründen kaum Sicherheit. Erstens sichern die Cloudanbieter die Schlüssel vorzugsweise mit ihrem Konto ab. Verschafft sich ein Hacker Zugriff zu Ihrem Cloudaccount, erlangt er Zugriff auf diesen Key und damit auch auf Ihre Archivdaten. Im Sommer 2023 hatten Hacker einen Azure Root Key von Microsoft erbeutet und erlangten damit Zugriff auf Hunderte Kundenkonten. Damit standen die auf Serviceseite verschlüsselten Blob-Speicher auch für die Hacker offen, sofern betroffene Kunden das Key-Management von Azure und keine eigenen, "customer-provided" Schlüssel verwendeten.

Zweitens funktionieren verschlüsselte Speicher eben nur bei dem jeweiligen Anbieter. Wollen Sie Ihr Archiv aus Redundanzgründen auf mehreren Speichern sichern oder irgendwann aus Kostengründen umziehen, müssen Sie diese jeweils über den Dienst des jeweiligen Anbieters neu verschlüsseln. Also sollten Sie besser selbst Ihr Archiv verschlüsseln, bevor Sie es zu einem Cloud-Storage übertragen. Die Verschlüsselung kann dabei an verschiedenen Stellen erfolgen: Via Pipeline könnten Sie den Vorgang in den Kommandoaufruf von Tar integrieren, ebenso wie das "split"-Kommando für Multipart-Archive. So wird das in vielen How-tos auch empfohlen. Ein Beispiel:

Ihre PAR-Informationen würden sich dann aber auf die bereits verschlüsselten Blöcke beziehen. Bevorzugt erstellen Sie daher das Archiv samt PAR-Daten zunächst unverschlüsselt und lassen dann den gewünschten Chiffrierer über alle Blöcke laufen. Das vereinfacht eine gegebenenfalls nötige Neuverschlüsselung. Sollte jemand beispielsweise in zehn Jahren eine Methode entwickeln, um heute als sicher geltende Algorithmen wie AES 256 zu knacken, müssen Sie Ihr Archiv mit einer dann zeitgemäßen Methode neu verschlüsseln. Wenn Sie alle Blöcke erst am Ende verschlüsseln, bleiben die Paritätsinformationen valide und müssen nicht neu berechnet werden.

Bei der Verschlüsselung können Sie auf zwei ebenfalls alte und etablierte Technologien zurückgreifen: OpenSSL und GPG. Nur weil die Programme mehr als 20 Jahre alt sind, heißt das aber noch lange nicht, dass die verwendeten Verschlüsselungsmethoden unzeitgemäß wären. Beide Tools binden die Chiffrieralgorithmen über Funktionsbibliotheken ein. Gibt es neue, verbesserte Verschlüsselungsmethoden, stehen diese in beiden Werkzeugen zügig zur Verfügung. Die Programme erlauben sowohl symmetrische als auch asymmetrische Verschlüsselungen.

Symmetrische Verfahren nutzen ein und denselben Schlüssel zum Ver- und Entschlüsseln. Asymmetrische Verfahren verwenden einen öffentlichen Schlüssel für das Chiffrieren und einen privaten zum Dechiffrieren (Public- und Private-Key). Die asymmetrische Verschlüsselung ist dabei sicherer, aber auch langsamer. Ihr großer Vorteil liegt jedoch woanders, denn Sie müssen den öffentlichen Schlüssel (zum Verschlüsseln) nicht geheim halten. Damit lässt er sich auf mehreren Systemen zur Erstellung von Archiven einsetzen, auch auf cloudbasierten Umgebungen oder Rechnern mit geringen Sicherheitsvorkehrungen. Nur den privaten Schlüssel müssen Sie schützen.

Bei genauerem Hinsehen setzen beide Verfahren streng genommen eine symmetrische Verschlüsselung für die Daten an sich ein. Ein asymmetrisches Verfahren generiert für den zu verschlüsselnden Datenblock einen symmetrischen Key, sichert diesen dann aber asymmetrisch verschlüsselt in der Zieldatei ab. Ohne den Private-Key kann der Dechiffrierer also nicht auf den symmetrischen Schlüssel zugreifen.

Sowohl GPG als auch OpenSSL offerieren einfache Verfahren, um Schlüssel zu erstellen und diese dann – üblicherweise in einer Pipe – zur Verschlüsselung heranzuziehen. Das Ganze sieht dann schematisch wie folgt aus:

und im Gegenzug:

Etwas einfacher und komfortabler funktioniert das Ganze mit einem etwas neueren Open-Source-Tool namens age [2], das auf Dateiverschlüsselung spezialisiert ist. Auch hier kommt das AEAD-Verfahren zum Einsatz (Authenticated Encryption with Associated Data), also prinzipiell das Konzept, eine synchron verschlüsselte Datei mit einem asynchronen Verfahren abzusichern. Age setzt die Verschlüsselung "Chacha20Poly1305" ein, die auch in IPSec, TLS und SSH zum Einsatz kommt.

Age generiert auf Wunsch einen eigenen Schlüsselsatz, kann aber auch ein bestehendes SSH-Schlüsselpaar verwenden. Das ist besonders praktisch, weil viele Unternehmen bereits über ein zentrales Schlüsselmanagement wie zum Beispiel DogTag oder einen Vault wie Hashicorp Vault verfügen. Damit lassen sich existierende Schlüsselpaare für age benutzen.

Ein nach diesem Verfahren verschlüsseltes Archiv können Anwender dann getrost auf Cloudsystemen verschiedener Anbieter lagern. Selbst wenn Kriminelle Zugang zu den Archivblöcken erhalten sollten, bleibt dieses ohne den privaten Key verschlossen. Einen Nachteil hat ein verschlüsseltes Archiv allerdings: Wenn Sie eine Kopie davon auf einem Ihrer lokalen Datacenter-Speicher vorhalten, nutzen Technologien wie Speicherkomprimierung oder Deduplizierung nichts. Bei Preisen von 100 Euro für Festplatten mit 10 TByte Kapazität dürfte das Interesse der Anwender an derartigen Technologien aber ohnehin verschwindend gering ausfallen. Der Einsatz dieser Verfahren lohnt angesichts der von ihnen verursachten Performanceverluste ohnehin nicht mehr wirklich.

Auf dem System, das das Archiv vorbereiten soll, erstellen Sie eine Unterverzeichnisstruktur im Stil von "/archiv/meta", "/archiv/dec" und "/archiv/enc". Legen Sie fest, wie groß die Archivblöcke ausfallen sollen und wie viel Redundanz Par2 hinzufügt. Unser Setup arbeitet beispielsweise mit 1-GByte-Blöcken und zehn Prozent PAR-Redundanz. Bauen Sie das initiale Archiv aus dem Quellverzeicnis nach "/archiv/dec". Metainformationen wie gegebenenfalls Schlüsselpaare oder das Tar-Snapshot-File sichern Sie im "meta"-Verzeichnis. Möchten Sie die Paritätsdaten (in Kopie oder Original) getrennt vom Archiv aufbewahren, können Sie diese ebenfalls in "meta" ablegen:

Der letzte Punkt ist hierbei kein Druckfehler. Das "split"-Kommando fügt den Blöcken eine Dateiendung nach dem Schema aa, ab, ac und so weiter hinzu. Ob alles korrekt lief, prüfen Sie im Anschluss mit

Das Kommando listet alle im Archiv vorhandenen Dateien auf und überprüft deren Integrität. Im nächsten Schritt fügen Sie dem Archiv die Erasure-Coding Redundanz hinzu:

Der Parameter "-u" sorgt dafür, dass alle Par2-Paritätsblöcke gleich groß ausfallen, während "-r10" die Redundanz festlegt. Wie groß der Wert von "-m" für "Memory" ausfällt, hängt von ihrem System ab. Par2 ist in der Regel bescheiden und nutzt nicht mehr als 16 MByte Arbeitsspeicher für die Paritätsberechnung. Der Prozess lässt sich allerdings erheblich beschleunigen, wenn Sie Par2 mehr RAM zugestehen. In unserem Beispiel wären das 4 GByte. Im Anschluss an die Paritätsberechnung können Sie die Datei-Integrität prüfen:

Der Aufruft "v" überprüft sowohl die Par2-Blöcke als auch das dazu passende Archiv, unternimmt bei einem Problem aber keinen Reparaturversuch. Für einen "harten" Test, entfernen Sie einen ihrer "tar.xx"-Blöcke aus dem Verzeichnis und starten Par2 mit dem Parameter "r" für repair. Das Tool muss dann den fehlenden Block aus den bestehenden Daten und Paritätsinformationen identisch zur originalen Datei wiederherstellen. Zum Schluss generieren Sie ein Schlüsselpaar im Metaverzeichnis und verschlüsseln das komplette Archiv nebst Paritätsinformationen:

Kopieren Sie aus dieser Datei den Public Key heraus und erstellen Sie ein "encrypt"-Skript nach folgendem Schema:

Im Anschluss haben Sie das verschlüsselte Archiv im Verzeichnis "/archiv/name/enc" liegen. Hier können Sie dann mit

einen oder mehrere Blöcke entschlüsseln und mit Ihren Originalen vergleichen. Danach nutzen Sie ein passendes Filetransfer-Tool, um Ihr Archiv mit dem gewählten Protokoll zu seiner Lagerstätte zu übertragen. Aus Sicht des Archivs spielt es nun keine Rolle, ob Sie ein Dateisystem oder einen Objektspeicher wie S3 nutzen.

Bei der Datenarchivierung geht es nicht um schöne, moderne Werkzeuge, die es in wenigen Jahren vielleicht gar nicht mehr gibt, sondern um Langlebigkeit. Archive, die Sie nach dem hier vorgestellten Prinzip erstellen, sollten mit nur wenigen Interaktionen lange Zeit überdauern. Und wenn Sie dabei auf Nummer sichergehen möchten, fügen Sie Ihrem Archiv noch als separate, unverschlüsselte Dateien die Quellcodes der Open-Source-Tools Tar, Par2 und age hinzu.