Wer ein Backup mit einem großen ZIP- oder 7z-Archiv macht, spart Speicherplatz — bezahlt aber beim Wiederherstellen. In einem Test an einem echten Datenbestand (459.382 Dateien, 50,9 GB) war das selektive Zurückholen einzelner Dateien aus einem Content-Addressed Store 48× schneller als aus einem 7z-Archiv: 2,4 Millisekunden statt 112 Millisekunden pro Datei. Die Lehre: Deduplizieren statt in ein Archiv pressen — dann bleiben Dateien einzeln zugänglich und kommen in Millisekunden zurück.
In Teil 1 dieser Serie ging es darum, wie man beim Backup am meisten Speicher spart: nicht durch eine höhere Kompressionsstufe, sondern durch Deduplikation davor — doppelte Dateien einmal speichern statt zehnmal. Das Ergebnis war eindeutig: Deduplizieren schlägt jede Kompressionsstufe. Aber eine Frage blieb offen, und sie ist mindestens so wichtig:
Wie schnell hole ich eine einzelne Datei wieder zurück? Denn ein Backup ist nur die halbe Miete. Den Ernstfall erkennt man nicht daran, wie klein das Archiv ist, sondern daran, wie schnell die eine versehentlich gelöschte Datei wieder da ist. Genau das habe ich gemessen — und das Ergebnis hat meine Backup-Strategie umgekrempelt.
Der Denkfehler: „Hauptsache klein gepackt"
Die naheliegende Datensicherung sieht so aus: Ordner nehmen, mit 7-Zip oder ZIP in ein Archiv pressen, weglegen. Das spart Platz und fühlt sich aufgeräumt an. Der Haken zeigt sich erst, wenn man eine einzige Datei daraus braucht.
Ein Archiv ist ein einziger großer Block. Um eine verstreute Datei herauszuholen, muss das Archiv-Verzeichnis gelesen und der passende Abschnitt entpackt werden. Bei einem sogenannten Solid-Archiv (wie es 7z für gute Kompression nutzt) hängen viele Dateien in gemeinsamen Blöcken — um an eine heranzukommen, wird mehr dekomprimiert als nötig. Je größer und verstreuter das Archiv, desto langsamer der Zugriff.
Die Gegenprobe: ein Content-Addressed Store
Die Alternative kennt jeder, der schon mal mit git oder dem Backup-Tool restic gearbeitet hat: ein Content-Addressed Store (CAS). Die Idee ist simpel:
- Jede eindeutige Datei wird genau einmal gespeichert — benannt nach ihrem Inhalts-Hash (Prüfsumme).
- Ein kleines Manifest merkt sich, welcher Pfad zu welchem Hash gehört.
- Doppelte Dateien verweisen einfach auf denselben Hash — das ist die Deduplikation, eingebaut.
Eine Datei zurückzuholen ist dann kein Entpacken, sondern ein Nachschlagen plus eine Kopie: Pfad im Manifest finden, die Hash-Datei kopieren, fertig. Und genau das macht den Unterschied messbar.
Das Experiment: 25 Dateien aus 5 Ordnern zurückholen
Getestet auf einem Mac mini mit 10 Kernen, an einem realen Backup-Verzeichnis mit 459.382 Dateien und 50,9 GB. Für den Restore-Vergleich habe ich aus einer Stichprobe (3.844 Dateien, knapp 2 GB) gezielt 25 Dateien aus 5 verschiedenen Ordnern wiederhergestellt — einmal aus dem CAS-Store, einmal aus einem 7z-Archiv derselben Daten. Alle Messwerte sind real, kein Schätzwert:
| Methode | 25 Dateien | pro Datei | hochgerechnet: 1.000 Bilder |
|---|---|---|---|
| CAS-Restore (lokaler Clone) | 0,059 s | 2,4 ms | ~2,4 s |
| CAS-Restore (echte Kopie von Storage) | 0,152 s | 6,1 ms | ~6 s |
| 7z selektiv aus Archiv | 2,812 s | 112 ms | ~112 s |
Das selektive Wiederherstellen aus dem Content-Addressed Store war 48× schneller als aus dem 7z-Archiv, wenn der Store auf demselben Laufwerk liegt — und immer noch 18× schneller, wenn die Datei echt von einem externen Speicher kopiert werden muss. Alle 25 Dateien kamen bitgenau zurück (per Prüfsumme verifiziert, 25 von 25).
Hochgerechnet auf den Alltag: Wer 1.000 Bilder aus einem Backup zurückholen will, wartet beim Archiv fast zwei Minuten — beim CAS-Store wenige Sekunden.
Warum der Unterschied so groß ist
Der Schlüssel ist die Unabhängigkeit von der Archivgröße. Eine Datei aus dem CAS-Store zu holen kostet immer gleich viel — egal, ob der Store 2 GB oder 2 TB groß ist. Es ist ein Manifest-Lookup und ein File-Copy, mehr nicht. Auf einem modernen Dateisystem wie APFS auf dem Mac ist diese Kopie sogar fast gratis, weil das System die Datei klont (cp -c), statt sie physisch zu duplizieren.
Ein Archiv dagegen skaliert gegen dich: Je mehr drinsteckt und je verstreuter die gesuchten Dateien liegen, desto mehr muss gelesen und dekomprimiert werden. Was beim Packen ein Vorteil ist (alles in einem Block, gute Kompression), wird beim gezielten Zugriff zur Bremse.
Die eigentliche Erkenntnis: die zweigeteilte Architektur
Hier wird es für jeden interessant, der viele Fotos, Dokumente oder Mediendateien sichert. Aus dem CAS-Prinzip ergibt sich eine Aufteilung, die ein einzelnes ZIP- oder 7z-Archiv prinzipbedingt nicht kann:
| Schicht | Größe (Hochrechnung) | Liegt wo |
|---|---|---|
| Original-Dateien (dedupliziert) | 27,7 GB | kalt auf großem Speicher (NAS / Cloud) |
| Manifest (Pfad → Hash) | ~50 MB | lokal, immer dabei |
| Vorschau-Bilder (Thumbnails) | ~2,3 GB | lokal auf Laptop / iPad |
Die Vorschau-Schicht aus Manifest und Thumbnails ist mit rund 2,4 GB winzig — sie passt locker aufs MacBook oder iPad. Die vollen Originale (27,7 GB nach Deduplikation, von ursprünglich 50,9 GB) liegen kalt auf großem Speicher. Das Ergebnis: Man sieht alle Dateien als Vorschau, lädt aber nur die wenigen Originale zurück, die man tatsächlich braucht — in Millisekunden. Ein Archiv zwingt dich zur Alles-oder-nichts-Entscheidung; diese Architektur nicht.
Genau dieses Modell steckt hinter ArchivBlick, meinem Werkzeug für große Foto- und Dokumentenarchive: kleine Vorschau lokal, Originale kalt, Zugriff in Millisekunden. (Transparenzhinweis: ArchivBlick ist ein eigenes, selbstfinanziertes Projekt — kein bezahlter Beitrag.)
Was heißt das für deine Datensicherung?
Die praktische Lehre aus beiden Teilen dieser Backup-Serie lässt sich in drei Sätzen zusammenfassen:
- Zuerst deduplizieren, nicht packen. Doppelte Dateien zu entfernen sparte in diesem Bestand 23,2 GB (45 %) — fast doppelt so viel wie das Packen des ganzen Ordners mit 7z (12 GB / 24 %).
- Komprimieren nur, wo es sich lohnt. Text und Logdateien schrumpfen stark; bereits komprimierte Daten wie JPGs oder MP4s holen selbst auf höchster Stufe kaum etwas heraus.
- Für Wiederherstellung zählt der Zugriff, nicht die Archivgröße. Ein Content-Addressed Store hält Dateien einzeln zugänglich und liefert sie in Millisekunden. Ein ZIP- oder 7z-Archiv lohnt nur als Cold Storage — etwas, das man komplett weglegt und im Ganzen wieder herausholt.
Wer also ein Backup nicht nur anlegen, sondern im Ernstfall auch schnell wiederherstellen will, sollte ZIP und 7z bewusst dort einsetzen, wo sie stark sind — beim kalten Wegpacken großer Textmengen — und für alles, worauf man wieder gezielt zugreifen will, auf Deduplikation und einen inhaltsadressierten Speicher setzen. Hätte ich das vor Jahren gewusst, hätte ich mir viel Wartezeit beim Wiederherstellen gespart.
Datengrundlage und Methodik
Alle Zahlen in diesem Artikel sind eigene Messungen vom 24.06.2026, keine übernommenen Fremdangaben und keine Schätzwerte. Gemessen wurde auf einem Mac mini mit 10 Kernen an einem produktiven Datenbestand:
- Datenbestand: 459.382 Dateien, 50,9 GB. Deduplikation per Prüfsumme über alle gleich großen Dateien; verbleibend 27,7 GB.
- Restore-Vergleich: 25 Dateien aus 5 verschiedenen Ordnern, gezogen aus einer Stichprobe von 3.844 Dateien (knapp 2 GB). Dieselben Daten einmal als Content-Addressed Store, einmal als 7z-Archiv.
- Integrität: alle 25 wiederhergestellten Dateien per Prüfsumme gegen das Original geprüft, 25 von 25 bitgenau. Keine Datei wurde dabei verändert.
- Hochrechnungen (Spalte „1.000 Bilder" sowie die Größenangaben der Vorschau-Schicht) sind als solche gekennzeichnet und linear aus den gemessenen Werten pro Datei abgeleitet.
Die Messwerte gelten für diesen Datenbestand auf dieser Hardware. Auf rotierenden Festplatten, bei anderer Dateigrößen-Verteilung oder über ein Netzlaufwerk fallen die absoluten Zeiten anders aus — das Verhältnis zwischen beiden Verfahren bleibt in seiner Richtung bestehen, weil es an der Funktionsweise hängt und nicht an der Geschwindigkeit des Speichers.
Transparenz & Haftung: Dieser Beitrag ist unabhängig und selbstfinanziert und enthält keine Affiliate-Links; die genannten Werkzeuge wurden weder gesponsert noch haben sie für die Nennung bezahlt. Der Artikel wurde mit KI-Unterstützung (Claude) recherchiert und geschrieben; die genannten Zahlen stammen aus den oben dokumentierten eigenen Messungen, die redaktionelle Verantwortung liegt bei Marco Fuhrmann. Alle Angaben ohne Gewähr — Messwerte hängen von Hardware und Datenbestand ab und lassen sich nicht ungeprüft übertragen. Dieser Artikel beschreibt meine persönliche Vorgehensweise und ersetzt keine auf deine Situation zugeschnittene Backup-Beratung.