Du migrierst 4 TB archivierte Finanzdaten. Jede Datei ist WORM-gesperrt. Wenn du eine korrupte Datei auf das Ziel-WORM-Volume committest, kannst du sie nicht reparieren. Du kannst sie nicht löschen. Du kannst sie nicht überschreiben. Nicht bis die Aufbewahrungsfrist abläuft.
Das können sieben Jahre sein.
WORM-Migration ist nicht wie normale Dateimigration. Die Risiken sind andere. Ein falscher Schritt in der Commit-Reihenfolge und du sitzt entweder auf korrupten, unveränderlichen Daten fest — oder du hast die Chain of Custody gebrochen, die dein Compliance-Team für Audits braucht.
WORM steht für Write Once, Read Many. Sobald eine Datei auf ein WORM-Volume “committed” wurde, ist sie unveränderlich. Keine Änderungen. Kein Löschen. Die Datei liegt dort, unantastbar, bis ihre Aufbewahrungsfrist abläuft.
Das ist kein Nice-to-have. Regulatorische Rahmenwerke verlangen es:
Wenn dein Unternehmen unter eines dieser Regelwerke fällt, hast du wahrscheinlich bereits WORM-Volumes. Die Frage ist, wie du sie migrierst, ohne die Garantien zu brechen, die sie bieten.
WORM ist nicht dasselbe wie schreibgeschützte Berechtigungen
Eine Datei mit chmod 444 auf schreibgeschützt zu setzen ist kein WORM. Ein Admin kann die Berechtigungen zurückändern. Echte WORM-Durchsetzung passiert auf der Storage-Ebene, und selbst root kann sie nicht umgehen. Der Storage-Controller selbst verweigert die Änderung committeter Dateien.
Jeder NAS-Hersteller macht WORM anders. Das Konzept ist gleich, aber der Commit-Mechanismus, die Aufbewahrungsverwaltung und die administrativen Steuerungen unterscheiden sich erheblich.
NetApp SnapLock ist am weitesten verbreitet. Es gibt zwei Modi:
SnapLock committed Dateien über einen atime-basierten Mechanismus. Du schreibst die Datei, setzt dann die Access Time (atime) auf das gewünschte Aufbewahrungsdatum und änderst dann die Berechtigungen auf schreibgeschützt. Diese Reihenfolge löst den WORM-Commit aus. Die Reihenfolge ist entscheidend.
Dell EMC SmartLock (ehemals Isilon WORM) verwendet einen ähnlichen atime-basierten Commit, aber mit eigenen Retention-Clock- und Compliance-Clock-Features. SmartLock hat ebenfalls Enterprise- und Compliance-Varianten.
Synology WriteOnce ist auf neueren Synology-Modellen verfügbar. Es implementiert WORM auf Shared-Folder-Ebene mit konfigurierbaren Aufbewahrungsfristen, aber die Admin-Tools und der Commit-Ablauf unterscheiden sich von NetApp und Dell.
QNAP WORM bietet grundlegende WORM-Funktionalität auf QNAP Enterprise NAS, hauptsächlich für kleinere Deployments mit einfacheren Compliance-Anforderungen.
Commit-Mechanismen sind nicht standardisiert
Es gibt keine universelle WORM-Commit-API. NetApp verwendet atime + chmod. Dell nutzt einen ähnlichen, aber nicht identischen Ablauf. Synology und QNAP haben eigene Mechanismen. Jedes Migrationstool (oder Skript) muss die spezifische Commit-Reihenfolge sowohl für die Quell- als auch die Zielplattform verstehen.
Hier gehen die meisten WORM-Migrationen schief.
Bei einer normalen Dateimigration kopierst du die Datei und verifizierst sie. Wenn die Verifizierung fehlschlägt, löschst du die Zielkopie und versuchst es erneut. Einfach.
Mit WORM geht das nicht. Sobald eine Datei committed ist, ist sie committed. Wenn du eine korrupte Datei committed hast, ist diese korrupte Datei jetzt unveränderlich. Deine einzigen Optionen sind, auf den Ablauf der Aufbewahrungsfrist zu warten (Jahre) oder, in manchen Fällen, das gesamte Volume zu zerstören und neu aufzubauen.
Die korrekte Reihenfolge ist:
Vertausche unter keinen Umständen die Schritte 2 und 3.
Quelle (committed WORM) Ziel (neues WORM-Volume)
┌─────────────────────┐ ┌─────────────────────────────┐
│ file.pdf (locked) │ ──copy──▶│ file.pdf (uncommitted) │
│ retention: 2030 │ │ ↓ │
│ checksum: a1b2c3 │ │ verify checksum == a1b2c3 │
│ │ │ ↓ │
│ │ │ set atime → 2030 │
│ │ │ chmod → read-only │
│ │ │ file.pdf (WORM committed) │
└─────────────────────┘ └─────────────────────────────┘
Das bedeutet, dein Migrationstool muss einen Mehrphasen-Ansatz unterstützen. Es kann nicht einfach Dateien rüberballern und sie unterwegs committen. Jede Datei muss ankommen, verifiziert werden und erst dann committed werden.
Batch-Commits sind riskant
Manche Migrationsskripte committen Dateien in Batches, um Zeit zu sparen. Das bedeutet: Wenn eine Datei im Batch nach dem Commit die Verifizierung nicht besteht, hast du eine unveränderliche korrupte Datei. Committe jede Datei einzeln, direkt nach erfolgreicher Verifizierung.
Das Ziel-WORM-Volume muss die gleichen Aufbewahrungsdaten wie die Quelle einhalten. Wenn eine Datei auf der Quelle eine Aufbewahrungsfrist bis März 2030 hat, muss das Ziel dasselbe Datum durchsetzen.
Das klingt offensichtlich, scheitert aber in der Praxis aus mehreren Gründen:
Clock-Skew. WORM-Volumes nutzen eine Compliance-Clock, die von der System-Uhr abweichen kann. Wenn die Compliance-Clocks von Quelle und Ziel nicht synchronisiert sind, können Aufbewahrungsdaten driften. NetApp SnapLock hat ein ComplianceClock-Feature genau dafür. Dell hat seine eigene Retention-Clock. Die sind nicht austauschbar.
Mindest-Aufbewahrungsfristen. Manche WORM-Volumes haben eine Mindest-Aufbewahrungsfrist auf Volume-Ebene konfiguriert. Wenn das Minimum des Ziels länger ist als die verbleibende Aufbewahrung der Quelldatei, wird die Datei länger gesperrt als beabsichtigt. Technisch kein Compliance-Verstoß (du bist restriktiver, nicht weniger), aber es kann Probleme verursachen, wenn Daten planmäßig ablaufen sollen.
Cross-Vendor-Übersetzung. Der Wechsel von NetApp SnapLock zu Dell SmartLock bedeutet, Aufbewahrungs-Metadaten zwischen zwei verschiedenen Formaten zu übersetzen. Die atime-Kodierung, die Retention-Clock-Basis und der Compliance-Status müssen alle korrekt abgebildet werden. Es gibt kein Standardformat dafür.
Für Compliance-Zwecke musst du nachweisen, dass Daten während der Migration nicht manipuliert wurden. Das bedeutet einen Audit-Trail, der dokumentiert:
Dieser Audit-Trail selbst muss auf WORM oder gleichwertig manipulationssicherem Storage gespeichert werden. Wenn der Audit-Trail nachträglich bearbeitet werden kann, beweist er nichts.
Committen vor der Verifizierung. Der gefährlichste Fehler. Du sperrst ein, was du kopiert hast — inklusive Bit-Rot, abgebrochener Transfers oder Kodierungsfehler. Keine Möglichkeit, es vor Ablauf der Aufbewahrungsfrist zu korrigieren.
Verlust von Aufbewahrungs-Metadaten. Wenn dein Migrationstool keine Aufbewahrungsdaten extrahiert und erneut anwendet, bekommt jede Datei auf dem Ziel die Standard-Aufbewahrung des Volumes. Das könnte zu kurz sein (Compliance-Verstoß) oder zu lang (Daten können nicht planmäßig ablaufen).
Unterbrechung des Audit-Trails. Wenn es eine Lücke in deiner Chain-of-Custody-Dokumentation gibt, ist der gesamte Compliance-Status der Migration fragwürdig. Ein Prüfer, der fragt “Beweise, dass Datei X während der Migration nicht verändert wurde”, braucht eine klare Antwort.
Korruption auf Protokollebene. NFS und SMB behandeln große Dateien unterschiedlich. Netzwerkunterbrechungen während des Transfers können Dateien produzieren, die korrekt aussehen (gleiche Größe), aber korrupten Inhalt haben. Ohne Checksummen-Verifizierung pro Datei merkst du das erst, wenn es zu spät ist. Wenn du bereits auf WORM committed hast, ist es zu spät.
Berechtigungs- und Ownership-Abweichungen. WORM-Volumes haben oft strenge Berechtigungsanforderungen. Wenn das Ziel andere UID/GID-Mappings oder ACL-Strukturen verwendet, werden Dateien möglicherweise mit falschen Zugriffsrechten committed. Anders als bei regulären Dateien kannst du Berechtigungen einer WORM-committed Datei nicht nachträglich korrigieren.
Volume-Einstellungen stimmen nicht überein. Das Ziel-WORM-Volume braucht passende Konfiguration: Autocommit-Zeiträume, Standard-Aufbewahrung, minimale/maximale Aufbewahrungsgrenzen. Wenn Autocommit auf dem Ziel aktiviert ist und auf 30 Minuten steht, könnten deine Dateien committed werden, bevor die Verifizierung abgeschlossen ist.
Autocommit während der Migration deaktivieren
Wenn das Ziel-WORM-Volume eine Autocommit-Funktion hat, deaktiviere sie vor dem Start der Migration. Du brauchst volle Kontrolle darüber, wann Dateien committed werden. Reaktiviere sie, nachdem alle Dateien verifiziert und committed sind.
Verwende diese Checkliste vor jeder WORM-Volume-Migration.
WORM-Unterstützung in syncopio
WORM-bewusste Migration ist ein aktives Forschungs- und Entwicklungsthema für syncopio. Die Schreiben-Verifizieren-Committen-Reihenfolge, Checksummen-Verifizierung pro Datei und Audit-Trail-Generierung passen zur bestehenden Architektur von syncopio, aber volle WORM-Commit-Unterstützung über alle Hersteller hinweg ist noch nicht verfügbar. Wenn du eine WORM-Migration planst, melde dich bei uns. Dein Anwendungsfall hilft dabei, zu bestimmen, was als Nächstes gebaut wird.