redundante usb-sticks mit zfs

Wer kennt es nicht? Ihr speichert wichtige Daten auf euren USB-Stick, steckt ihn zwei Wochen später in einen anderen Rechner und die Datei ist nicht aufzufinden. Bei Flashspeicherchips fallen gerne einmal Blöcke aus, insbesondere wenn sie unter vielen Zugriffen zu leiden haben. Es gibt zwar spezielle Dateisysteme für Flashchips, allerdings ist deren Verbereitung nicht erwähnenswert. Was kann man also machen? Man könnte ein Dateisystem mit einem Journal benutzen (ext3, xfs, jfs oder ntfs), da hat man dann zumindest eine minimale Sicherheit. Oder man entscheidet sich für einen ganz neuen Weg, dem Weg ZFS. ZFS ist ein relativ neues Dateisystem aus dem Hause SUN Microsystems und bietet eine Fülle an einzigartigen Features, diese wären z.B.:

*einfache Administrierbarkeit *hohe Datenintegrität *Raid5 odegritätsprüfung ohne das Dateisysteme ausgehangen werden müssen *Integrität wird über Checksumen geprüft (SHA-1 oder SHA-256) *die Möglichkeit Snapshots zu erzeugen (Dateisystembasierende Backups) *sehr schnelle live Komprimierung (über ZFS eigenes Verfahren oder bis hin zu gzip -9) *und und und …

Man kann nun ein USB - Stick mit ZFS betreiben, allerdings ist man da auch nicht gegen Hardwareausfälle geschützt. Wenn man also wirklich sensible Daten hat die transportiert werden sollen und man 100% sichergehen möchte das sie so ankommen wie sie gespeichert wurden, dann kann man sich einfach mittels einigen gängigen USB - Sticks und eines USB - Hubs einen Raid - Verbund bauen. Das ganze natürlich, wer hätte es gedacht, mit OpenSolaris und ZFS. Dazu natürlich noch eine Sparc Workstation oder ein x86 kompatibler Rechner.

Kostenpunkte:

*passiver USB - Hub (4 Port) - Preis: 7€ *4 x 2 Gbyte USB - Sticks - Preis pro Stick: 6€

Das macht in der Summe 31€, natürlich geht es auch nur mit 3 USB - Sticks … oder mit mehr ;). Auf meinem System läuft die Opensolaris Community Edition x86 (Build 93), allerdings wird ZFS Seit Solaris 10 unterstützt. Solaris 10 und verschiedene Opensolaris Distributionen können von der Sun Homepage kostenfrei heruntergeladen werden. ZFS befindet sich auch für andere Betriebsysteme in der Entwicklung (allerdings sind alle Implementation noch Experimentel (Stand 07/2008)), so z.B. für Linux, FreeBSD und NetBSD. Für Windows ist mir nichts bekannt und für OpenBSD wird es hoffentlich bald implementiert.

Also, fangen wir an:

Als erstes schließt man den Hub an einen freien USB 2.0 Port an, der Solaris Kernel sollte ihn ohne Probleme als solchen erkennen, eine beispielhafter Eintrag in /var/adm/messages könnte demnach so aussehen:

Jul 22 12:04:42 gorn usba: [ID 349649 kern.info]        USB2.0 Hub
Jul 22 12:04:42 gorn genunix: [ID 936769 kern.info] hubd0 is /pci@0,0/pci1043,808c@10,3/hub@2

Nun verbindet man die einzelnen USB - Sticks mit dem Hub. Sind alle USB - Sticks verbunden so kann man mittels dem Befehl rmformat die jeweiligen Gerätedateien die zu den USB - Sticks gehören identifizieren:

root@gorn:~# rmformat
...
2. Logical Node: /dev/rdsk/c3t0d0p0
Physical Node: /pci@0,0/pci1043,808c@10,3/hub@2/storage@4/disk@0,0
Connected Device: Sharkoon Flexi-Drive EC2  1100
Device Type: Removable
Bus: USB
Size: 1,9 GB
Label:
Access permissions: Medium ist nicht schreibgeschützt.
...

Uns interessiert demnach nur, dass dieser USB - Stick unter c3t0d0p0 zu finden ist, also jeweils für die einzelnen Sticks merken! In meinem Fall ganz einfach: c3t0d0p0, c4t0d0p0, c5t0d0p0 und c6t0d0p0.

Machen wir uns an das Erstellen des zPool, allerdings solle es nicht nur ein einfacher zPool sein, sondern auch Redundanz bieten. Das ist dank ZFS kein Problem, wir sagen dem Programm zpool einfach er soll uns beim Erstellen gleichzeitig ein raidz erzeugen.

