🌐 Auch auf: English · Français · Español
Über die Jahrzehnte haben sich bei mir ein paar Terabyte an persönlichen Daten angesammelt.
Vor allem Dinge wie:
- Fotos
- Musik
- Dokumente
- Videos
- Backups von irgendwelchen Projekten
Lange Zeit lag alles an einem einzigen zentralen Speicherort auf meinem NAS.
Das hat jahrelang gut funktioniert … bis zwei Probleme immer nerviger wurden:
- Backup-Dauer
- Speicherbedarf
Vor allem wenn ich das Betriebssystem meines NAS neu installieren oder austauschen musste,
konnte das Wiederherstellen des kompletten Datenbestands viele Stunden dauern.
Irgendwann wurde mir klar: Meine Datenstrategie braucht ein Umdenken 🤓
Aktive Daten von Archivdaten trennen
Mein aktuelles Setup teilt die Daten in zwei Kategorien auf.
Aktive Daten
Das sind Dateien, die ich täglich oder wöchentlich nutze.
Sie bleiben auf meinem NAS:
- Passwort-Tresor (KeePass)
- Aktuelle Dokumente
- Neuere Fotos
- Rechnungen für die nächsten Steuererklärungen
- Laufende Projekte
Weil der gesamte Datenbestand deutlich kleiner wurde, konnte ich die Speicherhardware wechseln:
Dank der geringeren Datenmenge konnte ich die bisher verwendete HDD mit hoher Kapazität durch eine deutlich schnellere SSD mit weniger Kapazität ersetzen.
Dadurch reagieren die Dateien für den Alltag spürbar flotter.
Archivdaten
Alles, was ich selten brauche, ist auf eine externe Archivplatte umgezogen.
Beispiele:
- Alte Fotos
- Alte Videos
- Abgeschlossene Projekte
- Historische Dokumente
Dieser Ansatz hat mehrere Vorteile:
- Backups sind viel schneller
- Auf dem NAS liegen deutlich weniger Dateien
- Die Hardwareanforderungen sind geringer
- Offline-Speicherung senkt das Ransomware-Risiko
Auch wenn ich das Risiko persönlich für ziemlich gering halte: Ein Offline-Datenbestand
schadet nie 🙂.
Warum viele kleine Dateien auf ext4 langsam sind
Beim Optimieren meiner Backups ist mir etwas Interessantes aufgefallen:
Viele kleine Dateien zu kopieren ist dramatisch langsamer als wenige große.
Das lässt sich leicht erklären, wenn man sich anschaut, wie ext4 funktioniert.
Jede Datei braucht einen Inode
ext4 ist ein inode-basiertes Dateisystem.
Für jede einzelne Datei muss das Dateisystem:
- einen freien Inode finden
- den Inode schreiben
- einen Verzeichniseintrag anlegen
- Datenblöcke zuweisen
- Metadaten aktualisieren
Beispiel:
1 file of 1 GB → 1 inode
100,000 files of 10 KB → 100,000 inodes
Das erzeugt eine riesige Menge an Metadaten-I/O.
Das Ergebnis:
- mehr Kopfbewegungen auf der Platte
- mehr Schreibvorgänge im Journal
- mehr Metadatenoperationen
Mit anderen Worten: Massenhaft winzige Dateien bremsen alles aus.
Die Lösung: kleine Dateien in große Archive packen
Um das Problem anzugehen, habe ich beschlossen, viele kleine Bilddateien in große Archivdateien zu bündeln.
Ich habe mir von einer KI helfen lassen, ein kleines Bash-Skript zu schreiben, das:
- meine Fotoverzeichnisse rekursiv durchsucht
- die Bilder in jedem Ordner einsammelt
- daraus eine große Archivdatei erstellt
Wichtiges Detail:
Keine Kompression.
JPEG-Bilder sind bereits komprimiert, zusätzliche Kompression ist also meist sinnlos und verschwendet nur CPU-Zyklen.
Warum ich RAR gewählt habe
Manche werden fragen: Warum ausgerechnet RAR?
Die einfache Antwort: langjährige Erfahrung.
RAR bietet ein paar Funktionen, die für Archive extrem nützlich sind:
Geteilte Archive
Überschreitet ein Archiv eine festgelegte Größe, legt RAR automatisch Volumes an:
jpg_archive.part1.rar
jpg_archive.part2.rar
jpg_archive.part3.rar
Diese Volumes gehören zusammen und lassen sich nahtlos entpacken.
Wiederherstellungsdaten
RAR kann Wiederherstellungsinformationen direkt im Archiv speichern.
Das kann helfen, Daten zu retten, wenn:
- ein Sektor auf der Platte kaputtgeht
- Bitrot auftritt
- eine Archivdatei teilweise beschädigt wird
Für Langzeitarchive ist diese Funktion Gold wert.
Der Haken an der Sache
Natürlich hat dieser Ansatz einen Nachteil.
Wenn ich auf ein einzelnes Foto zugreifen will, muss ich zuerst:
- das Archiv entpacken
- das Bild öffnen
Aber mal ehrlich:
Wie oft schaue ich mir spontan ein Foto von 2007 an?
Eben 🙂.
Backup-Strategie
Selbstverständlich ist die externe Archivplatte nicht die einzige Kopie.
Ich halte mehrere Kopien vor:
- eine lokale Backup-Platte
- eine weitere zusätzliche Kopie
- ein Offsite-Backup
Das schützt vor:
- Hardwaredefekten
- versehentlichem Löschen
- Feuer oder Diebstahl
- Bitrot
Das Bash-Skript
Hier ist das Skript, mit dem ich Bilddateien rekursiv in RAR-Archive gebündelt habe.
#!/bin/bash
# Abort immediately on any error
set -e
# Base directory
BASE_DIR="/media/user3/MASTER/daten/bilder/"
LOG_FILE="$BASE_DIR/jpg_rar_log.txt"
if [[ -z "$BASE_DIR" ]]; then
echo "Please provide the base directory as a parameter."
exit 1
fi
# Check if RAR is installed
if ! command -v rar &> /dev/null; then
echo "RAR is not installed. Please install it and try again."
exit 1
fi
# Initialize logfile
echo "=== JPG RAR Archiving Log $(date) ===" > "$LOG_FILE"
# Recursive directory traversal
find "$BASE_DIR" -type d -print0 | while IFS= read -r -d '' DIR; do
# Skip directory if RAR files already exist
if find "$DIR" -maxdepth 1 -type f -iname "*.rar" -print -quit | grep -q .; then
echo "[SKIP] '$DIR' already contains RAR files."
echo "$(date) | $DIR | SKIPPED | Reason: RAR files present" >> "$LOG_FILE"
continue
fi
# Count JPG files
JPG_COUNT=$(find "$DIR" -maxdepth 1 -type f \( -iname "*.jpg" -o -iname "*.jpeg" \) | wc -l)
if [[ "$JPG_COUNT" -le 5 ]]; then
echo "[SKIP] '$DIR' has only $JPG_COUNT JPGs."
echo "$(date) | $DIR | SKIPPED | Reason: too few JPGs ($JPG_COUNT)" >> "$LOG_FILE"
continue
fi
ARCHIVE_NAME="$DIR/jpg_archive.rar"
echo "[PROCESS] '$DIR' → '$ARCHIVE_NAME' ($JPG_COUNT JPGs)"
# Create archive (null-terminated to support special characters)
if find "$DIR" -maxdepth 1 -type f \( -iname "*.jpg" -o -iname "*.jpeg" \) -print0 | \
xargs -0 rar a -m0 -rr10p -v5000m -ep1 "$ARCHIVE_NAME"; then
# Determine archive size in MB
ARCHIVE_SIZE=$(du -m "$ARCHIVE_NAME" | cut -f1)
# Delete original files
find "$DIR" -maxdepth 1 -type f \( -iname "*.jpg" -o -iname "*.jpeg" \) -exec rm -f {} +
echo "[DONE] Archive successfully created and originals removed."
echo "$(date) | $DIR | SUCCESS | Archive: $ARCHIVE_NAME | Size: ${ARCHIVE_SIZE}MB | JPGs: $JPG_COUNT" >> "$LOG_FILE"
else
echo "[ERROR] Archiving failed, original files remain."
echo "$(date) | $DIR | ERROR | Archive: $ARCHIVE_NAME | JPGs: $JPG_COUNT" >> "$LOG_FILE"
exit 1
fi
done
echo "Finished! Logfile: $LOG_FILE"
Wichtige Warnung
⚠️ Ich übernehme keinerlei Verantwortung, wenn jemand dieses Skript verwendet.
Automatisiertes Archivieren kann bei falscher Anwendung zu Datenverlust führen.
Deshalb immer:
- zuerst mit Kopien testen
- mehrere Backups vorhalten
- die Archive überprüfen
Erst dann solltest du überlegen, so etwas auf echte Daten loszulassen.
Nächster Artikel
Nachdem der Großteil meiner Daten archiviert war, habe ich noch ein weiteres Skript geschrieben, das
automatisch alle RAR-Dateien durchsucht und ihre Integrität prüft.
Das beschreibe ich im nächsten Artikel 🙂.
