Storage-VPS als Langzeitarchiv: Prüfsummen und par2

Storage-VPS als Langzeitarchiv: Archiv ist nicht Backup

Ein Storage-VPS als Langzeitarchiv funktioniert, wenn Sie den Nachweis mitliefern, dass jede Datei noch unverändert ist: ein Prüfsummen-Manifest, par2-Wiederherstellungsblöcke gegen Bit-Rot, eine monatliche Prüfung per systemd-Timer und eine zweite Kopie an einem anderen Ort. Diese vier Teile entstehen unten Schritt für Schritt, mit Befehlen, die auf einem frischen Ubuntu 24.04 laufen. Vorher aber die Grenze, die alles andere bestimmt.

Ein Archiv ist die Kopie fertiger Dinge, die Sie selten anfassen: die Fotos von 2019 oder das Rohmaterial eines abgeschlossenen Projekts. Diese Dateien ändern sich nicht mehr. Ein Backup ist die Kopie von Daten, die sich noch ändern, und es braucht Versionen und einen kurzen Rhythmus. Ein Archiv braucht etwas anderes: den Beleg, dass jede Datei in fünf Jahren noch bitgenau die Datei ist, die Sie abgelegt haben.

Diese Grenze hat eine Folge, die viele übersehen. Ein Archiv auf einem Storage-VPS ist eine einzige Kopie. Eine Kopie schützt vor nichts: nicht vor einem Tippfehler mit rm, nicht vor einer vergessenen Rechnung beim Anbieter, nicht vor einem Plattenausfall auf dem Host, und nicht vor einem gestohlenen SSH-Schlüssel. Warum eine Kopie auf einem Server kein Backup ist, steht ausführlich in Ist ein Storage-VPS ein Backup?. Die zweite Kopie gehört an einen anderen Ort. Für private Daten reicht eine externe Festplatte zu Hause, die Sie zweimal im Jahr anschließen und mit demselben Manifest prüfen. Wer die zweite Kopie auch online will, nimmt einen zweiten Server bei einem anderen Anbieter, nach demselben Muster wie bei einem VPS als Offsite-Backup-Ziel. Erst wenn sha256sum -c an beiden Orten dasselbe Manifest bestätigt, ist das Archiv gesichert.

Warum überhaupt ein Storage-VPS und kein normaler VPS? Weil ein Archiv genau das Lastprofil hat, für das die große, langsame Platte gebaut ist: einmal schreiben und selten lesen, dazu einmal im Monat eine sequenzielle Prüfung. Was die beiden Plan-Typen trennt, steht in Storage-VPS oder normaler VPS. Was eine HDD hinter einem Storage-VPS an Durchsatz liefert und warum das für diesen Zweck reicht, steht in welche Plattengeschwindigkeit ein Storage-VPS erreicht.

Was am Ende auf dem Server liegt

• Ein Verzeichnis /srv/archiv mit den Daten, in Ordnern pro Jahr oder pro Projekt.
• Eine Datei SHA256SUMS, das Manifest: eine Prüfsumme pro Datei.
• Pro Ordner ein par2-Satz, mit dem sich beschädigte Blöcke neu berechnen lassen.
• Ein systemd-Timer, der das Manifest jeden Monat prüft und den Dienst bei einer Abweichung als fehlgeschlagen markiert.
• Dieselben Daten, dasselbe Manifest und dieselben par2-Sätze auf der zweiten Kopie.

Die Befehle sind für Ubuntu 24.04 geschrieben. Auf Debian 12 und 13 sind sie bis auf den Benutzernamen im rsync-Befehl identisch, weil alles Beteiligte aus den GNU coreutils und dem Paket par2 kommt und systemd auf beiden Systemen läuft.

Welche Formen der deutsche Markt anbietet