root@gorn:~# zpool create -f usbpool raidz c3t0d0p0 c4t0d0p0 c5t0d0p0 c6t0d0p0

Das war es schon, der zPool ist erstellt. Wir haben jetzt eine Redundanz ähnlich Raid 5, d.h. ein kompletter USB - Stick kann ausfallen, ohne das Datenverlust entsteht. Möchte man noch weiter gehen, so kann man auch ein raidz2 erstellen, dann hat man eine Redundanz ähnlich wie Raid 6, was allerdings nur bei einer größeren Menge an Platten Sinn macht.

schauen wir uns unseren neu erstellten zPool mit raidz einmal an:

root@gorn:~# zpool status usbpool
Pool: usbpool
Status: ONLINE
scrub: Keine erforderlich
config:
NAME          STATE     READ WRITE CKSUM
usbpool       ONLINE       0     0     0
raidz1      ONLINE       0     0     0
c3t0d0p0  ONLINE       0     0     0
c4t0d0p0  ONLINE       0     0     0
c5t0d0p0  ONLINE       0     0     0
c6t0d0p0  ONLINE       0     0     0
Fehler: Keine bekannten Datenfehler
root@gorn:~# zfs list
...
usbpool                 126K  5,48G  26,9K  /usbpool

Er kann jetzt unter dem Pfad /usbpool genutzt werden. Man hat 5,5 Gbyte Speicher zur freien Verfügung und die zusätzliche Redundanz eines USB - Sticks. Es kann also irgendein Stick ausfallen und die Datenintegrität bleibt bestehen, man kann auch einen Stick hinzufügen um die Kapazität zu erhöhen.

Um die USB - Sticks vom Hub zu entfernen müssen sie zuerst ungemountet werden, dass geschieht mittels:

root@gorn:~# zpool export usbpool

Nun kann man die USB - Stick entfernen und zu einem Späteren Zeitpunkt wieder anschließen, dabei kommt es nicht auf die Reihenfolge an. ZFS sucht seine Geräte die zu dem jeweiligen Pool gehören selbst.

root@gorn:~# zpool import usbpool

Nachdem der Pool wieder importiert wurde kann man sich daran machen, die Dateisystemintegrität zu testen:

Die Datenintegrität lässt sich mit ZFS im laufenden betrieb untersuchen:

root@gorn:~# zpool scrub usbpool
root@gorn:~# zpool status
Pool: usbpool
Status: ONLINE
scrub: scrub in progress for 0h0m, 19,37% done, 0h0m to go
config:
NAME          STATE     READ WRITE CKSUM
usbpool       ONLINE       0     0     0
raidz1      ONLINE       0     0     0
c6t0d0p0  ONLINE       0     0     0
c3t0d0p0  ONLINE       0     0     0
c5t0d0p0  ONLINE       0     0     0
c4t0d0p0  ONLINE       0     0     0
Fehler: Keine bekannten Datenfehler

Man sieht hier deutlich das die Geräteadressen nun durcheinander gewürfelt sind, es ist halt egal wo man nach dem exportieren des zPools die Sticks anschließt.

Wenn man ein Stick im laufenden Betrieb entfernt, wird dies nur sichtbar wenn man scrub auf den zPool anwendet und sich danach den Status anzeigen lässt:

root@gorn:~# zpool scrub usbpool
root@gorn:~# zpool status
...
c6t0d0p0  ENTFERNT     0     0     0
...

Man kann den Stick ohne Probleme wieder anschließen und ZFS bindet ihn wieder in das bestehende raidz ein. Fällt ein USB - Stick mal aus und ein anderer wird eingesetzt, so verwendet man die Befehle “zpool clear” und “zpool replace” (mehr dazu in den Manpages).

Verwendungszweck

5,5 Gbyte hört sich nicht gerade viel an! Dem kann ich zustimmen, allerdings kann man sich mit so einem sehr günstigen Raid auch eine private Backupstrategie ausdenken. An sich passt auf dieses kleine Raid gerade so ein DVD - Image, allerdings nehmen meine E-Mails (mehrere tausend, bzip2 komprimiert) weniger als 400 Mbyte platz weg. Des weiteren könnte man alle wichtigen config - dateien aus dem home darauf sichern und wer hindert einen daran ein CVS oder ein SVN in so einem Pool zu speichern. Wenn man sowieso nur über FastEthernet zugreift können die Sticks die Leitung voll auslasten, da ja von jeweils drei USB - Sticks gleichzeitig gelesen und auf 3 gleichzeitig geschrieben werden kann (1/4 der Bandbreite sind Paritätsinformationen).

und so sieht das Ganze dann aus: