Du hast gerade eine 48-stündige Migration von 200 TB mit 50 Millionen Dateien abgeschlossen. Alles sieht gut aus — Dateianzahl stimmt, keine Fehler im Log. Aber woher weißt du, dass jede Datei intakt ist? Stiller Bit Rot, Netzwerkkorruption, Storage-Firmware-Bugs und abgebrochene Schreibvorgänge können alle Dateien produzieren, die existieren, aber falsche Daten enthalten. Checksummen sind der einzige Weg, es sicher zu wissen.
Eine Checksumme (oder Hash) ist ein Wert fester Größe, der aus dem Dateiinhalt mit einer mathematischen Funktion berechnet wird. Wenn sich auch nur ein Bit der Datei ändert, ändert sich die Checksumme komplett. Indem du Checksummen auf Quelle und Ziel berechnest und vergleichst, kannst du jede Datenkorruption erkennen.
Datei: quartalsreport.xlsx (4,2 MB)
SHA-256: a8f5f167f44f4964e6c998dee827110c...
Ein Byte ändern →
SHA-256: e3b0c44298fc1c149afbf4c8996fb924... (komplett anders)
Nicht alle Hash-Algorithmen sind gleich. Der Trade-off liegt zwischen Geschwindigkeit und Kollisionsresistenz (wie schwer es ist, zwei Dateien mit demselben Hash zu finden).
| Algorithmus | Geschwindigkeit (GB/s)* | Ausgabegröße | Kollisionsresistenz | Einsatzgebiet |
|---|---|---|---|---|
| MD5 | ~3,5 | 128 Bit | Gebrochen | Nur Legacy-Systeme |
| SHA-256 | ~1,2 | 256 Bit | Stark | Sicherheit, Compliance |
| SHA-512 | ~1,5 | 512 Bit | Stark | Hochsicherheitsumgebungen |
| XXH3 | ~30+ | 64/128 Bit | Nicht-kryptographisch | Speed-first-Integrität |
| BLAKE3 | ~8+ | 256 Bit | Stark | Moderner SHA-256-Ersatz |
*Ungefährer Single-Core-Durchsatz auf moderner x86-Hardware. Tatsächliche Geschwindigkeiten hängen von CPU, Speicher und Implementierung ab.
MD5 war jahrzehntelang der Standard für Dateiintegrität, und du findest es immer noch in vielen Tools (rsync, md5sum). Es ist schnell und erzeugt kompakte 128-Bit-Hashes. Allerdings ist MD5 kryptographisch gebrochen — es ist möglich, verschiedene Dateien mit demselben MD5-Hash zu erzeugen. Für Migrationsintegritätsprüfungen (nicht Sicherheit) ist MD5 noch funktionsfähig, aber neuere Optionen sind in jeder Hinsicht besser.
SHA-256 ist die Standardwahl, wenn Compliance oder Sicherheit eine Rolle spielen. Es gehört zur SHA-2-Familie, hat keine bekannten praktischen Angriffe und wird von vielen regulatorischen Rahmenwerken gefordert. Der Trade-off ist Geschwindigkeit — SHA-256 ist ungefähr 3x langsamer als MD5 auf derselben Hardware.
XXH3 ist ein nicht-kryptographischer Hash, der mit 30+ GB/s läuft — begrenzt durch Speicherbandbreite, nicht durch die CPU. Für Migrationsintegritätsprüfungen, bei denen du Geschwindigkeit brauchst und nicht um adversarische Kollisionsangriffe besorgt bist, ist XXH3 hervorragend.
BLAKE3 kombiniert SHA-256-Sicherheitsklasse mit nahezu XXH3-Geschwindigkeit. Es ist parallelisierbar, erzeugt 256-Bit-Hashes und wird schnell zum modernen Standard für Dateiintegrität. Wenn du einen einzelnen Algorithmus für die Integritätsverifizierung wählen musst, ist BLAKE3 schwer zu schlagen.
rsync kann mit Checksummen verifizieren, aber es ist ein separater Durchlauf:
# Erst übertragen
rsync -av /source/ /dest/
# Dann verifizieren (liest alles nochmal)
rsync -avc /source/ /dest/
Das bedeutet:
Bei einer 200-TB-Migration fügt ein separater Verifizierungsdurchlauf weitere 48 Stunden hinzu. Die meisten Admins überspringen ihn.
Robocopy hat keine eingebaute Checksummen-Funktion. Du kannst Dateigrößen und Zeitstempel vergleichen, aber die erkennen keine stille Korruption. Verifizierung hinzuzufügen bedeutet, PowerShell-Skripte mit Get-FileHash zu schreiben:
# Manuelle Verifizierung nach Robocopy
Get-ChildItem -Recurse \\dest\share | ForEach-Object {
$hash = Get-FileHash $_.FullName -Algorithm SHA256
# Mit Quelle vergleichen... irgendwie
}
Das ist langsam, fehleranfällig und skaliert nicht.
rclone unterstützt --checksum zum Vergleich, aber ähnlich wie rsync ist es ein separater Vorgang, der die I/O verdoppelt.
Der beste Ansatz für Migrationsintegrität nutzt zwei Checksummen:
Warum beide?
Stell dir das wie Versand vor
Der schnelle Hash ist wie prüfen, ob ein Paket intakt angekommen ist (schnelle Sichtprüfung). Der starke Hash ist wie das Verifizieren der Seriennummern im Inneren gegen den Lieferschein (dauert länger, ist aber rechtlich belastbar).
syncopio verfolgt einen grundlegend anderen Ansatz als CLI-Tools: Die Verifizierung findet während des Transfers statt, nicht danach.
Kein zweiter Durchlauf. Keine doppelte I/O. Keine Race Conditions.
| Ansatz | I/O-Durchläufe | Gesamtzeit (200 TB) | Integritätssicherheit |
|---|---|---|---|
| rsync (ohne Verifizierung) | 1 | ~48 Stunden | Keine |
| rsync + Checksummen-Verifizierung | 2 | ~96 Stunden | Hoch |
| Robocopy (ohne Verifizierung) | 1 | ~48 Stunden | Keine |
| syncopio (Verifizierung während des Transfers) | 1 | ~48 Stunden | Hoch |
syncopio gibt dir die gleiche Integritätsgarantie wie rsyncs Zwei-Pass-Ansatz — in der Hälfte der Zeit.
Nach dem Transfer erstellt syncopio Verifizierungsberichte, die für Compliance-Audits geeignet sind:
syncopio advantage
syncopios integrierte Verifizierung beseitigt die “Hat es wirklich korrekt kopiert?”-Angst, die jede Migration begleitet. Kein zweiter Durchlauf, keine manuellen Verifizierungsskripte, kein Hoffen auf das Beste. Alle Features ansehen oder Demo anfordern.
Unabhängig davon, welches Tool du nutzt: