Bitrot schummelt Fehler leise ins Dateisystem

Unter Bitrot bezeichnet man umgangssprachlich das „Kippen“ einzelner Datenbits. Dies kann etwa bei Zahlen schnell dramatische Folgen hervorrufen: Habt ihr etwa 100 Euro auf dem Konto (Binär: 1100100) und das erste Bit kippt in der Datenbank der Bank zu einer 0, dann schrumpft euer Guthaben auf einen Schlag auf nur noch 36 Euro (Binär: 0100100). Damit dies nicht passiert, speichern moderne Dateisysteme Daten redundant und schreiben Prüfsummen, sodass man zum einen merkt, dass etwas mit den Daten nicht stimmt und zum anderen sie auch automatisch wiederherstellen kann. Auch Dateiformate selber besitzen eine gewisse Redundanz, sodass kleine Datenfehler im Bild eigentlich kaum ersichtlich sein sollten. Daher hat mich dieser Beitrag von Ars Technica sehr gewundet. Schon nach drei gekippten Bits ist das dort gezeigte Bild nicht mehr erkennbar. Gut, nach 10 gekippten Bits bin ich auch nicht mehr wiederzuerkennen, aber der Totalausfall nach 3 gedrehten Bits macht einem schon Sorgen — schließlich gehören Bilder für viele von uns zum wertvollsten Datenschatz.

Um das Thema also einmal selber nachzustellen, braucht es ein Bild und ein kleines Programm, mit dem man gezielt einzelne Bits einer Datei umkippen lassen kann. Im Netz finden sich dazu eine Reihe von kleinen Code-Schnippseln, der folgende in Python geschriebene Code macht als bitflip.ph abgespeichert genau dies. Als Parameter übergebt ihr den Programm einen Offsetwert, also im Endeffekt das wie vielte Bit es drehen soll. Zudem habe ich mit bitflip.sh ein kleines Shell-Skript geschrieben, das automatisiert eine beliebige Anzahl an Bits einer Datei drehen kann. Es nummeriert zudem die einzelnen Bilder und erstellt am Ende aus den Einzelbildern ein Video — mit dem Ziel am Ende den Verfall des Bildes als animierten Verlauf zu sehen.

Skripte zum automatisierten Drehen einzelner Bits

bitflip.ph

#!/usr/bin/python
"""Toggle the bit at the specified offset.
Syntax:  filename bit-offset"""

import sys
fname = sys.argv[1]
# Convert bit offset to bytes + leftover bits
bitpos = int(sys.argv[2])
nbytes, nbits = divmod(bitpos, 8)

# Open in read+write, binary mode; read 1 byte 
fp = open(fname, "r+b")
fp.seek(nbytes, 0)
c = fp.read(1)

# Toggle bit at byte position `nbits`
toggled = bytes( [ ord(c)^(1<<nbits) ] ) 
# print(toggled) # diagnostic output

# Back up one byte, write out the modified byte
fp.seek(-1, 1)  # or absolute: fp.seek(nbytes, 0)
fp.write(toggled)
fp.close()

bitflip.sh

#!/bin/bash
# Settings
ORIGFILE=$1
FIRSTBIT=$2
LASTBIT=$3
STEPWIDTH=$4

# Folders
FLIPPEDFILES=tmp_flipped
VIDEOTEMP=tmp_video

# Init
FLIPPEDBITS=0

# Watch for Ctrl+C
trap "exit" INT

# Prepare
if [[ ! -e $FLIPPEDFILES ]]; then
	mkdir $FLIPPEDFILES
