Datei nach Transfer beschädigt? So verhindern Sie Datenverlust

Dateikorrpuption nach dem Transfer ist bei modernen HTTPS-Diensten selten, weil TCP-Checksums, TLS 1.3-Integrität und AES-GCM-Authentifizierungs-Tags Bitfehler während der Übertragung zuverlässig abfangen. Wenn eine Datei dennoch beschädigt ankommt, liegt die Ursache fast immer am Endpunkt: ein unterbrochener Download, der nur eine Teildatei gespeichert hat, ein Festplattenfehler beim Schreiben oder ein Client-Bug, der Streams vorzeitig abschneidet. Berechnen Sie auf beiden Seiten einen SHA-256-Hash und vergleichen Sie. Stimmen die Hashes überein, ist die Datei identisch. Weichen sie ab, übertragen Sie erneut. Dienste mit AES-256-GCM-Verschlüsselung bieten diese Integritätsprüfung bereits eingebaut.

Warum Transfers selten in der Leitung korrumpieren

Jede HTTPS-Anfrage enthält eine TLS-Integritätsprüfung. TLS 1.3 mit AEAD-Verschlüsselung wie AES-256-GCM oder ChaCha20-Poly1305 erzeugt pro Record einen Authentifizierungs-Tag. Kippt auf der Leitung ein Bit, schlägt die Tag-Verifikation fehl, und der Record wird verworfen, bevor er die Anwendung erreicht. TCP fügt zusätzlich eine eigene 16-Bit-Prüfsumme pro Segment hinzu. Die kombinierte Wahrscheinlichkeit einer stillen Korruption, die beide Prüfungen passiert, ist verschwindend gering – bei TLS allein rund 1 zu 2^128.

Unverschlüsselte Protokolle wie FTP oder Plain-HTTP sind weniger zuverlässig. TCPs Prüfsumme übersieht manche Fehler; Bits können auf defekter Zwischenhardware mit schlechtem RAM lautlos kippen. Das ist ein echter Grund, Plain-FTP für große Transfers zu meiden – unabhängig vom offensichtlicheren Problem des Credential-Leaks.

Wo Korruption tatsächlich entsteht

Die häufigsten Ursachen für Schäden nach dem Transfer, nach Häufigkeit geordnet:

Unterbrochener Download als Teildatei gespeichert. Browser-Downloads, die bei 75 Prozent die Verbindung verlieren, speichern oft eine 75-prozentige Datei, die im Download-Ordner vollständig wirkt, aber beim Öffnen defekt ist. Chrome und Firefox kennzeichnen solche Dateien heute als .crdownload bzw. .part, ältere Versionen und manche Download-Manager jedoch nicht.

Fehler beim lokalen Festplattenschreiben. Ein defektes externes Laufwerk, eine volle Festplatte oder ein Bad Sector führt dazu, dass die Datei nur teilweise geschrieben wird. Windows meldet das nicht immer deutlich; macOS tut es gelegentlich.

Antivirenprogramm verändert die Datei. Echtzeit-AV entfernt manchmal ausführbare Abschnitte oder modifiziert Archive während des Downloads, um sie zu „desinfizieren". Die Datei ist dann technisch vorhanden, aber logisch beschädigt.

Client-Bug, der Streams abschneidet. Selten bei gut gepflegten Clients, aber manche Legacy-FTP-Clients, ältere SyncToy-Versionen oder benutzerdefinierte Upload-Skripte haben bekannte Trunkierungsfehler.

Verifizierung per SHA-256-Hash

Der einzig zuverlässige Weg, die Integrität einer übertragenen Datei zu beweisen, ist die Berechnung eines kryptografischen Hashes auf beiden Seiten und der anschließende Vergleich. SHA-256 ist universell, schnell (500 MB/s auf modernen CPUs mit AES-NI) und kollisionssicher.

macOS/Linux: shasum -a 256 datei.mov. Windows 10+: certutil -hashfile datei.mov SHA256. Beide liefern einen 64-stelligen Hex-String. Senden Sie den Hash zusammen mit dem Link – etwa „SHA256: a1b2c3..." –, damit der Empfänger nach dem Download prüfen kann.

Stimmen die Hashes überein, ist die Datei bit-für-bit identisch. Weichen sie ab, übertragen Sie erneut.

AES-GCM liefert Integrität ohne Zusatzaufwand

Dienste, die mit AES-256-GCM (Authenticated Encryption with Associated Data) verschlüsseln, betten in jeden Block einen Authentifizierungs-Tag ein. Schlägt beim Entschlüsseln die Tag-Verifikation fehl, bedeutet das, dass der Chiffretext manipuliert oder korrumpiert wurde – die Entschlüsselung bricht mit einem Fehler wie „GCM authentication failed" ab.

