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.