else
	rm $FLIPPEDFILES/*
fi

if [[ ! -e $VIDEOTEMP ]]; then
	mkdir $VIDEOTEMP
else
	rm $VIDEOTEMP/*
fi

# Function annotate
function annotate () {
	convert $1/$2.jpg -gravity southeast \
		-stroke '#000C' -pointsize 100   -strokewidth 2 -annotate 0 $3 \
		-stroke  none   -pointsize 100   -fill white    -annotate 0 $3 \
		$1/$2.jpg
}

# Flip bits
cp $ORIGFILE $FLIPPEDFILES/$FIRSTBIT.jpg
convert $ORIGFILE $FLIPPEDFILES/$FIRSTBIT.jpg +append $VIDEOTEMP/$FIRSTBIT.jpg

while [  $FIRSTBIT -lt $LASTBIT ]; do

	echo Flipping bit: $FIRSTBIT
	echo Flipped bits: $FLIPPEDBITS

	let PLUSONE=FIRSTBIT+STEPWIDTH
	cp $FLIPPEDFILES/$FIRSTBIT.jpg $FLIPPEDFILES/$PLUSONE.jpg
	./bitflip.py $FLIPPEDFILES/$PLUSONE.jpg $PLUSONE
	convert $FLIPPEDFILES/$FIRSTBIT.jpg $FLIPPEDFILES/$PLUSONE.jpg +append $VIDEOTEMP/$PLUSONE.jpg
	annotate $VIDEOTEMP $PLUSONE $FLIPPEDBITS

	let FIRSTBIT=FIRSTBIT+STEPWIDTH
	let FLIPPEDBITS=FLIPPEDBITS+1
	clear
done

# Build video
cd $VIDEOTEMP
cat *.jpg | ffmpeg -y -f image2pipe -r 15 -vcodec mjpeg -i - -vcodec libx264 ../out.mp4

Doch bevor ich das Skript auf ein JPG loslasse, muss bitflip.ph beweisen, ob es auch wirklich funktioniert. Dazu nehme ich ein beliebiges PNG-Bild und flippe gezielt ein einzelnes Bit. Ein binärer Verglich mit cmp zeigt dann den Unterschied. Der Aufruf von file erkennt anschließend zwar noch eine PNG-Datei, doch ein Bildbetrachter mag die Datei nicht mehr öffnen, wie auch identify aus der Imagemagick-Suite einen mit IDAT: CRC error einen Fehler in der Bilddatei meldet. Schalte ich das Bit erneut um, dann akzeptiert identify das Bild wieder brav und der Bildbetrachter von Gnome öffnet die PNG-Datei ebenfalls wieder. Sum­ma sum­ma­rum: Schon ein gekipptes Bit kann eine Datei komplett runinieren. JPG bringt jedoch deutlich mehr Redundanzen mit, von daher bin ich gespannt, wie sich das für Fotografien übliche Dateiformat schlägt.

### Beliebige PNG-Datei kopieren
$ cp picture.png picture-flip.png
### Als Beispiel das 2000. Bit flippen
$ ./bitflip.py picture-flip.png 2000
### Hat es geklappt, ja!
$ cmp -l picture.png picture-flip.png | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}'
000000FB 1C 1D

### Immer noch eine PNG-Datei?
$ file picture-flip.png
picture-flip.png: PNG image data, 800 x 533, 8-bit/color RGB, non-interlaced
### Bild-Information kaputt
$ identify -verbose picture-flip.png
identify: IDAT: CRC error `picture-flip.png' @ error/png.c/MagickPNGErrorHandler/1630.
identify: corrupt image `picture-flip.png' @ error/png.c/ReadPNGImage/3959.

### Gegenprüfung, wieder das 2000. Bit flippen
$ ./bitflip.py picture-flip.png 2000
### Bild-Informationen stimmen wieder
$ identify -verbose picture-flip.png
Image: picture-flip.png
  Format: PNG (Portable Network Graphics)
  Mime type: image/png
  Class: DirectClass
  Geometry: 800x533+0+0
  Resolution: 28.35x28.35

Bei Ars schildert Autor Jim Salter nun, dass es schon mit einem geflippten Bit im JPG-Bild Artefakte erscheinen. Nach zwei und erst recht nach drei gekippten Bits ist dann kaum mehr etwas von dem Originalbild zu erkennen. In meinen Tests kann ich das nun aber nicht nachvollziehen: Mein Testbild bleibt ein Bild und für das Auge ergibt sich kein erkennbarer Unterschied, nur cmp meldet (wie gewünscht) die Anzahl der Unterschiede in den jeweiligen Dateien. Ich habe den Vergleich bewusst auf eine „richtige“ Fotografie beschränkt und nicht auf eine künstlich kleine JPG-Datei, da natürlich die Redundanz mit der Größe des Bildes zunimmt. 1000 gekippte Bits in einer 1 Kb großen Datei dürften sich deutlich dramatischer Auswirken als in einer 5 Mb großen Datei, frisch von der Digitalkamera geladen.

Mit 10 gekippten Bits

$ cmp -l ../katze_orig.jpg 11000.jpg | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}' | wc -l
10

Mit 100 gekippten Bits

$ cmp -l ../katze_orig.jpg 20100.jpg | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}' | wc -l
100

Mit knapp 1000 gekippten Bits

$ cmp -l ../katze_orig.jpg 110000.jpg | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}' | wc -l
999

Lange Rede, kurzer Sinn: Ganz so schlimm wie der Autor von Ars darstellt, wirkt sich Bitrot bei JPEG-Dateien nicht aus. Dennoch sollte man sich bei seiner Backupstrategie ein wenig Gedanken an die Tatsache verschwenden, dass einzelne Bits auf dem Datenträger kippen können. Sichert man nun einfach nur Stumpf seine Daten auf ein Backup-Medium, dann wandert der Defekt unbemerkt ins Backup und ersetzt auch irgendwann mal die älteste Version in der Sicherung, sodass eine Wiederherstellung zu einem späteren Zeitpunkt unmöglich wird. Dazu gehören moderne Dateisysteme, die Prüfsummen wie Btrfs oder ZFS für alle Daten anlegen (nicht nur wie Ext4 für das Journal) und am besten darunter noch ein RAID1, sodass man Daten leicht wiederherstellen kann.

Btrfs gibt es als Dateisystem schon seit mehreren Jahren im Linux-Kernel, openSUSE setzt etwa seit Version 13.2 als Standard auf Btrfs als Dateisystem. Eine Spezialität des jungen Dateisystems liegt darin Copy-On-Write zu unterstützen. So lassen sich Daten kopieren, ohne dass zusätzlicher Speicherplatz benötigt wird. Erst wenn sich eine der beiden Kopien ändert, wird diese auch auf die Festplatte geschrieben — und zwar auch nur der Speicherblock, der die Änderung enthält. Dies eignet sich daher ideal für Snapshots von Datenpartition, da sich zahlreiche Snapshots erstellen lassen, ohne dass man viel Speicher verbrät. Zahlreiche weitere Informationen zu Btrfs und dem Umgang mit dem Dateisystem in einem Linux-System finden sich inzwischen zum Beispiel im Wiki von Ubuntuusers.

Diskstation auf Btrfs-Snapshots umrüsten

Für mich war es daher einer der Kriterien auf eine Diskstation DS216+ umzusteigen — andere NAS-Hersteller wie QNAP etwa unterstützen Btrfs allerdings selbstverständlich auch, ich bin allerdings jedoch schon ein wenig länger mit Synology-Geräten unterwegs, daher bleibe ich in der Syno-Community. Für die Umrüstung einer Diskstation auf Btrfs muss man nun leider die Datenpartition einmal löschen und wieder neu aufsetzen. Dazu gilt es zuallererst ein Backup eurer Daten zu erstellen, dann im Speicher-Manager das gewünschte Volume zu löschen und es anschließend gleich wieder mit Btrfs als Dateisystem wieder neu aufzusetzen.

Beim Anlegen der neuen gemeinsamen Ordner auf dem Volume unter Systemsteuerung | Gemeinsame Ordner achtet ihr am besten gleich zusätzlich darauf, dass im Reiter Erweitert die Option Erweiterten Datenintegritätsschutz aktiviert ist — was bei einem Btrfs-Volumen eigentlich von Haus aus der Fall sein sollte. Die Option sorgt dafür, dass Btrfs Prüfsummen erstellt und ihr im Falle von Bitrot die betroffenen Daten wiederherstellen könnt. Bei Bitrot treten schleichend und bitweise Fehler in den Daten auf, ohne dass das System diese tatsächlich als Fehler interpretiert. Nachträglich lässt sich diese Option, genauso wie die in Btrfs integrierte Dateikomprimierung, nicht mehr de-/aktivieren. Überlegt euch also schon im vorhinein genau, was dieser Ordner können soll.

Btrfs-Snapshots aktivieren und Zeitplan erstellen

Für die Snapshots müsst ihr nun die Erweiterung Schnappschuss & Replikation aus dem Paketzentrum installieren und diese dann anschließend aus dem Anwendungsmenü heraus öffnen. Für jeden gemeinsamen Ordner lässt sich dort dann im Reiter Schnappschüsse in den Eigenschaften ein Zeitplan bestimmen, der regelt wie oft das System einen Snapshot archiviert. Da bei Btrfs-Snapshots nur die zwischenzeitlich angelaufenen Änderungen als zusätzliche Datenmenge entstehen, könnt die Snapshots durchaus recht häufig erstellen lassen, ohne dass die Festplatte vollläuft. Im Reiter Aufbewahrung könnt ihr zudem dann noch festlegen, wie lange das System die einzelnen Snapshots archivieren soll. Danach gilt es abzuwarten, bis die Snapshot-Funktion das erste mal zuschlägt, alternativ könnt ihr mit Einen Schnappschuss machen manuell einen Snapshot auslösen.

Zugriff geht auch über den Dateimanager

Der Vorteil der Btrfs-Snapshots liegt nun darin, dass ihr über einen ganz normalen Dateimanager Zugriff auf die Sicherungen erhaltet. Im Stammordner eines jeden gemeinsamen Ordners des Systems (bei dem ihr die Snapshot-Funktion aktiviert habt) erscheint ein Verzeichnis mit der Bezeichnung #snapshots — unter Windows ist dies mit einem Kamera-Icon hervorgehoben. In diesem findet ihr die bisher angelaufenen Sicherungen; in diesen dann direkt den Stand eurer Daten zum Zeitpunkt der Sicherung. Löscht ihr also nun mal eine Datei oder ein Verzeichnis aus Versehen oder seid ihr mit einer Änderung an einem Dokument unzufrieden und möchtet einen älteren Stand wiederherstellen, dann müsst ihr einfach nur die #Snapshots ansteuern und die verbastelte Datei mit der gewünschten Version überschreiben.

Im Großen und Ganzen deckt man so mit Btrfs und einem RAID 1 schon zahlreiche Szenarien ab. Fällt eine der Platten aus, ist auf der zweiten alles gespielt. Also einfach die defekte Platte ausbauen, eine neue einsetzen und das System das RAID wiederherstellen lassen. Die Snapshots decken jetzt die Fälle ab, bei denen man als User zu dumm war: Also versehentliches Löschen und Änderungen an Daten, die man später bereut. Hängt man nun noch in regelmäßig Abständen eine externe Festplatte an das NAS und lässt eine „richtige“ Sicherung erstellen, ist man auch vor Komplettausfällen des NAS-Geräts abgesichert.

Gegen Bitrot sichern die Btrfs-Snapshots noch nicht

Einzig gegen den vorhin angesprochenen „Bitrot“ oder besser die Silent Data Corruption ist die Synology-Lösung noch nicht das Wahre. Dies liegt nicht an Btrfs selber, sondern an der Art und Weise wie Synology den Speicher organisiert: Bei einem klassischen Software-RAID (Mdadm-RAID) übernimmt das System die Daten von dem Speichermedium, das sich als Erstes meldet. Btrfs wählt hingegen nun aber die Quelle aus, bei der auch die Prüfsumme der ausgelieferten Daten stimmt (deswegen müsst ihr wie oben beschrieben die Option Erweiterten Datenintegritätsschutz aktivieren). Von Bitrot beschädigte Daten fallen dann sofort auf, so dass das System sie theoretisch automatisch mit jenen aus dem intakten Datenbereich ersetzen kann.

Synology legt nun aber unter das Btrfs-RAID ein LVM, wodurch diese automatische Korrektur nicht mehr möglich ist. Das System erkennt nun zwar eine Datei mit defekten Bits, da die Prüfsummen nicht stimmen. Es kann den Schaden aber nicht mehr automatisch reparieren, da es nicht weiß, von welcher Platte die defekten Daten stammen — Ich muss das Szenario noch austesten, aktuell habe ich hier keine Festplatten übrig. Im Forum von Synology gibt es zu diesem Thema eine ausführliche Diskussion, und auch Synology musste schon Marketingmaterial ändern, weil die die Implementation von Btrfs seitens Synology diesen Schutz nicht bietet. Vielleicht ist das auch ein Grund, warum Synology DSM 6.0 bisher noch nicht offiziell an den Start gebracht hat.

Interessant sind aber nicht nur die nackten Zahlen, sondern auch die Frage, ob es sich lohnt teure Enterprise-Platten zu kaufen oder auf deutlich günstigere Desktop-Festplatten zu setzen — Vergleichbare Enterprise-Modelle kosten gerne mehr als dopp elt so viel. Für einen Speicheranbieter wie Backblaze macht es nach eigenen Aussahen wirtschaftlich keinen Sinn die teuren Enterprise-Festplatten zu nutzen. Selbst wenn 15% aller Desktop-Platten jährlich ausfallen und sämtliche Enterprise-Platten fehlerfrei ihren Dienst tun würden, wäre der Breakeven erst nach 10 Jahren erreicht. Kaum eine Festplatte wird allerdings so lange in den Racks des Dienstes seine Runden drehen, da aktuelle Modelle aufgrund ihrer höheren Speicherdichte deutlich wirtschaftlicher arbeiten.

Für uns kleine NAS-Betreiber stellt sich allerdings eher die Frage nach der Datensicherheit. Da Backblaze seine Daten redundant speichert, dürfen gerne einmal ein paar Festplatten ausfallen. Es muss einfach nur die Platte in das Rach geschoben werden und gut ist — das kostet nur ein wenig Zeit und damit Geld. Spendiert man seinem NAS allerdings ein RAID mit redundanter Datenverteilung, dann kommt man in den selben Luxus. Wie sind denn eure Erfahrungen in der letzten Zeit. Mein letzter Plattencrash ist einige Jahre her und meine Desktop-Rechner und Notebooks sind inzwischen dank SSDs nicht mehr ganz so empfindlich gegenüber spontanen Abstürzen — bildlich gesprochen.

Das Backup über ADB ist seit Android „Ice Cream Sandwich“ 4.0 möglich, alles was Ihr dazu braucht ist ein Rechner mit dem Android-SDK und ein USB-Kabel. Unter Linux installiere ich das SDK am liebsten über ein kleines Install-Skript, dass das Entwickler-Toolkit für Android aus dem Netz holt und unter Debian und Ubuntu ordentlich im System verankert, so erspart man sich den einen oder andere Ärger bei der Nutzung des SDKs. Unter Windows läuft das SDK auch, eine schnelle Suche im Netz sollte euch zum Ziel führen, der Rest hier ist systemübergreifend gültig.

Nach der Installation des SDK solltet ihr kurz überprüfen, ob euer Handy vom ADB-Server auch gefunden wird. Schaltet dazu in den Einstellungen des Handys unter Einstellungen | Entwickleroptionen den USB-Debuggingmodus ein und verbindet dann euer Android-Gerät per USB-Kabel mit dem PC. Im oberen linken Eck sollte jetzt ein kleines Android-Symbol erscheinen, dass der USB-Debuggingmodus aktiv ist. Ein Aufruf des ADB-Servers sollte auch zeigen, dass euer Handy korrekt gefunden wurde.

$ adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
0146970C0601500A        device

Für das eigentliche Backup gibt es nun eine Reihe von Optionen, die man ab- oder anschalten kann. Ihr habt die Wahl zwischen dem Sichern oder Übergehen eurer Apps (Standard ist das Übergehen), dem Sichern der Daten auf der SD-Speicherkarte/Datenpartition (Standard ist Übergehen) und dem Sichern der Einstellungen der System-Apps (Von Haus aus aktiv), die Hilfe gibt euch ausführliche Infos zu jeder der Optionen.

## Bei mir liegt adb nicht im System-Pfad, daher muss ich erstmal in das
## Verzeichnis wechseln
$ cd /usr/local/android-sdk/platform-tools/
$ ./adb help
...
adb backup [-f ] [-apk|-noapk] [-shared|-noshared] [-all] [-system|-nosystem] []
- write an archive of the devices data to .
If no -f option is supplied then the data is written
to "backup.ab" in the current directory.
(-apk|-noapk enable/disable backup of the .apks themselves
in the archive; the default is noapk.)
(-shared|-noshared enable/disable backup of the device's
shared storage / SD card contents; the default is noshared.)
(-all means to back up all installed applications)
(-system|-nosystem toggles whether -all automatically includes
system applications; the default is to include system apps)
( is the list of applications to be backed up. If
the -all or -shared flags are passed, then the package
list is optional. Applications explicitly given on the
command line will be included even if -nosystem would
ordinarily cause them to be omitted.)

Ich persönlich habe mein System die letzten Tage mit allem drum und dran sichern lassen, so dass das Backup letztendlich über 10 GByte groß wurde. Ich kann nicht klagen, aber es hat enorm lange gedauert. Leider hatte ich vergessen die Dauer zu notieren, aber sowohl das Sichern wie auch das Wiederherstellen der Daten hat locker den halben Tag gedauert.

Während der Laufzeit des Backups könnt ihr euer Handy benutzen, allerdings solltet Ihr es nicht vom USB-Kabel trennen, sonst geht der ganze Klimmbimm wieder von vorne los. Folgende Befehle hatte ich genutzt, um mein Backup zu erstellen und dann nach dem Rooten wieder einzuspielen.

## Backup mit allem drum und dran erstellen
$ ./adb backup -apk -shared -all -f backup_$(date +%d%m%Y).ab
## Backup wiederherstellen
$ ./adb restore backup_datum.ab

Etwas ärgerlich ist, dass man während des Backups bzw. dem Wiederherstellen keinerlei Feedback bekommt, wie weit nun das Backup voran geschritten ist. Beim Erzeugen des Backups könnt Ihr über die Dateigröße der Backup-Datei recht einfach prüfen, was gerade läuft. Wächst sie noch, und ist das Terminal nicht schon in die nächste Zeile gesprungen, dann läuft das Backup noch. Beim Wiederherstellen schaut ihr euch am besten das logcat über ddms an, dort seht Ihr im Detail was gerade auf dem Handy passiert.

In meinem Selbstversuch war das Backup absolut zuverlässig. Ich habe mein Stock-Galaxy-Nexus gesichert, es gerootet, Jelly Bean installiert und dann das Backup zurückgespielt. Von den System-Einstellungen, über meine installierten Apps und deren Einstellungen, bis hin zu all meinen Bildern, Videos und MP3s wurde alles automatisch wiedergergestellt. Es dauert ewig – gerade wenn man eben den Inhalt der SD-Karte mitsichert – doch das Backup nimmt einem viel Arbeit ab.

[UPDATE 22.08.2012] Bei Android-Hilfe.de finden sich noch ein paar Infos über das hier hier beschriebene Backup über die Android Debug Bridge. SMS werden wohl nie gespeichert und das Wiederherstellen von Widgets geht wohl auch ab und an schief. Bei mir hatte es unter ICS geklappt, auf einem Nexus 7 Tablet mit Android „Jelly Bean“ 4.1 allerdings nicht mehr. SMS könnt Ihr mit SMS Backup&Restore oder SMS Backup+ sichern, bei Widgets helfen zur Not Screenshots der Homescreens. [/UPDATE]

Wie angesprochen kann man über den Befehl dpkg die installierten Pakete ausgeben lassen. Mit ein bisschen Shell-Magie kann man aus dieser Liste eine Datei erzeugen, die sich dann auf einem anderen Rechner dazu verwenden lässt, die selben Pakete zu installieren. Im Endeffekt läuft das das Ganze so ab…

# Paketliste auf Rechner A erstellen...
$ dpkg --get-selections | awk '!/deinstall|purge|hold/ {print $1}' > packages.list
# Pakete aus der Liste auf Rechner B installieren
$ xargs -a "packages.list" sudo apt-get install

Nun funktioniert dieses Vorgehen leider nur solange, wie die Liste der verfügbaren Pakete in den Paketquellen identisch ist. Referenziert die Liste auf ein Paket, das manuell installiert wurde oder auf ein Paket aus einer zusätzlichen Paketquelle, so muss diese erst über die /etc/apt/sources.list bzw. über add-apt-repository hinzugefügt werden. Manuell installierte Pakete müsste man sogar von Hand aus der Liste löschen.

Hier kommt nun das Programm apt-clone ins Spiel. Dieses sichert nicht nur eine Paketliste, sondern speichert auch auch die sources.list inkl. weiterer in /etc/apt/sources.list.d/ abgelegten Quellen und erzeugt sogar aus manuell installierten Programmen wieder installierbare Pakete. So kann man in der Tat das komplette System klonen, ohne dass man groß Aufwand treiben muss. Einzig Konfigurationsdateien aus /etc werden bislang nicht mitgesichert, so dass man Dienste erneut konfigurieren muss, doch daran arbeitet man aktuell auch noch.

Wenn Ihr das Ganze ausprobieren wollt, dann müsst Ihr erst einmal apt-clone auf beiden Rechnern installieren. Das Paket gibt es jedoch nur seit Ubuntu Natty 11.04, ältere Ubuntu-Versionen lassen sich daher auf diesen bequemen Weg nicht clonen…

$ sudo apt-get install apt-clone

Danach müsst ihr auf dem fertig eingerichteten System apt-clone ausführen. Die Option  clone --width-dpkg-repack sorgt dafür, dass von Hand installierte Pakete wieder erneut verpackt werden, so dass Ihr sie auf dem zweiten System wieder erneut installieren könnt. Bei mir schmeißt das Ganze ein paar Fehlermeldungen aus, die jedoch keine Auswirkungen hatten.

$ sudo apt-clone clone --with-dpkg-repack /
dpkg-deb: warning: './dpkg-repack-7727/DEBIAN/control' contains user-defined field 'Original-Maintainer'
dpkg-deb: warning: ignoring 1 warning about the control file(s)

dpkg-deb: building package `libxapian15' in `./libxapian15_1.0.20-2_amd64.deb'.
dpkg-deb: building package `teamviewer6' in `./teamviewer6_6.0.9224_amd64.deb'.
dpkg-deb: building package `openshot-doc' in `./openshot-doc_1.3.0-maverick1_all.deb'.
dpkg-deb: warning: './dpkg-repack-8460/DEBIAN/control' contains user-defined field 'Python-Version'
dpkg-deb: warning: ignoring 1 warning about the control file(s)

dpkg-deb: building package `arte+7recorder-5' in `./arte+7recorder-5_5.0.beta3~ppa3~maverick_all.deb'.
dpkg-deb: warning: './dpkg-repack-8498/DEBIAN/control' contains user-defined field 'Original-Maintainer'
dpkg-deb: warning: ignoring 1 warning about the control file(s)
...

Danach findet ihr im Wurzelverzeichnis / eine Datei mit dem Namen apt-clone-state-rechnername.tar.gz, in dieser stecken nun die gesammelten Informationen. Habt ihr keine Pakete manuell installiert, so ist sie nur ein paar KB groß. Sollten jedoch Programme wie Skype, Teamviewer und Co. manuell über .deb Dateien installiert worden sein, so wird diese Sicherung natürlich recht schnell aufgeblasen.

Packt die Datei nun auf einen USB-Stick oder schiebt sie über das Netzwerk auf eurer zweiten Rechner und startet auf dem zweiten Rechner ebenfalls apt-clone. Diesmal übergebt ihr mit restore die Option, dass die Paketinformationen aus dem Archiv wiederhergestellt werden sollen.

$ sudo apt-clone restore apt-clone-state-rechnername.tar.gz

Je nachdem wie viele Pakete gefehlt haben, wird nun die Paketverwaltung eine Weile lang beschäftigt sein, da ich auf meinem Testsystem bspw. eine komplette Latex-Umgebung installiert hatte, wird diese nun auch auf dem geclonten System installiert usw…

Damit Ihr nicht völlig unnötige Pakete installieren lässt, würde ich vorher auf dem zu klonenden System etwas aufräumen. Schmeißt dazu am besten Synaptic oder das Software-Center an und schaut was ihr nicht wirklich braucht. Räumt dann noch mit…

$ sudo apt-get autoremove

…nicht mehr benötigte Pakete runter und entfernt am besten noch bei den nicht mehr benötigte Kernel, die sammeln sich recht gerne an und brauchen viel Platz. Schau euch dazu am besten mal den Beitrag alte Kernel inkl. Header mit nur einem Befehl entfernen an. Mit einem Kommando räumt ihr alle alten Kernels vom System.

Getestet habe ich das alles mit meiner „normalen“ Natty-Installation unter einem 64-Bit Ubuntu und einer 32-Bit Installation in einer VirtualBox. Selbst bei diesem Sprung von 32- auf 64-Bit ging alles klar. Alles in allem ist apt-clone für alle ein tolles Werkzeug, die ihr System neu einrichten wollen.

Redo Backup and Recovery baut dabei auf die koreanische Linux-Distribution xPUD auf (weitere Infos zu xPUD bei heise). Diese Distribution basiert auf einer Browser-gestützten Oberfläche names Plate und versucht zum einen leichtgewichtig zu sein und zum anderen soll sie einfach zu bedienen sein. In Redo Backup and Recovery wurde die Oberfläche von xPUD zum großen Teil übernommen, so kann man aus Redo heraus einen Browser starten und/oder sogar Software wie OpenOffice.org, zusätzliche Treiber oder sogar auch Skype nachinstallieren.

So lässt sich das System nicht nur zur Rettung benutzen, über das Netz kann man somit auch Hilfe bei Freunden oder Communities holen. Bei Bedarf gibt es auch die Möglichkeit Redo auf einem USB-Stick zu installieren, so dass Änderungen erhalten bleiben.

Das Erstellen von Images übernimmt Partclone zu dem von Redo eine Oberfläche entwickelt wurde. Sollte man nur einzelne Dateien vom beschädigten System brauchen, dann ist von Haus aus der PCMan File Manager als Dateimanager mit an Bord. Redo Backup and Recovery steht unter der GNU GPL Lizenz und ist über die Homepage als rund 75MB große .iso-Datei herunterladbar.