Batch-Upload-Optimierung: Ordner schneller übertragen

Die schnellste Batch-Upload-Strategie: Ordner in ein einziges .zip (Store-Modus, keine Kompression) packen und ein großes Objekt statt Tausende kleiner hochladen. Ein Ordner mit 5.000 .jpg-Dateien à 500 KB ergibt zusammen 2,5 GB, dauert aber einzeln hochgeladen 10- bis 20-mal länger als ein einziges 2,5-GB-Archiv, weil jede kleine Datei den vollen TLS- und HTTP-Overhead bezahlt. Dienste mit parallelem Upload-Support (HexaTransfer, Dropbox, rclone) helfen, wenn viele Chunks groß sind. Dienste ohne Parallelismus gewinnen beim Durchsatz trotzdem, sobald Sie kleine Dateien in ein Archiv kombinieren. Dazu: Duplikate versehentlich doppelt vorhandener Dateien bereinigen, .DS_Store- und Thumbs.db-Ballast überspringen — und Sie sind in einem Bruchteil der naiven Zeit fertig.

Warum Tausende kleiner Dateien langsam sind

Jeder Datei-Upload über HTTPS trägt festen Overhead: TLS-Handshake (bei Connection-Keep-Alive wiederverwendbar), HTTP-Header (~500 Bytes), Server-Bestätigung und Disk-Flush auf der Empfangsseite. Bei einer 50-KB-Datei kann dieser Overhead die Dateigröße selbst übersteigen. Bei einer 500-KB-Datei entspricht der Overhead 10–20 % der gesamten Bytes auf der Leitung.

Multipliziert mit 5.000 Dateien haben Sie die halbe Zeit mit Metadaten statt Nutzlast verbraucht. Deshalb ist das Kopieren eines großen Ordners mit vielen kleinen Dateien auf einen externen Datenträger immer langsamer als das Kopieren eines gleichgroßen Archives.

Erst archivieren, dann hochladen

Die größte einzelne Beschleunigung für Ordner-Uploads: erst in eine .zip-, .7z- oder .tar-Datei komprimieren. Bei bereits komprimierten Inhalten (Fotos, Videos, Office-Dokumente) den Store-Modus verwenden (keine Kompression) — der Bündelungsvorteil ohne CPU-Kosten. Bei textlastigen Ordnern (Logs, Quellcode) mit Standard-Kompression echte Größeneinsparungen erzielen.

Befehle:

• macOS/Linux: zip -0 -r archive.zip ordner/ für keine Kompression; zip -r archive.zip ordner/ für Standard-Kompression.
• Windows: Rechtsklick auf Ordner → Senden an → Komprimierter (gezippter) Ordner. Oder 7-Zip mit „Zu Archiv hinzufügen" → Kompressionsstufe → Speichern.
• Große Ordner: tar -cf archive.tar ordner/ (keine Kompression) oder tar -czf archive.tar.gz ordner/ (gzip).

Vor dem Archivieren deduplizieren

Ordner sammeln über Zeit doppelte Dateien an. Designprojekte haben „final_v2.psd", „final_v2_KOPIE.psd", „final_v2_BACKUP.psd" — gleicher Inhalt, verschiedene Namen. Ein 20-GB-Ordner kann nach Deduplizierung routinemäßig auf 12 GB schrumpfen.

Tools: fdupes (Linux), rmlint (Linux/macOS), Duplicate File Finder (macOS), dupeGuru (plattformübergreifend). Die meisten arbeiten durch Hashing von Dateien und Kennzeichnung identischer Hashes. Ergebnisse überprüfen, Duplikate löschen, dann archivieren.

Für Fotografen verfolgt Lightrooms Katalog bereits eindeutige Fotos; nur markierte Auswahlen exportieren statt ganzer Aufnahme-Ordner.

Betriebssystem-Ballast überspringen

Jeder macOS-Ordner sammelt .DS_Store-Dateien (versteckte Metadaten). Jeder Windows-Ordner trägt Thumbs.db. Unter Linux erscheinen .directory-Dateien von KDE. Diese fügen für den Empfänger nichts hinzu und blähen die Archivanzahl auf.

Beim Zippen unter macOS:

zip -r archive.zip ordner/ -x "*.DS_Store" "__MACOSX"

Unter Windows über 7-Zip: Muster in der UI oder Befehlszeile mit -xr!Thumbs.db -xr!desktop.ini ausschließen. Für rsync-ähnliche Transfers: --exclude='.DS_Store' --exclude='Thumbs.db' verwenden.

Parallele Chunked-Uploads

Wenn der Dienst es unterstützt, sättigen parallele HTTP-Streams die Bandbreite, die eine einzelne TCP-Verbindung auf hochlatenten Pfaden nicht füllen kann. Das tus.io-Protokoll unterstützt das über gleichzeitige Chunk-Uploads. Clients wie die tus-js-client-Bibliothek verwenden standardmäßig eine gleichzeitige Anfrage, können aber höher konfiguriert werden.

Für kontinentübergreifende Uploads (z. B. US-Nutzer zu europäischem Dienst) verdoppelt oder verdreifacht Parallelismus den effektiven Durchsatz. Bei lokalen Uploads sättigt ein einzelner Stream die Upload-Bandbreite ohnehin, und Parallelismus bringt nichts.

Chunk-Größen-Optimierung

Große Chunks reduzieren den Overhead pro Anfrage; kleine Chunks erholen sich schneller von Netzwerkfehlern. Der Kompromiss hängt von Ihrer Verbindung ab:

| Verbindungstyp | Empfohlene Chunk-Größe | |---|---| | Gigabit-Glasfaser, kabelgebunden | 32–64 MB | | Heimglasfaser, WLAN | 10–20 MB | | Büro-Breitband | 10 MB | | Mobil 4G/5G | 2–5 MB | | Instabiles/Hotel-WLAN | 1–2 MB |

Die meisten Consumer-Dienste wählen einen vernünftigen Standard (5–10 MB) und legen die Einstellung nicht offen. Befehlszeilen-Tools (rclone, aws s3 cp, gsutil) erlauben präzise Konfiguration.

Ordnerstruktur ist weniger wichtig als das Gesamtvolumen

Ein verbreiteter Mythos: „Tief verschachtelte Ordner verlangsamen Uploads." Das stimmt nicht. Das Archivformat flacht Pfade in String-Header ab, unabhängig von der Tiefe. Ein Ordner mit 10.000 Dateien auf 3 Ebenen lädt identisch hoch wie ein Ordner mit 10.000 Dateien auf 10 Ebenen — einmal archiviert.

Was wirklich eine Rolle spielt: die Anzahl einzelner Dateien. 10.000 kleine Dateien flach ist dasselbe Problem wie 10.000 kleine Dateien verschachtelt — archivieren Sie sie.

Kompressionsstrategie nach Inhaltstyp

• Gemischte Fotos (.jpg/.heic): Store-Modus-.zip. Kein CPU-Aufwand.
• RAW-Fotos (.cr3/.arw/.nef): Store-Modus-.zip. Bereits intern komprimiert.
• Videoprojekte (.mp4, .mov, .prproj): Store-Modus-.zip.
• Quellcode: 7z mit LZMA2 für maximale Ratio.
• Log-Dateien: 7z mit LZMA2; erwarten Sie 10- bis 20-fache Reduktion.
• PDFs: Store-Modus. Die meisten PDFs haben interne Kompression.
• Gemischte Office-Docs (.docx, .xlsx): Store-Modus. Diese sind bereits intern ZIP-komprimiertes XML.
• Datenbank-Dumps (.sql): 7z mit LZMA2. Ausgezeichnete Kompression.

Hintergrund- vs. Vordergrund-Upload

Browserbasierte Uploads müssen den Tab offen halten. Das Schließen des Tabs beendet typischerweise den Upload. Manche Dienste bieten Service-Worker-gestützte Hintergrund-Uploads, die kurz nach dem Tab-Schließen weiterlaufen, aber das ist bei mobilen Browsern und einigen Unternehmens-Browser-Profilen unzuverlässig.

Für wirklich große Batch-Uploads (100+ GB) gewinnen Desktop-Clients, weil sie als Prozesse auf Betriebssystem-Ebene laufen. rclone mountet und synchronisiert auf jeden größeren Cloud-Dienst. Der Dropbox-Desktop-Client stellt Uploads zuverlässig in die Warteschlange. Diese überstehen Laptop-Lid-Closes und WLAN-Wechsel, was Browser kaum schaffen.

Für Batch-Uploads unter 10 GB verarbeitet ein moderner browserbasierter Dienst mit Chunked-Uploads über tus.io die Arbeit problemlos. HexaTransfers clientseitige Verschlüsselung fügt moderaten CPU-Overhead hinzu, beeinflusst aber den Durchsatz auf aktueller Hardware nicht nennenswert.

Überdimensionierte Batches aufteilen

Wenn Ihr Batch die Transfer-Obergrenze des Dienstes überschreitet, teilen Sie logisch statt mechanisch auf. „Fotos nach Datum"-Ordner für einen monatelangen Shoot funktionieren besser als willkürliche Byte-Splits, weil Empfänger jeden Batch überprüfen können, ob er vollständig ist („1.-7. März.zip", „8.-14. März.zip") statt sich zu fragen, ob Volume .005 fehlt.

Für Dienste ohne Transfer-Limits, aber mit Session-Limits, vermeidet das sequenzielle Hochladen mehrerer Archive das Überschreiten von Concurrent-Upload-Caps.

Vor dem Weggehen verifizieren

Große Batch-Uploads verleiten dazu, sie einfach loszuschicken und zu vergessen. Bitte nicht. Bevor Sie den Laptop schließen:

• Bestätigen Sie, dass die Upload-Seite „Abgeschlossen" und nicht „In Bearbeitung" anzeigt
• Öffnen Sie den Link in einem anderen Browser oder im Inkognito-Modus und überprüfen Sie die Empfänger-Erfahrung
• Prüfen Sie, ob das Archiv korrekt öffnet (ein beschädigtes .zip beim Upload ist selten, aber möglich)
• Bestätigen Sie, dass die Ablaufeinstellungen Ihren Vorstellungen entsprechen

Fünf Minuten Überprüfung sind besser als eine unangenehme E-Mail von morgen, die fragt, ob der Empfänger die Dateien bekommen hat.

Delta-Sync für wiederholte Batches

Wenn Sie einen Batch aktualisieren — etwa wöchentliche Backups eines Projektordners — ist das vollständige Neu-Hochladen verschwenderisch. Tools wie rclone, rsync über SSH oder dedizierte Sync-Clients übertragen nur geänderte Dateien. Das erfordert dauerhaften Speicher (keine kurzlebigen Transferdienste), ist also ein Cloud-Speicher-Muster, kein Transfer-Muster.

Für echte Transfer-Workflows, bei denen der Empfänger jedes Mal ein anderer ist, ist das vollständige Archivieren jedes Batches der richtige Ansatz.

Fazit

Der schnelle Weg für Ordner-Uploads: alles in ein .zip archivieren (Store-Modus für vorcomprimierte Inhalte, echte Kompression für Text), Betriebssystem-Ballast überspringen, wo sinnvoll deduplizieren und das einzelne Archiv über einen Dienst hochladen, der Chunked-Resumable-Uploads unterstützt. Für sehr große Batches einen Desktop-Client nutzen. Der Unterschied zwischen dem naiven „Ordner direkt hochladen" und dem optimierten Weg beträgt oft den Faktor 10 an verstrichener Zeit.

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