Schlagwörter

, ,

Mein Home-Office Arbeitsplatz besteht aus einem Mac- und einer Solaris-Kiste. Die Kombination, die sich bei mir seit Jahren zur einzig wahren und sehr produktiven durchsetzte. Heute geht es mal ausschließlich um den Solaris-Rechner. Genauer: es geht um wichtige Projekte und Daten die sich auf ihr befinden.

Nennt mich paranoid, aber ich vertraue den drehenden Festplatten in dem Dell nicht im geringsten. Mir geht es demnach darum, gegen Festplatten-Ausfall gewappnet zu sein. Dabei verzichte ich auf die Einhaltung der Backupprinzipien. Um ein Außerhaus-Backup muss ich mich die Tage noch separat kümmern. Mir ist zunächst wichtig darauf vertrauen zu können, das das was in meinem /data/Project Ordner liegt auch gesichert zu haben wenn die Festplatte ihren Geist aufgibt.

Da auf diesem Rechner die Master-Sourcen inclusive Repository und der erste stage des Build-Servers liegt ist die Angelegenheit besonders brenzlig.

Ich möchte die Platten nicht spiegeln, da im Rechner kein Platz mehr ist und externe Platten nochmals Strom benötigen. Ich kann es zuhause so schon kaum begründen, warum ein Build-Server unbedingt Continuos sein muss…

Meine Idee ist es zwei USB-Sticks als Mirror an den Rechner zu hängen. USB-Ports hat der Rechner genügend und bei 32GB für 15 Euro kann man nichts falsch machen. Da (Paranoia) USB-Sticks nun nicht der sicherste Aufbewahrungsort ist, kommen eben zwei hinten rein, die über das OS gespiegelt werden: ZFS macht es möglich!

In den Artikel zeige ich die Schritte, die nötig sind um ein lokales Backup auf zwei bespiegelte USB-Sticks unter Solaris oder BSD mit ZFS zu bringen.

Zunächst stecke ich beide Sticks in den Rechner und formatiere beide nach einander mit GParted auf “unformatted” um die üblichen vorformatiertem FAT Partitionen der Sticks zu löschen.

Nun ist ein bisschen Konsolenarbeit nötig. Keine Angst – tut nicht weh!

Zunächst muss ein neuer ZPool angelegt werden. Ein ZPool ist eine Einheit in der verschiedene Platten oder Speichermedien zusammengefasst werden können. Im ZPool wird beschreiben, wie diese Medien zusammenhängen. Es ist zum Beispiel möglich zwei Festplatten hintereinander zu schalten, so dass daraus logisch eine große wird. Es ist auch möglich in einem ZPool zwei oder mehr Speichermedien in einem RAID-Verbund zu verknüpfen, oder mehrere RAIDs zu verbinden, bzw. Mehrere Plattenverbindungen als RAID-konoten anzusehen. Ich glaube für mehr Infos hilft es im Netz zu suchen.

Ein ZPool ist eine logische Einheit von Festplatten. Wenn man es nach Schichten betrachtet, ist ein ZPool die erste Abstraktion nach dem physikalischen Gerät.

Für die beiden neuen Sticks möchte ich nun eben diese neue Einheit bilden und beide Sticks in einem Mirrorverbund verknüpfen. Sollte ein Stick ein paar Daten verlieren, so werden diese on thy fly vom anderen Stick ersetzt.

Um ein neuen ZPool mit beiden Sticks im Mirror zu erstellen benötigt man folgenden Befahl als Superuser:

zpool create <name_des_pools> mirror <device_1> <device_2>

Ich nenne mein ZPool “backup”

Ein “zpool list” zeigt alle Pools und die sich darin befindenden Geräte an:

Nun existiert ein ZPool, aber noch keine Möglichkeit diesen zu verwenden. Es wird noch ein ZFS Eintrag benötigt. Es ist nicht ganz leicht dieses Konzept zu erklären, da es so offensichtlich für jemanden ist, der länger mit ZFS gearbeitet hat. Wenn man neu an das Filesystem kommt sollte man zunächst verstehen, das ZPools und Einträge im ZFS erstmal nichts mit Verzeichnissen zu tun haben. Verzeichnisse sind nur für den Menschen und seinen Ordnungswahn gut – und ZFS unterstützt diesen, indem er die Daten und die Draufsicht über Verzeichnisse erst einmal konsequent trennt!