Wer in Deutschland vergleicht, landet meist bei drei Namen: Hetzner, netcup und Contabo. Die drei verkaufen nicht dieselbe Form, und genau das macht den Vergleich schwer. Die eine Form ist ein VPS mit einer großen HDD im Paket, oft als Storage-VPS beworben. Die zweite ist ein kleiner Cloud-Server, an den Sie ein Volume hängen und später vergrößern. Die dritte ist reiner Speicherplatz ohne eigenes Betriebssystem, erreichbar per SFTP oder rsync, also streng genommen kein VPS. Der Workflow unten braucht eine Shell mit Root-Rechten und systemd, was die dritte Form ausschließt. Die Preise pro Terabyte ändern sich zu oft, um sie hier zu drucken. Der Vergleich in Euro pro TB steht in Storage-VPS-Anbieter in Deutschland, und was Sie vor dem Kauf abfragen sollten, in der Checkliste für die Wahl eines Storage-VPS.

Das erste Hochladen dauert so lange, wie Ihr Upload erlaubt

Der Anbieter wirbt mit einer Gigabit-Anbindung. Für die erste Befüllung ist das egal, weil die Grenze Ihr Anschluss zu Hause ist. Genauer: die Upload-Rate, die bei DSL und Kabel viel kleiner ist als die beworbene Download-Rate. Die Rechnung ist kurz. Ein Terabyte sind 8.000.000 Megabit. Geteilt durch die Upload-Rate in Megabit pro Sekunde ergibt das die Sekunden, geteilt durch 3.600 die Stunden.

[
  {
    "label": "DSL 50/10 (10 Mbit/s Upload)",
    "stunden": 222
  },
  {
    "label": "VDSL 250/40 (40 Mbit/s Upload)",
    "stunden": 56
  },
  {
    "label": "Kabel 1000/50 (50 Mbit/s Upload)",
    "stunden": 44
  },
  {
    "label": "Glasfaser 1000/500 (500 Mbit/s Upload)",
    "stunden": 4
  }
]

Die Werte sind Leitungsraten ohne Protokoll-Overhead, also die beste Zeit, die Sie erreichen können; in der Praxis kommt rund ein Zehntel dazu. Bei DSL mit 10 Mbit/s Upload dauert ein Terabyte rund 222 Stunden, also mehr als neun Tage Dauerbetrieb. Bei Glasfaser mit 500 Mbit/s sind es rund 4 Stunden. Zwischen den beiden liegt eine Größenordnung, und kein Anbieter kann daran etwas ändern. Wer mehrere Terabyte über DSL befüllen will, plant Wochen ein und lädt Ordner für Ordner hoch.

Zwei Folgen für den Ablauf. Erstens fahren Sie den Upload mit rsync, weil --partial nach einem Abbruch die halb übertragene Datei behält und sie beim nächsten Lauf als Basis nutzt. Zweitens erzeugen Sie das Manifest zu Hause, bevor Sie hochladen, und laden es mit hoch. Dann prüft der Server, ob die Übertragung vollständig war, und nicht nur, ob die Platte seit dem Upload gehalten hat.

rsync -a --partial --info=progress2 /pfad/zum/archiv/ ubuntu@203.0.113.10:/srv/archiv/

Der Schrägstrich am Ende des Quellpfads ist wichtig: mit ihm kopiert rsync den Inhalt des Ordners, ohne ihn den Ordner selbst als Unterverzeichnis.

Das Manifest erstellen: find und sha256sum

Eine Prüfsumme ist ein kurzer Fingerabdruck einer Datei. Ändert sich ein einziges Bit, ändert sich der ganze Fingerabdruck. SHA-256 ist der heute übliche Algorithmus dafür, und sha256sum gehört zu den GNU coreutils, ist also auf jedem Ubuntu vorhanden. Das Manifest ist eine Textdatei mit einer Zeile pro Datei: Prüfsumme, dann zwei Leerzeichen, dann der Pfad. Dasselbe Format prüft auch heruntergeladene ISO-Images, siehe Downloads mit Prüfsummen verifizieren.

Zum Üben legen Sie zwei Testdateien mit Zufallsdaten an. Sie stehen für Ihre echten Daten und laufen auf jedem frischen Ubuntu.

sudo install -d -m 750 -o "$USER" -g "$USER" /srv/archiv
cd /srv/archiv
mkdir -p fotos/2019 steuer/2021
head -c 1M /dev/urandom > fotos/2019/test-001.bin
head -c 1M /dev/urandom > steuer/2021/test-002.bin

cd /srv/archiv
find . -type f ! -name SHA256SUMS ! -name '*.par2' -print0 | sort -z | xargs -0 sha256sum > SHA256SUMS
wc -l SHA256SUMS
cat SHA256SUMS

find . -type f listet jede Datei unterhalb des aktuellen Verzeichnisses. Die beiden ! -name schließen das Manifest selbst und die par2-Dateien aus. Der Ausschluss des Manifests ist kein Schönheitsfehler. Die Shell legt SHA256SUMS über die Umleitung > an, während die Pipeline startet, und beim zweiten Lauf existiert die Datei ohnehin schon. Ohne den Ausschluss würde find sie finden und sha256sum sie mit ins Manifest schreiben, und die Prüfung würde an genau dieser Zeile scheitern, weil sich der Inhalt der Datei nach dem Hashen noch ändert. -print0 und xargs -0 trennen die Pfade mit einem Nullbyte statt mit einem Zeilenumbruch, so überstehen Dateinamen mit Leerzeichen oder Umlauten die Pipe, und sort -z sortiert dazwischen mit demselben Trennzeichen. Die feste Reihenfolge macht zwei Manifeste desselben Baums zeilenweise vergleichbar. wc -l sollte 2 ausgeben, und cat zwei Zeilen mit je 64 Hex-Zeichen und einem Pfad, der mit ./ beginnt.

Das Manifest prüfen

cd /srv/archiv
sha256sum -c SHA256SUMS
echo "Exit-Code: $?"

sha256sum -c liest das Manifest, berechnet jede Prüfsumme neu und vergleicht sie mit der gespeicherten. Im gesunden Fall steht hinter jedem Pfad ein OK, und echo zeigt den Exit-Code 0. Merken Sie sich diese Ausgabe, Sie brauchen sie gleich zum Vergleich. Der Exit-Code ist die Zahl, auf die es später ankommt, weil systemd nur sie sieht.

Bei einem Archiv mit vielen tausend Dateien ist die Ausgabe zu lang, um sie zu lesen. sha256sum -c --quiet SHA256SUMS unterdrückt die OK-Zeilen und zeigt nur, was nicht passt. Das ist die Form für den Timer.

par2-Wiederherstellungsblöcke anlegen

Das Manifest sagt Ihnen, welche Datei kaputt ist. Es kann sie nicht heilen. par2 (Parity Archive Volume Set, Version 2) schließt diese Lücke. Es berechnet aus Ihren Daten Wiederherstellungsblöcke, und aus diesen Blöcken lassen sich beschädigte Teile später neu berechnen. Das Prinzip ist dasselbe wie bei RAID-Parität, nur auf Dateiebene und ohne zweite Platte.

sudo apt update && sudo apt install -y par2
cd /srv/archiv
par2 create -r10 -n1 -R fotos-2019.par2 fotos/2019
ls -l fotos-2019*.par2

-r10 erzeugt Wiederherstellungsblöcke im Umfang von 10 Prozent der Daten. Das ist der Preis: ein Ordner mit 100 GB bekommt rund 10 GB par2-Dateien dazu. -n1 legt alle Blöcke in eine einzige Wiederherstellungsdatei. -R folgt in die Unterverzeichnisse des angegebenen Ordners. ls zeigt zwei Dateien: fotos-2019.par2, die kleine Indexdatei mit den Prüfsummen aller Blöcke, und eine zweite Datei mit vol im Namen, die die eigentlichen Wiederherstellungsblöcke enthält. par2 speichert die Pfade relativ zum Verzeichnis der par2-Datei, deshalb liegt fotos-2019.par2 in /srv/archiv und nicht im Ordner selbst.

Legen Sie einen Satz pro Ordner an, nicht einen für das ganze Archiv. par2 liest beim Erzeugen jede Datei einmal komplett, und auf einer HDD mit 2 TB dauert das Stunden; ein neuer Ordner würde sonst jedes Mal einen kompletten Neulauf erzwingen. Außerdem begrenzt das par2-Format die Zahl der Blöcke pro Satz, so dass ein sehr großer Satz sehr große Blöcke bekommt, und große Blöcke machen die Reparatur grob. Für den zweiten Ordner also par2 create -r10 -n1 -R steuer-2021.par2 steuer/2021.

Eine Datei absichtlich beschädigen und reparieren

Jetzt beschädigen Sie eine Datei mit Absicht. Das ist der wichtigste Schritt, weil Sie sonst nie gesehen haben, wie ein Fehler aussieht, bevor er echt ist.

cd /srv/archiv
printf 'X' | dd of=fotos/2019/test-001.bin bs=1 seek=4096 conv=notrunc status=none
sha256sum -c SHA256SUMS
echo "Exit-Code: $?"

dd überschreibt genau ein Byte an Position 4096. conv=notrunc verhindert, dass dd den Rest der Datei abschneidet, die Dateigröße bleibt also gleich. Echter Bit-Rot, die schleichende Beschädigung durch alternde Sektoren oder einen Fehler im Controller, ändert nicht einmal das Änderungsdatum, weil kein Programm die Datei geöffnet hat. Hier tut dd das, aber die Wirkung auf den Inhalt ist dieselbe: ein anderes Byte, und kein Werkzeug ohne Prüfsumme bemerkt es. Lesen Sie jetzt die Ausgabe von sha256sum -c Zeile für Zeile und vergleichen Sie sie mit dem ersten Lauf. Sehen Sie sich die Zeile für test-001.bin an, dann die Zeile für test-002.bin, dann die letzte Zeile, und zuletzt den Exit-Code. Genau diese Stellen liest der Timer unten jeden Monat für Sie.

Die Reparatur läuft in zwei Schritten: erst prüfen, dann reparieren.

cd /srv/archiv
par2 verify fotos-2019.par2
par2 repair fotos-2019.par2
sha256sum -c SHA256SUMS
echo "Exit-Code: $?"

par2 verify prüft jede Datei des Satzes gegen die Blockprüfsummen in der Indexdatei und meldet am Ende, ob eine Reparatur nötig ist. par2 repair berechnet die beschädigten Blöcke aus den Wiederherstellungsblöcken neu und schreibt die Datei zurück. Danach muss sha256sum -c wieder für jede Zeile OK melden und den Exit-Code 0 liefern. Wenn das der Fall ist, haben Sie einmal von Anfang bis Ende gesehen, was das Archiv im Ernstfall tut. par2 repair behält die beschädigte Version unter einem neuen Namen im selben Ordner; ls fotos/2019/ zeigt sie. Löschen Sie diese Datei, sonst landet sie im nächsten Manifest.

Die Prüfung auf einen systemd-Timer legen

Ein Timer ist die systemd-Form eines Cronjobs, mit zwei Vorteilen: Persistent=true holt einen Lauf nach, den der Server wegen eines Neustarts verpasst hat, und das Ergebnis landet im Journal statt in einer Mail, die niemand liest. Wie Timer im Detail funktionieren, welche OnCalendar-Ausdrücke es gibt und wie Sie sie testen, steht in systemd-Dienste und Timer auf einem VPS. Hier reichen zwei kurze Dateien.

Die Dienstdatei /etc/systemd/system/archiv-pruefung.service:

[Unit]
Description=Archiv-Manifest pruefen

[Service]
Type=oneshot
WorkingDirectory=/srv/archiv
ExecStart=/usr/bin/sha256sum -c --quiet SHA256SUMS
Nice=19
IOSchedulingClass=idle

Die Timer-Datei /etc/systemd/system/archiv-pruefung.timer:

[Unit]
Description=Archiv-Manifest monatlich pruefen

[Timer]
OnCalendar=monthly
Persistent=true
RandomizedDelaySec=2h

[Install]
WantedBy=timers.target

Type=oneshot sagt systemd, dass der Dienst läuft, endet und dann fertig ist, statt dauerhaft im Hintergrund zu bleiben. Nice=19 und IOSchedulingClass=idle lassen die Prüfung nur dann Platte und CPU nutzen, wenn sonst niemand sie braucht, damit ein Lauf über mehrere Stunden andere Zugriffe auf die HDD nicht ausbremst. OnCalendar=monthly bedeutet den Ersten jedes Monats um Mitternacht, und RandomizedDelaySec=2h verschiebt den Start um bis zu zwei Stunden, damit nicht jeder Server auf demselben Host zur selben Sekunde die Platte belastet. Ohne User= läuft der Dienst als root, was hier unbedenklich ist, weil sha256sum -c nur liest.

sudo systemctl daemon-reload
sudo systemctl enable --now archiv-pruefung.timer
systemctl list-timers archiv-pruefung.timer
sudo systemctl start archiv-pruefung.service
systemctl status archiv-pruefung.service --no-pager

list-timers zeigt in der Spalte NEXT den nächsten Lauf. start auf den Dienst, nicht auf den Timer, löst die Prüfung sofort aus. status zeigt danach status=0/SUCCESS, wenn das Manifest stimmt. Beschädigen Sie die Testdatei noch einmal mit dem dd-Befehl von oben, starten Sie den Dienst erneut und lesen Sie status und journalctl -u archiv-pruefung.service -n 20: der Dienst steht auf failed, und im Journal stehen genau die Zeilen, die --quiet durchlässt. Reparieren Sie danach wieder mit par2 repair fotos-2019.par2.

Ein fehlgeschlagener Dienst meldet sich nicht von allein. Die billigste Lösung ist systemctl --failed einmal pro Woche beim Einloggen; der Befehl listet jeden Dienst, dessen letzter Lauf mit einem Fehler endete. Die bessere Lösung ist eine Zeile OnFailure= im [Unit]-Abschnitt des Dienstes, die einen zweiten Dienst startet, der eine Nachricht verschickt.

Neue Ordner nachtragen, und die zweite Kopie

Das Manifest jedes Mal komplett neu zu erzeugen, liest das ganze Archiv, was auf einer HDD Stunden dauert. Sobald ein neuer Ordner wie steuer/2022 hochgeladen ist, reicht es, seine Zeilen anzuhängen und einen eigenen par2-Satz anzulegen.

cd /srv/archiv
find ./steuer/2022 -type f -print0 | sort -z | xargs -0 sha256sum >> SHA256SUMS
par2 create -r10 -n1 -R steuer-2022.par2 steuer/2022

>> hängt an, statt zu überschreiben, deshalb braucht dieser Aufruf den Ausschluss des Manifests nicht. Danach gilt dieselbe Reihenfolge wie bei der ersten Befüllung: den Ordner mit Manifest und par2-Satz auf die zweite Kopie bringen, und an beiden Orten sha256sum -c laufen lassen. Der Timer findet Schäden, und par2 repariert kleine. Was beides nicht kann: eine ganze ausgefallene Platte ersetzen oder einen gelöschten Ordner zurückholen. Dafür gibt es nur die zweite Kopie.

Was dieses Archiv nicht ist