Gelingt die Entschlüsselung, ist die Datei garantiert unverändert. Eine separate SHA-256-Prüfung auf Empfängerseite ist nicht nötig. HexaTransfer, Smash Secure Mode, SwissTransfer, Tresorit Send und Proton Drive verwenden alle AES-GCM bzw. XChaCha20-Poly1305 aus genau diesem Grund.

Teile-Downloads erkennen

Ein klares Zeichen für einen unvollständigen Download: Die Dateigröße auf der Festplatte ist kleiner als die auf der Transferseite angezeigte Größe. Rechtsklick auf die heruntergeladene Datei, Größe prüfen, mit der vom Absender genannten Größe vergleichen. Stimmt beides nicht überein, wurde der Download nicht abgeschlossen.

Mediendateien verraten das besonders deutlich. Eine teilweise heruntergeladene MP4 spielt kurz ab und bricht dann ab. Eine teilweise heruntergeladene ZIP meldet beim Entpacken „Archiv ist beschädigt". Eine teilweise PDF zeigt die ersten Seiten und wirft dann einen Fehler. Textdateien öffnen sich oft scheinbar fehlerfrei, sind aber lautlos abgeschnitten – der schlimmste Fall, weil man es nicht sofort bemerkt.

Fortsetzbare Downloads bei instabilen Verbindungen

Verliert der Empfänger während des Downloads die Verbindung, ist Resume-Unterstützung entscheidend. HTTP Range Requests (RFC 7233) ermöglichen es einem Client, ab einem Offset fortzusetzen. curl nutzt dafür -C -, wget -c. Browser-basierte Download-Manager variieren; Firefox und Chrome setzen innerhalb derselben Sitzung fort, sofern der Server Range-Requests unterstützt.

Dienste, die nur POST ohne Range-Header einsetzen, erzwingen bei einem Verbindungsabbruch einen vollständigen Neustart – bei einer 10-GB-Datei über eine mobile Verbindung ein äußerst unangenehmes Erlebnis.

Antivirensoftware als Störquelle

Windows Defender, Avast, Bitdefender und McAfee unterbrechen Downloads gelegentlich, um Inhalte zu scannen. Meistens läuft das transparent ab. Bei Archiven oder ausführbaren Dateien entscheidet das AV manchmal, die Datei zu „bereinigen", und entfernt Inhalte oder ersetzt sie durch einen Quarantäne-Stub.

Wenn eine Datei auf dem Gerät des Empfängers konsistent beschädigt ankommt, bitten Sie ihn, den Echtzeit-AV vorübergehend zu deaktivieren und es erneut zu versuchen. Gelingt der Download dann, ist das AV der Verursacher. Fügen Sie die Domain des Transferdienstes zur AV-Ausnahmeliste hinzu.

Speicherplatz und Dateisystemfehler

Ein Download kann auch beschädigt werden, wenn die Zieldiskette während des Schreibvorgangs voll läuft. macOS schreibt über die APFS-Snapshot-Schicht und meldet Fehler in der Regel sauber. Windows NTFS neigt dazu, lautlos abzuschneiden. Prüfen Sie bei externen Laufwerken vor dem Start eines 10-GB-Downloads den verfügbaren Speicherplatz.

Dateisystem-Bugs sind selten, aber real. exFAT auf älteren Windows-Versionen hatte historisch Trunkierungsfehler bei Dateien über 4 GB. ext4, NTFS und APFS sind auf aktuellen Betriebssystemversionen zuverlässig.

Dateien mit Spezialwerkzeugen überprüfen

Videodateien: ffprobe -v error datei.mp4 meldet Fehler lautlos. Wenn die Ausgabe leer ist, ist die Container-Struktur intakt. Für eine Tiefenprüfung: ffmpeg -v error -i datei.mp4 -f null - geht durch jeden Frame und meldet Dekodierfehler.

PDFs: Adobes „Überprüfen"-Funktion prüft die Objektstruktur. qpdf --check datei.pdf macht dasselbe über die Kommandozeile.

DICOM-Medizinbilder: dcmdump datei.dcm aus DCMTK verifiziert erforderliche Tags und Struktur – relevant für PACS-Systeme in Kliniken, die ungültige Dateien ablehnen.

Archive: unzip -t datei.zip und 7z t datei.7z testen ohne zu entpacken. Schnell und erkennt die meisten Korruptionen.

Dienste mit eingebauter Integrität wählen

Für kritische Transfers empfiehlt sich ein Dienst, der kryptografische Integrität by Design bietet. Ende-zu-Ende AES-GCM-Verschlüsselung, SHA-256-Hash-Anzeige auf der Download-Seite oder explizite Prüfsummenvalidierung im Client liefern Sicherheit statt bloßes Vertrauen. HexaTransfer nutzt AES-256-GCM: Eine erfolgreiche Entschlüsselung selbst bestätigt, dass die Datei unverändert ist, und das 10-GB-Limit pro Transfer deckt die meisten professionellen Deliverables ab.

Auf hexatransfer.com testen — kostenlos, ohne Konto, bis 10 GB.