Die Speichergeräte werden in ZPools verwaltet. Ein ZPool kann mehrere Einträge besitzen. Jeder Eintrag kann unterschiedliche Einstellungen haben. Man kann einen Eintrag zum Beispiel eine bestimmte Maximalgröße (Quota) geben, oder alle Daten in dem Eintrag komprimieren. Es gibt eine Vielzahl nützlicher Eigenschaften, die man einem Eintrag mitgeben kann. Einer dieser Einträge ist jedoch auch der Mountpoint. Dieser gibt an unter welchem Verzeichnis der Eintrag angesprochen werden soll.

In meinem Fall möchte ich erstmal keine besonderen Einstellungen an meinem Backup vornehmen. Es soll nicht komprimiert und auch nicht gededuped werden. Es soll nicht über Samba oder nfs freigegeben werden, es soll auch nicht verschlüsselt werden. u.s.w. (Für mehr Information ist die Dokumentation von ZFS und ZPool hilfreich.)

in meinem ZPool “backup” lege ich einen Eintrag “Projects” an und möchte diesen über das Verzeichnis /data/backup/Projects ansprechen.

Als Superuser erzeugt man einen neuen Eintrag mit

zfs create <eigenschaften> <zpool>/<eintrag>

Für meinen Fall lege ich drei Einträge an, die ich alle in ein Oberverzeichnis mounte.

Projects, User und Zones. Alle werden in in /data/backup unter gleichen Namen wie der ZFS Eintrag gemountet. So halte ich eine bessere Übersicht. Bei anderen habe ich jedoch auch schon gesehen, das die Namen sich unterscheiden.

Um die Liste der Einträge zu sehen benutzt man den Befehl list

zfs list

Solaris-backup-1 und solaris-backup-1/var gehören nicht dazu und sind Einträge von einem boot-environment (Erklärt) namens backup-1. *ignore*

In “backup/Projects” werde ich alle aktuell aus dem Subversion ausgecheckten Projekte die sich in meinem /data/Projects Ordner befinden speichern. In “backup/User” die Benutzerverzeichnisse und in “backup/Zones” werde ich die Solaris-Container die sich auf dem Systembefinden speichern. In den Containern liegt zum Beispiel das System des Build-Servers, Ein Development-Webserver, ein Pre-Stage-Server und noch weitere abgeschirmte Systeme die ich für meine Projekte benötige. Über Container und die sinnvolle Aufteilung kann ich bei Interesse noch separat berichten. (Kommentar unter den Post zeigt Interesse)

Um nun die Daten auch zu sichern habe ich mich für das gute alte rsync entschieden. Zunächst Speicher ich alle Daten aus /data/Project in das Backup-Verzeichnis.

rsync -av /data/Projects/* /data/backup/Projects

Und das selbe habe ich dann mit den Homeverzeichnissen getan. Um einen korrekten Backup der Zonen kümmere ich mich später, da diese eine besondere Strategie benötigen.

ZFS bildet Prüfsummen für jedes File und kann anhand dieser  feststellen, ob das File unbeschädigt und intakt ist. Bei Plattenspiegelung kann ZFS feststellen, welche der Kopien die unbeschädigte ist.

Im Gegensatz zu den alten Verfahren des Mirroring, wo nur sichergestellt werden kann, das die beiden Spiegel physikalisch mit den gleichen Daten versehen sind, ergibt das Verfahren über die Prüfsummen eine erheblich erhöhte Datensicherheit.

Um sicher zu stellen, das die Daten auf beiden Spiegeln intakt sind, gibt es den Befehl “scrub”. Um initial sicherzugehen, das beide Sticks die selben intakten Daten haben kann man nun einmal “scrub” ausführen. Später kann man dies hin und wieder tun und sich mit Status die Ergebnisse anzeigen lassen.

Als Superuser gibt man für das scubben folgenden Befehl ein:

zpool scrub <poolname>

Im oberen Teil beim “backup”-ZPool kann man sehen, das das scubben noch in Arbeit ist. 1.72% sind bereis bearbeitet. Der rpool wurde bereits geprüft und der Test hat 0 Fehler ergeben.

Um nun ein kontinuierliches Backup zu haben möchte ich jede Stunde die Unterschiede von meinem Project-Verzeichnis auf den Stick kopieren. Dazu erstelle ich zunächst ein kleines Batch-Script welches ich dann in die Crontab des Systems lege. Jede Stunde speichert der Rechner still und heimlich die Daten auf den Stick. Da rsync nur die Unterschiedlichen Daten speichert geht das sehr schnell.

Mit “crontab -e” kann man die Cron-Tabelle bearbeiten, hier kommt bei einem Backup zu jeder Vollen Stunde folgende Zeile hin:

0 * * * * /path/to/backup.sh

Nicht nur das der bespiegelte Backup auf USB-Stick schön Nerdig ist, ich fühle mich nachdem das nun einige Tage schon so läuft viel sicherer.