Die GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff) verlangen für steuerrelevante Geschäftsunterlagen eine revisionssichere Archivierung: Unveränderbarkeit, Nachvollziehbarkeit, Vollständigkeit und eine Verfahrensdokumentation, die ein Prüfer lesen kann. Ein Manifest, das root mit einem Befehl neu schreiben kann, erfüllt das nicht, und ein Storage-VPS, auf dem Sie selbst root sind, auch nicht. Dieses Archiv ist eine technische Absicherung gegen Bit-Rot und stille Übertragungsfehler. Es ist kein Compliance-Produkt und erhebt diesen Anspruch nicht. Wer Rechnungen und Buchungsbelege eines Unternehmens aufbewahren muss, braucht ein Dokumentenmanagementsystem, das für diesen Zweck gebaut ist, und den Rat eines Steuerberaters.

Zuletzt der Anbieter. Er hat physischen Zugriff auf die Platte, auf der Ihr Archiv liegt. Wer das nicht will, verschlüsselt vor dem Upload, und wie das mit einem Storage-VPS zusammenpasst, steht in Daten auf einem Storage-VPS verschlüsseln. Für den Workflow hier ändert sich dann eine Sache: das Manifest und die par2-Sätze gehören über die verschlüsselten Dateien, denn die liegen auf dem Server, und nur die kann der Timer dort prüfen.

FAQ

Ist ein Archiv auf einem Storage-VPS ein Backup?

Nein. Ein Archiv ist die Kopie fertiger Daten, ein Backup die Kopie von Daten, die sich noch ändern, und beides ist auf einem einzelnen Server nur eine Kopie. Ein gelöschter Ordner oder ein Plattenausfall nimmt sie mit. Das Archiv ist erst gesichert, wenn eine zweite Kopie an einem anderen Ort liegt und sha256sum -c dort dasselbe Manifest bestätigt.

Warum reicht sha256sum nicht, wozu noch par2?

sha256sum -c findet eine beschädigte Datei, kann sie aber nicht heilen. Ohne zweite Kopie ist sie verloren. par2 speichert Wiederherstellungsblöcke, aus denen par2 repair beschädigte Teile neu berechnet, solange der Schaden kleiner ist als die Redundanz. Das Manifest findet den Fehler, par2 behebt ihn, solange er klein ist.

Wie viel Redundanz soll par2 bekommen?

10 Prozent (-r10) sind für Bit-Rot mehr als genug, weil ein defekter Sektor einige Kilobyte trifft und kein Zehntel der Datei. Mehr Redundanz kostet linear mehr Platz und hilft nicht gegen den Fall, den par2 ohnehin nicht abdeckt: eine ganze tote Platte. Wer Platz sparen will, kommt mit -r5 aus. Entscheidend ist nicht die Prozentzahl, sondern dass die par2-Sätze mit auf der zweiten Kopie liegen.

Wie lange dauert das erste Hochladen von einem Terabyte?

So lange, wie Ihr Upload zu Hause erlaubt, nicht so lange, wie die Anbindung des Anbieters erlaubt. Rechnerisch sind es bei 10 Mbit/s Upload, typisch für DSL, rund 222 Stunden, bei 500 Mbit/s über Glasfaser rund 4 Stunden. Fahren Sie den Upload mit rsync --partial, dann kostet ein Verbindungsabbruch nur die angefangene Datei und nicht den ganzen Lauf.

Ist dieses Archiv revisionssicher im Sinne der GoBD?

Nein. Revisionssichere Archivierung verlangt Unveränderbarkeit und eine Verfahrensdokumentation, und beides fehlt bei einem Server, auf dem Sie selbst root sind und das Manifest jederzeit neu schreiben können. Der Workflow schützt private und technische Daten gegen Bit-Rot und stille Übertragungsfehler. Für steuerrelevante Geschäftsunterlagen brauchen Sie ein dafür gebautes Dokumentenmanagementsystem und den Rat eines Steuerberaters.