Arch Linux Tux

[ENC]BladeXP's Blog

Was die Welt nicht alles braucht!

Disk Images platzsparend archivieren

2016-11-12 15:00 | Kategorien: arch debian linux opensource software ubuntu windows

Windows ist bei mir vor allem ein Zweitsystem, es dient für Steam zum Spielen und für Lightroom um meine Fotos zu bearbeiten. Das alte Windows 7 wollte seinerzeit durch Windows 10 ersetzt werden, denn der aktuelle PC soll noch länger genutzt werden als es der Service für Windows 7 gestattet.

Ein wichtiger Aspekt für große Veränderungen an einem System ist natürlich das Backup, während die Mediendaten, welche ich nutze entweder auf dem Homeserver liegen (Fotos) oder aus der Cloud kommen (Steam) ist das Betriebssystem als solches bei mir nicht im Backupkonzept vorgesehen. Zu groß der Platzverbrauch, zu gering der Profit.

Die einfachste Möglichkeit eine komplette Festplatte 1:1 zu sichern ist ein Disk Image, doch dafür benötigt man Platz mit der gleichen Größe, wie die Quelle von welcher man ein solches erstellen möchte. Die Nutzung einer Festplatte ist aber in der Regel kleiner, meist sogar deutlich, als die tatsächlich vorhandene Kapazität eben dieser. Die Idee ist daher mit möglichst geringem Aufwand, möglichst viel Platz zu sparen.

Windows verkleinern

Zuerst kann man, sofern Windows auf der Quelle ist, die Auslagerungsdateien und die Hibernation Files zu deaktivieren, das allein spart in der Regel schon deutlich Platz. Der nächste Schritt ist die obligatorische und großzügige Datenträgerbereinigung mit dem gleichnamigen Tool.

Jetzt kommt das Wichtigste: Das überschreiben der nicht vom Betriebssystem benötigen Blöcke im Dateisystem mit nullen. Der Hintergrund liegt in der Struktur moderner Betriebssysteme versteckt, den dort werden Dateien und dementsprechend auch Blöcke auf dem Datenträger, nicht mehr gelöscht, sondern lediglich als frei markiert. Ein Verhalten, das gut für die Geschwindigkeit und eventuell erforderliche Wiederherstellungsmaßnahmen ist, aber sehr schlecht um davon ein Image zu machen.

Um zuvor genanntes Problem zu umgehen, kann man sich das Tool sdelete herunterladen, und anschließend in einer Befehlszeile mit Administratorrechten ausführen: sdelete.exe -z c:. Dieser Prozess dauert je nach Geschwindigkeit des zugrunde liegenden Datenträgers etwas. Nach Abschluss sollte man das Betriebssystem herunterfahren und in sein Lieblingslinux booten.

Möglichkeiten

In meinem Fall waren nach dieser Aktion noch ca. 96GiB Nutzdaten (inkl. Betriebssystem) vorhanden, auf einem Datenträger mit einer Kapazität von 250GB. Die Frage, die sich mir nun stellte, war, wie viel Platz benötige ich tatsächlich um die Bruttodatenmenge, also die Kapazität vom Datenträger, als Image zu sichern. Zur Auswahl standen für mich dabei 2 Verfahren:

Nun stelle sich für mich die alles entscheidende Frage: Was ist der Größen und Zeitunterschied zwischen Sparse File mit dd_rescue und lzop?

Sparse File

Mit dem Befehl dd_rescue -a -d -b 32M /dev/sdb sdb_backup.img erzeugte ich zuvor genanntes Sparse File, basierend auf dem Block Device /dev/sdb. Der gesamte Vorgang dauert bei meinem System 9 Minuten und 12 Sekunden, je nach Kombination aus HDD/SSD dauert dies mehr oder weniger lang. Das Ergebnis ist eine Datei die zwar mit 239GiB angegeben ist, aber nur 145 GiB auf dem Datenträger verbraucht:

[root@pc2007:/srv] 21s $ ls -l -h -s
145G -rw-r----- 1 root   root  239G 17. Jun 16:53 sdb_backup.img

LZO Compression

Der nächste Versuch war es mittels lzop < /dev/sdb > sdb_backup.image.lzo ein LZO Komprimiertes Images zu erzeugen. Dieses mal dauerte der Vorgang 10 Minuten und 7 Sekunden, ein marginaler Unterschied, wenn man bedenkt, dass noch eine Kompression der Daten durchgeführt wird. Das Ergebnis in diesem Fall ist eine Datei welche 107 GiB groß ist, also ca. 26% weniger Platz im Vergleich zum Sparse File benötigt:
[stefan:~] 10m32s $ ls -l -h -s /srv/sdb_backup.image.lzo 
107G -rw-r--r-- 1 root root 107G 17. Jun 17:17 /srv/sdb_backup.image.lzo

Fazit

Als kurzes Fazit lässt sich sagen das sich die Kompression mit lzop bewährt hat, vor allem weil ein derartiges Image auch auf Dateisysteme kopiert werden kann, die nicht Sparse fähig sind. Für mein neu geplantes Backup Konzept werde ich einen weiteren Blick auf die Kompression mittels LZO und LZ4 werfen, doch dazu später mehr. Mit anderen Kompressionsmöglichkeiten kann zweifelsfrei eine noch kleinere Datei (Image) erzeugt werden, der Zeitaufwand darf hierbei jedoch nicht unterschätzt werden.