Wie lange dauert ein Backup auf SSD oder HDD wirklich?

Was bestimmt die Backup-Geschwindigkeit: Quelle, Ziel, Schnittstelle und der langsamste Abschnitt

Die Dauer eines Backups ergibt sich nicht aus einer einzigen Zahl wie „Datenmenge in GB“. Entscheidend ist die gesamte Übertragungskette: Daten müssen am Quelllaufwerk gelesen, durch das Dateisystem aufbereitet, über eine Schnittstelle transportiert und am Zielmedium geschrieben werden. Jeder Abschnitt hat eine eigene Leistungsgrenze. Das Tempo des Backups fällt am Ende auf das Niveau des langsamsten Glieds zurück – selbst dann, wenn alle anderen Komponenten deutlich schneller wären.

Zusätzlich wirken Overhead und Wartezeiten: Das Betriebssystem öffnet Dateien, prüft Metadaten, erstellt Ordnerstrukturen, aktualisiert Zeitstempel und arbeitet mit Schreib-Caches. Backup-Programme berechnen je nach Einstellung Prüfsummen, komprimieren oder verschlüsseln und führen teils eine Verifikation durch. Diese Arbeiten kosten Zeit, auch wenn die reine Datenrate der Laufwerke hoch erscheint. In der Praxis ist deshalb die gefühlte Geschwindigkeit bei typischen Datenmischungen häufig deutlich niedriger als theoretische Maximalwerte.

Quelle und Ziel: Lesen und Schreiben sind nicht gleich schnell

Eine interne SSD kann Daten typischerweise sehr schnell bereitstellen, besonders bei großen, zusammenhängenden Dateien. Bei vielen kleinen Dateien sinkt die effektive Leserate jedoch, weil zahlreiche Zugriffe und Metadatenoperationen anfallen. Eine interne HDD verschärft diesen Effekt: Mechanik, Kopfbewegungen und Rotationslatenz begrenzen die Zugriffsleistung, vor allem bei zufälligen Zugriffen.

Auf der Zielseite gilt Ähnliches. Externe HDDs schreiben große Datenblöcke meist ordentlich schnell, brechen aber bei vielen kleinen Dateien stark ein. Externe SSDs sind bei zufälligen Schreibvorgängen klar im Vorteil, werden jedoch oft durch Gehäuse-Controller, die USB-Bridge und thermische Grenzen beeinflusst. Auch der freie Speicherzustand spielt mit: Stark gefüllte SSDs (wenig freier Platz/hohe interne Schreibamplifikation) oder HDDs mit ungünstiger Belegung können spürbar langsamer werden, weil mehr interne Verwaltungsarbeit anfällt.

Schnittstelle und Protokoll: USB-Standard ist nicht gleich Praxis

Die Schnittstelle setzt eine harte Obergrenze. USB 2.0 begrenzt Backups unabhängig von SSD-Tempo auf ein Niveau, das bei größeren Datenmengen schnell in Stunden kippt. USB 3.x hebt die Grenze deutlich an, aber auch hier zählen Details: Port-Implementierung, Kabelqualität, Hub-Betrieb, UASP-Unterstützung (USB Attached SCSI Protocol) und die USB-Bridge im externen Gehäuse. USB-C ist nur die Steckerform; entscheidend bleibt, ob dahinter USB 3.2 Gen 1, Gen 2, USB4/Thunderbolt oder ein anderer Modus arbeitet.

In vielen Alltagskonfigurationen wird eine externe SSD an USB 3.x nicht am SSD-Limit betrieben, sondern am Limit der USB-Bridge, des Ports oder des ausgehandelten USB-Modus. Umgekehrt kann eine externe HDD an USB 3.x selten mehr als ihre mechanische Schreibrate liefern. Daraus folgt: Der Umstieg von HDD auf SSD beschleunigt Backups besonders dann, wenn viele kleine Dateien anfallen oder wenn die Schnittstelle nicht der Engpass ist.

Dateimuster: Warum viele kleine Dateien so teuer sind

Ein Backup aus wenigen großen Video-Dateien verhält sich wie ein kontinuierlicher Datenstrom: lange, sequentielle Lese- und Schreibvorgänge, wenig Metadatenarbeit, hohe Ausnutzung der Schnittstelle. Ein Backup aus zehntausenden Fotos, Office-Dokumenten oder Projektverzeichnissen erzeugt dagegen eine Flut von Dateisystem-Operationen. Jede Datei muss gefunden, geöffnet, gelesen, geschlossen und am Ziel wieder angelegt werden. Dazu kommen Rechte, Zeitstempel und Ordnerstrukturen.

Dieser Overhead bremst unabhängig von „MB/s“-Angaben. Besonders sichtbar wird das bei HDDs, weil die Mechanik zwischen vielen kleinen Datenblöcken springen muss. Aber auch bei SSDs sinkt die Netto-Datenrate, weil ein größerer Anteil der Zeit in Verwaltung statt in Nutzdaten fließt. Backups, die nach Größe „klein“ wirken, können deshalb unerwartet lange dauern, wenn sie aus sehr vielen kleinen Dateien bestehen.

• Sequentiell (wenige große Dateien): Hohe Auslastung von Quelle, Schnittstelle und Ziel; Tempo nähert sich eher dem erreichbaren Durchsatz der Kette an.
• Random/Metadaten-lastig (viele kleine Dateien): Viele open/close-Operationen, Verzeichnisdurchläufe und Zeitstempel-Updates; effektive Datenrate sinkt deutlich, selbst bei schneller Hardware.
• Zusätzliche Verarbeitung: Prüfsummen (z. B. SHA-Checks), Kompression oder Verschlüsselung verlagern die Begrenzung teilweise auf CPU und I/O-Queue, nicht nur auf das Laufwerk.

Erst-Backup versus Folge-Backup: Vergleich kostet, Kopieren kostet auch

Das erste vollständige Backup ist meist der längste Lauf, weil sämtliche Daten erstmals übertragen werden. Folge-Backups wirken oft schneller, weil nur Änderungen kopiert werden. Allerdings entsteht dabei zusätzlicher Aufwand: Das Backup-Programm muss feststellen, welche Dateien neu oder verändert sind. Je nach Methode bedeutet das Verzeichnisvergleiche, das Prüfen von Änderungszeiten, Größen und teils das Lesen ganzer Dateien für Prüfsummen. Bei sehr großen Dateibeständen kann dieser „Scan“ mehr Zeit kosten als das anschließende Kopieren der tatsächlich geänderten Daten.

Das Verhältnis aus Scan-Zeit und Kopierzeit hängt stark vom Dateimuster ab. Ein Archiv mit wenigen großen Dateien wird schnell verglichen und bei Änderungen schnell übertragen. Ein Foto- oder Projektbestand mit sehr vielen Elementen kann dagegen auch dann lange laufen, wenn nur wenige Dateien neu hinzukommen. In solchen Szenarien ist eine scheinbar niedrige Kopiermenge kein Garant für kurze Laufzeiten; die Anzahl der Objekte ist der eigentliche Taktgeber.

Der praktische Blick: Der langsamste Abschnitt dominiert

Für realistische Erwartungen hilft ein gedanklicher Engpass-Test: Eine sehr schnelle interne SSD nützt wenig, wenn das Ziel eine externe HDD ist. Eine externe SSD nützt wenig, wenn das Backup über USB 2.0 läuft. Und selbst bei moderner Hardware kann die Backup-Software durch Prüfsummen und Dateivergleiche zum limitierenden Faktor werden, insbesondere bei vielen kleinen Dateien. In der Praxis pendeln typische Backup-Läufe daher zwischen „einige Minuten“ (kleine Änderungen, schnelle Schnittstelle, SSD-Ziel) und „mehrere Stunden“ (Erst-Backup, viele Dateien, HDD-Ziel oder langsame USB-Anbindung).

Werden große Datenmengen über Nacht eingeplant, ist das nicht automatisch ein Zeichen für schlechte Hardware; oft ist es eine Folge aus HDD-Ziel, vielen kleinen Dateien und zusätzlicher Verarbeitung. Ungewöhnlich lange Zeiten zeigen sich eher dann, wenn ein zuvor schneller Lauf plötzlich deutlich einbricht, wenn die Übertragungsrate stark schwankt oder wenn das System währenddessen regelmäßig „hängt“. In solchen Fällen liegt der Engpass häufig nicht bei der Datenmenge, sondern bei einem neuen Flaschenhals in der Kette, etwa einem Wechsel auf einen anderen Port, einem langsamen Hub/Dock, einem ungünstigen Energiesparzustand oder einem thermisch drosselnden externen Gehäuse.

Datenrealität statt Laborwerte: typische Transferraten und Zeitabschätzungen für Fotos, Dokumente und Videos

Für die Dauer eines Backups zählen am Ende nicht Datenblatt-Werte, sondern die tatsächlich erreichbare, über die gesamte Sicherung gemittelte Transferrate. Diese „effektive Geschwindigkeit“ entsteht aus dem Zusammenspiel von Quelle, Zielmedium, Anschluss, Dateistruktur und zusätzlicher Arbeit im Backup-Programm (Indexierung, Prüfsummen, Kompression, Verschlüsselung). In der Praxis liegt die Netto-Rate deshalb oft deutlich unter dem, was ein Laufwerk in einem synthetischen Sequenztest kurzzeitig erreicht.

Eine realistische Einordnung beginnt mit typischen Bandbreiten: USB 2.0 bremst unabhängig von SSD oder HDD; USB 3.x schafft deutlich mehr, wird aber häufig durch das langsamere Laufwerk oder durch viele kleine Dateien ausgebremst. Auch die Quelle kann limitieren: Eine interne HDD liefert bei langen, zusammenhängenden Transfers noch solide Werte, fällt bei stark fragmentierten Zugriffen aber schnell ab. Interne SSDs halten die Leserate meist konstant hoch, solange weder thermische Drosselung noch ein (modellabhängig) kleiner dynamischer SLC-Cache bei längeren Schreibphasen zum Engpass wird.

Typische effektive Transferraten (Netto) nach Szenario

Die folgenden Bereiche sind bewusst als Alltagsspannen formuliert. Sie setzen einen funktionierenden, nicht überlasteten Rechner voraus und beziehen sich auf den eigentlichen Nutzdatenstrom; das heißt, Protokoll-Overhead, Dateisystem-Metadaten und Backup-Verwaltungsaufwand sind bereits „eingepreist“.

Bei USB-C ist die Steckerform allein nicht aussagekräftig. Entscheidend ist der tatsächlich ausgehandelte Modus (zum Beispiel USB 3.2 Gen 1 vs. Gen 2). Kabel, Adapter, Dockingstationen und günstige Gehäuse können den Link unbemerkt auf einen langsameren Modus drücken, obwohl „USB-C“ auf allem steht.

Zeitabschätzungen für typische Datenpakete

Für eine grobe Dauerabschätzung genügt eine einfache Rechnung: Datenmenge in MB durch effektive MB/s. Da Backups selten konstant laufen, liefern Bandbreiten mit Unter- und Obergrenze die bessere Erwartung als ein Einzelwert. Für Fotosammlungen und Office-Dokumente liegt die Praxisrate oft näher am unteren Bereich, weil viele Dateien geöffnet, geprüft und angelegt werden müssen; bei großen Videodateien nähert sich die Rate eher dem Maximum des langsamsten Glieds.

• Fotosammlung (50 GB, viele JPEG/HEIC): an externer HDD über USB 3.x meist etwa 7–20 Minuten; an externer SSD über USB 3.x häufig etwa 2–10 Minuten.
• Dokumente/Projektordner (20 GB, sehr viele kleine Dateien): je nach Dateianzahl kann das an externer HDD über USB 3.x von etwa 15 Minuten bis deutlich über 1 Stunde reichen; eine externe SSD reduziert oft die Wartezeit, bleibt aber ebenfalls stark von der Dateianzahl abhängig.
• Videodateien (200 GB, wenige große Dateien): an externer HDD über USB 3.x häufig etwa 25–60 Minuten; an externer SSD über USB 3.2 Gen 2 typischerweise etwa 4–7 Minuten, bei Gen 1 eher 8–12 Minuten.
• USB 2.0 als Flaschenhals (100 GB, egal welcher Mix): in vielen Setups etwa 50–90 Minuten, selbst wenn Quelle und Ziel eigentlich schneller wären.

Diese Spannen setzen voraus, dass während des Backups keine zweite, ebenfalls stark I/O-lastige Aufgabe läuft (zusätzliche Kopiervorgänge, große Downloads, Medienbearbeitung auf dem gleichen Laufwerk). Parallelität kostet bei HDDs besonders viel, weil Kopfbewegungen und Warteschlangen die lineare Übertragung zerlegen.

Warum viele kleine Dateien den Durchsatz zerstören

Eine Datei zu kopieren bedeutet nicht nur Datenblöcke zu übertragen. Das System muss Verzeichnisse auflösen, Zugriffsrechte prüfen, Metadaten lesen und schreiben, Zeitstempel setzen und den Dateisystem-Journalbereich aktualisieren. Backup-Software legt zusätzlich Katalogeinträge an, berechnet je nach Modus Hashes oder Prüfsummen und prüft gegebenenfalls, ob eine Datei seit dem letzten Lauf verändert wurde. Diese „pro Datei“-Kosten sind nahezu konstant – unabhängig davon, ob eine Datei 4 KB oder 4 GB groß ist.

Bei HDDs kommt hinzu, dass viele kleine Dateien typischerweise über die Platte verteilt liegen. Die resultierenden Suchzeiten dominieren dann gegenüber der eigentlichen Übertragung. SSDs vermeiden mechanische Suchzeiten, verlieren aber ebenfalls Zeit durch Dateisystem- und Software-Overhead; der Einbruch ist nur weniger dramatisch.

Erstes Backup vs. Folge-Backups: warum die zweite Runde meist schneller wirkt

Das initiale Backup muss jeden Datenblock einmal lesen und schreiben. Folge-Backups sichern dagegen häufig nur Änderungen (inkrementell oder differenziell) und wirken deshalb deutlich schneller, obwohl die technische Transferrate unverändert bleibt. In der Praxis verschiebt sich der Flaschenhals: Bei kleinen Änderungsmengen dominiert nicht mehr die Schreibbandbreite, sondern das Erkennen der Änderungen. Je nach Tool kann das bedeuten, dass ein „schnelles“ Folge-Backup dennoch einige Zeit benötigt, weil es viele Dateien scannt, Metadaten vergleicht oder Snapshots verarbeitet.

Realistische Erwartungen lassen sich daher besser an der Änderungsrate festmachen als an der Gesamtdatenmenge: Ein System mit 1 TB Datenbestand kann in Minuten „fertig“ wirken, wenn nur wenige GB neu sind, während ein Fotoarchiv mit zehntausenden neuen Bildern trotz kleiner Gesamtdifferenz lange beschäftigt.

Wann Zeiten untypisch werden: Plausibilitätsgrenzen im Alltag

Extrem lange Laufzeiten sind oft kein „normaler“ Backup-Effekt, sondern ein Hinweis auf eine harte Begrenzung oder Störung. Als grobe Plausibilitätsprüfung taugt der Blick auf die Größenordnung: Große Video-Backups sollten an USB 3.x nicht „über Nacht“ laufen müssen, wenn Quelle und Ziel gesund sind. Umgekehrt sind stundenlange Backups bei sehr vielen Kleindateien nicht automatisch verdächtig, vor allem auf HDDs oder bei aktivierter Verschlüsselung und/oder Verifikation.

• Unpassende Schnittstelle: USB 2.0 oder ein auf USB 2.0 zurückgefallenes Kabel/Dock begrenzt die Praxisrate oft auf ~20–35 MB/s, unabhängig davon, ob eine schnelle SSD angeschlossen ist.
• Problematische Laufwerkszustände: auffällige Geräusche bei HDDs, wiederholte Neuverbindungen oder stark schwankende Raten können auf Lesefehler, wackelige Stecker, defekte Kabel oder ein überhitzendes Gehäuse hindeuten.
• Gleichzeitige I/O-Last: parallele Cloud-Synchronisation, Virenscans oder Medienbibliotheks-Importe können die effektive Backup-Rate massiv senken, besonders wenn Quelle und Ziel auf derselben physischen HDD liegen.
• Dateimix unterschätzt: Ordner mit sehr vielen kleinen Dateien verhalten sich eher wie „Metadatenarbeit“ als wie „Datenkopie“; 30 GB können länger dauern als 300 GB Video, obwohl weniger Daten übertragen werden.

Warum kleine Dateien und erste Backups länger dauern – und wann lange Laufzeiten ein Problem sind

Viele kleine Dateien: Warum „wenig Daten“ trotzdem viel Zeit kostet

Bei Backups zählt nicht nur die Summe der Gigabytes. Entscheidend ist, wie viele einzelne Dateien verarbeitet werden müssen. Jede Datei löst Verwaltungsarbeit aus: Dateisystem-Metadaten werden gelesen, Zugriffsrechte geprüft, Zeitstempel verglichen, der Zieldatenträger muss Verzeichnisse anlegen und Einträge schreiben. Diese Vorgänge erzeugen viele kurze, zufällige Lese- und Schreibzugriffe, die deutlich langsamer ablaufen als ein kontinuierlicher Datenstrom.

Besonders ausgeprägt ist der Effekt bei typischen Backup-Quellen wie E-Mail-Archiven, Software-Projekten, Browser-Profilen oder Foto-Programmen mit Katalogdatenbanken und Vorschauen: Hier liegen tausende bis Millionen kleiner Dateien vor, häufig in tiefen Ordnerstrukturen. Selbst eine schnelle SSD wird dann nicht durch die sequentielle Transferrate begrenzt, sondern durch Latenzen, Dateisystem-Overhead und die Zahl der I/O-Operationen pro Sekunde. Bei externen HDDs kommt hinzu, dass die Mechanik bei vielen „Sprungzugriffen“ (Seek) ausbremst.

Auch das Zielmedium spielt mit: Manche Backup-Programme schreiben zunächst temporäre Dateien, erstellen Prüfsummen oder packen Daten in Container. Das kann die Anzahl der Schreiboperationen erhöhen oder die CPU belasten. Ergebnis: Ein Ordner mit 50.000 Dateien à 20 KB kann länger dauern als ein einzelnes Video mit 50 GB, obwohl das Video die größere Datenmenge darstellt.

Warum das erste Backup fast immer deutlich länger dauert

Das erste vollständige Backup ist eine Sonderlage: Es muss jede Datei erstmals lesen, übertragen und auf dem Ziel neu anlegen. Zusätzlich entstehen beim Initiallauf häufig Nebenarbeiten, die bei späteren Sicherungen kleiner ausfallen: Kataloge werden aufgebaut, Dateilisten indiziert, Berechtigungen übernommen, gegebenenfalls werden Container-Dateien initial erstellt oder Verschlüsselungs-Header geschrieben. Je nach Software kommt Komprimierung oder Deduplizierung hinzu, was mehr CPU-Zeit benötigt und die Schreibrate drosseln kann, obwohl die Schnittstelle noch Reserven hätte.

Folge-Backups arbeiten häufig inkrementell oder differenziell. Dann werden nur neue oder geänderte Dateien kopiert. Dennoch kann auch ein Folge-Backup länger dauern als erwartet, wenn viele Dateien zwar nicht geändert, aber geprüft werden müssen. Ein reiner Zeitstempel-/Größenvergleich ist schnell, ein inhaltsbasierter Abgleich über Hashes oder Blockvergleiche kann dagegen erheblich Zeit kosten, insbesondere bei langsamen Quellmedien oder wenn die Backup-Software keine effiziente Änderungsverfolgung nutzen kann.

Realistische Richtwerte: Wann „über Nacht“ plausibel ist

Bei sehr vielen kleinen Dateien können selbst moderne Systeme deutlich unter die in Datenblättern genannten MB/s fallen. In der Praxis entscheidet die Kombination aus Dateianzahl, Quelle, Ziel, USB-Controller und Backup-Logik darüber, ob die Geschwindigkeit eher „Dateien pro Sekunde“ als „MB pro Sekunde“ entspricht. Daher helfen grobe Zeitkategorien als Plausibilitätscheck, nicht als Messwert.

• Minuten bis ~1 Stunde: Typisch für inkrementelle Backups mit überschaubar vielen Änderungen (z. B. neue Fotos, einige Dokumente) oder wenige große Dateien, sofern Quelle/Ziel und Schnittstelle nicht bremsen.
• Mehrere Stunden: Plausibel für ein erstes Vollbackup im Bereich einiger hundert Gigabyte, für Foto-/Dokument-Sammlungen mit vielen Ordnern oder wenn zusätzlich Komprimierung/Verschlüsselung aktiv ist und die CPU limitiert.
• Über Nacht: Häufig realistisch bei mehreren Terabyte, bei sehr vielen kleinen Dateien (z. B. Benutzerprofile, Entwicklungsumgebungen), bei externen HDDs oder wenn parallel andere Last anliegt (z. B. Cloud-Sync, Virenscan, laufende Updates).

Wann lange Laufzeiten auf Probleme hinweisen

Lange Zeiten sind nicht automatisch ein Fehler. Auffällig wird es, wenn die Laufzeit im Vergleich zu früher stark steigt oder wenn das Backup „hängt“: Der Fortschritt bewegt sich über längere Zeit nicht, obwohl das System ansonsten reaktionsfähig bleibt. Typische Ursachen sind instabile Verbindungen (vor allem bei USB), ein Datenträger, der wiederholt Lesefehler korrigieren muss, oder eine Backup-Software, die durch Sperren und Retries ausgebremst wird.

Bei externen Laufwerken sind USB-Kabel, Hubs und Energiesparfunktionen häufige Bremsklötze. Eine HDD kann zudem durch aggressive Stromsparmodi ständig hoch- und runterdrehen. Ebenso können Echtzeitscanner jedes neue oder geänderte Objekt prüfen; bei Millionen Dateien führt das zu massiver Zusatzlast. Bei Verschlüsselung oder Komprimierung fällt als Engpass oft die CPU auf, besonders auf älteren Notebooks, obwohl SSD und USB eigentlich schneller wären.

• Sprunghafte Einbrüche oder Pausen: Häufige Neuverbindungen, wackelige Ports/Kabel, problematische USB-Hubs oder zu geringe Stromversorgung bei 2,5″-HDDs (ohne eigene Versorgung).
• Unerwartet langsame Quelle: Eine stark gefüllte oder thermisch gedrosselte SSD, eine HDD mit vielen fragmentierten Bereichen oder ein System, das parallel stark auslagert (Swap/Pagefile) und dadurch I/O blockiert.
• Fehlerkorrektur und Retries: Wiederholtes Lesen wegen schwacher Sektoren oder Übertragungsfehler; Hinweise liefern Systemmeldungen oder SMART-Attribute. Unter Windows ist eine erste Sichtprüfung über wmic diskdrive get status möglich; für Details werden SMART-Tools benötigt.
• Blockierende Hintergrundprozesse: Echtzeitschutz, Indexierung, Cloud-Clients oder gleichzeitige Medien-Transcodes; ein Blick in die Ressourcenanzeige/Task-Manager zeigt oft hohe Datenträger- oder CPU-Auslastung während niedriger Backup-Transferrate.

Wenn ein Backup auf demselben Setup wiederholt deutlich länger benötigt als zuvor, obwohl Datenmenge und Dateistruktur ähnlich bleiben, spricht das eher für ein technisches Problem als für normale Streuung. Dann lohnt eine gezielte Kontrolle von Verbindung, Energieoptionen, freiem Speicherplatz auf dem Zielmedium sowie von Warnhinweisen zu Datenträgerzustand und Dateisystemkonsistenz.