Alle Beiträge von Kamil Günay

Homeserver 25: Sind wirklich keine Daten verlorengegangen?

War der Ausfall des RAIDs letztens jetzt eigentlich folgenlos? Sind meine Daten evtl. in Mitleidenschaft gezogen worden? Diese Fragen kann ich mit einem definitiven “Ich habe keine Ahnung!” beantworten. :-) Denn ein Kommentar von Stefan Jansen in meinem vorigen Artikel brachte mich zum Nachdenken. Zum Einen, ob der Ausfall wirklich folgenlos war, und zum Anderen, wie ich das denn jetzt überprüfen kann. Also habe ich den Browser meiner Wahl geöffnet, paar Stichworte in die Suchmaschine meiner Wahl eingegeben und eine ganze Weile gelesen.

Der einfachste Weg, zu prüfen, ob die Datenintegrität noch da ist, sind Hashes. Ein Hash ist eine Prüfsumme, an der man sehen kann, ob Daten verändert wurden. Wer genaueres wissen möchte, kann sich den Wikipedia-Artikel zu Prüfsummen durchlesen.

Damit ich also Prüfsummen erstellen kann, und diese auch gegenprüfen kann, muss ich diverse Tools haben. Meine Wahl fiel auf MD5Deep, weil dieses wirklich für alle relevanten Betriebssysteme vorhanden ist und identisch bedient wird. So muss ich nicht für jedes System ein neues Tool haben. Aber auch wenn es “MD5Deep” heißt, es ist eine Sammlung von Programmen, die mit allen möglichen Hash-Funktionen umgehen kann.

Hashwerte für mein Datenbackup erstellen

Dieser Schritt ist nur dieses Mal nötig, weil ja noch keine Hashes von intakten Daten existieren. Später werden die Daten direkt auf dem RAID gehashed.

Um also zu gucken, ob die Daten auf dem RAID noch in Ordnung sind, muss ich ja erst mal Hashes von Daten haben, von denen ich weiß, dass sie in Ordnung sind. Also muss erst mal ein Hashset von meinem Datenbackup erstellt werden. Dieses liegt auf mehreren externen Festplatten, die auch unter Windows lesbar sind.

Zunächst muss ich mir MD5Deep für Windows von der MD5Deep Homepage herunterladen. Die Datei packe ich aus. Hier sind viele Dateien drin, vor allem auch für die diversen Hash-Typen. Mich interessiert zunächst aber nur die Datei hashdeep64.exe, weil ich ein Windows 7 64 Bit nutze. Diese kopiere ich in ein Verzeichnis, von dem aus ich dieses Programm leicht aufrufen kann.

Nun muss ich von meinem Backup Hashes erstellen. Um dies zu tun, muss ich das für jede externe platte tun, auf der Backupdaten liegen. Da ich eine Festplatten-Dockingstation habe, ist das Wechseln von Platten denkbar einfach, einfach senkrecht reinstellen… :-)

Meine externe Platte lässt sich über den Laufwerksbuchstaben G: ansprechen. Die Backups liegen in exakt der Verzeichnisstruktur auf der Platte, wie sie auch auf dem RAID liegen.

Nun stelle ich also die erste Platte ins Dock, schalte sie ein und dann starte ich das Hash-Programm von der Kommandozeile. Der Befehl sieht so aus:

hashdeep64 -re -j1 g:\daten >>known.txt
  • hashdeep64: Das Programm.
  • -re: Diese Parameter hashen die Daten rekursiv, also alle Dateien aller Unterverzeichnisse. Und es wird die zu erwartende Dauer bei großen Dateien angezeigt.
  • -j1: Verwendet nur einen CPU-Kern. Sonst werden 4 Operationen gleichzeitig gemacht. Ich habe ja eine Quadcore-CPU in meinem Rechner, also ein Thread pro CPU-Kern. Das mag bei internen Platten oder RAIDs kein Problem sein, aber bei externen Platten, auch wenn es USB 3.0 ist, verlangsamt das den Prozess fast auf die doppelte Länge.
  • g:\daten: Da liegt mein Backup.
  • >>known.txt: Leitet die Ausgabe der Hashes in diese Datei um.

Diese Datei wird später noch wichtig, denn hier sind die bekannten Hashwerte drin, gegen die die Daten auf dem RAID geprüft werden sollen. Und warum habe ich zwei Größerzeichen verwendet? Weil dieser Befehl nach und nach mit allen Backupplatten ausgeführt werden soll. Die neuen Hashes sollen an die Datei angefügt werden. Würde da nur ein Größerzeichn stehen, würde die Datei bei jeder Ausführung überschrieben werden.

Jede Datei, auch große Videos, MP3s und Bilder, wird jetzt gehashed und dessen Hashwert in der Datei gespeichert. Da dies für alle Backupplatten gemacht werden muss, kann das eine geraume Zeit dauern.

known.txt bearbeiten

Ich fühle mich gerade wie ein HDD-DJ, ich jongliere hier mit Festplatten, wie andere mit CDs… :-) Aber egal.

Das Hashen hat nun eine geraume Zeit gedauert, und es ist dabei eine sehr große known.txt dabei entstanden. Die kann aber, so, wie sie jetzt ist, nicht verwendet werden. Zum Einen sind die Pfadangaben für Windows, zum Anderen haben wir hashdeep mehrere Male aufgerufen und die Hashes an diese Datei anhängen lassen, so dass der Datei-Header nun mehrere Male vorhanden ist. Dies muss geändert werden, bevor die Datei auf dem Server verwendet werden kann.

Ihr könnt zwar so ziemlich jeden Editor nutzen, den ihr möchtet, da es ja nur eine einfache Textdatei ist, ich benutze den Notepad++, aus gewohnheit und weil ich meine, dass der mit großen Dateien besser klarkommt.

Die known.txt beginnt mit den folgenden Zeilen:

%%%% HASHDEEP-1.0
%%%% size,md5,sha256,filename
## Invoked from: c:\
## c:\> hashdeep64 -re g:\daten
## 

Darunter beginnen die Hashes, jede Zeile enthält einen Hashwert und die dazu passende Datei.

Diese 5 Zeilen lassen wir so auch stehen. Weiter unten tauchen diese 5 Zeilen leider aber noch mehrere Male auf. Das könnte zum Problem werden, daher müssen wir diese entfernen. Also nutze ich die Suchfunktion und suche nach den 4 aufeinanderfolgenden Prozentzeichen. Dann wird der zusätzliche Header gelöscht, bis nur noch die Headerzeilen ganz oben vorhanden sind. Diese müssen sein.

Nun zeigen auch noch die Pfade auf Windows-Pfade, weswegen das Programm auf dem Server nichts finden würde. Mit zwei einfachen Suchen und Ersetzen Schritten wandeln wir diese Pfade in Linux-Pfade um.

Gehen wir also in das Suchen und Ersetzen Dialogfeld, in fast allen Editoren ist das mit Strg+H möglich. In das Feld “Suchen nach” geben wir “g:\daten” ein. In das “Ersetzen mit” Feld geben wir “/raid1/daten” ein. Nun aktivieren wir die Schaltfläche “Alle ersetzen”. Bei der Größe der Datei kann das einige Zeit dauern.

Im zweiten Schritt gehen wir wieder in das Suchen und Ersetzen Dialogfeld, und geben bei “Suchen nach” “\” ein, und in das “Ersetzen mit” Feld einen “/”. Auch jetzt aktivieren wir wieder die Schaltfläche “Alle ersetzen”.

Jetzt ist die Datei bereit, weiterverwendet zu werden. Also schließe ich den Editor, speichere die Datei dabei ab und kopiere sie auf den Server ins Home-Verzeichnis. Hierfür hatte ich ja eine Freigabe eingerichtet, also kann ich das mit dem Explorer tun.

Hashwerte gegenprüfen auf dem Server

Um nun zu prüfen, ob die Dateien auf meinem RAID in Ordnung sind, habe ich ja die known.txt in mein Home-Verzeichnis kopiert. Also logge ich mich per SSH auf dem Server ein. Das Erste, was ich nun tue, ich installiere erst mal MD5Deep auf meinem Server:

sudo apt-get install md5deep

Nun stehen mir alle Programme wieder zur Verfügung, die ich auch unter Windows schon hatte, darunter auch hashdeep. Mit diesem Programm und der zuvor erstellten Liste der bekannten Hashes kann ich nun prüfen, ob die Dateien auf dem RAID dem entsprechen, wie sie in meinem Backup vorhanden sind.

Hinweis: Die Prüfung wird in jedem Falle fehlschlagen. In der Zwischenzeit wurden Dateien hinzugefügt, entfernt und bearbeitet. Hashdeep prüft aber, ob der Verzeichnisbaum und -inhalt identisch sind. Kleinste Abweichungen führen schon zum Fehlschlagen des Audits. Das macht aber nix, wie ich gleich zeigen werde. Ich wollte es nur gleich gesagt haben… :-)

Ich rufe Hashdeep also nun mit folgendem Befehl auf:

sudo hashdeep -vv -rak known.txt /raid1/daten >resultat.txt

Der Parameter -v regelt die Ausführlichkeit der Ausgabe. Ein einzelnes v gibt nur etwas mehr Informationen, vv führt die Diskrepanzen auf und vvv gibt den Status für jede Datei an.

Den Status jeder Datei zu sehen, wäre too much. Mich interessieren nur die Diskrepanzen. Denn so kann ich entscheiden, ob ich die Datei gelöscht, bewegt, bearbeitet oder sie durch den Crash kaputtgegangen ist.

Der Parameter -rak scant das Ziel rekursiv, aktiviert den Audit-Modus und übergibt die Hash-Datei. Der Audit-Modus untersucht nun jede Datei in der Hash-Datei, ob sie geändert ist oder überhaupt noch vorhanden ist.

Am Ende wird das Resultat in die Datei resultat.txt geschrieben, wo ich es dann in Ruhe analysieren kann. Und da die Diskrepanzen nur eine Hand voll Dateien betreffen sollten, wenn alles gutgegangen ist, dürfte das ein überschaubarer Aufwand sein.

Resultate?

Eine Handvoll Dateien, ja nee, is klar! :-) Das habe ich ja mal so was von unterschätzt!

Woran ich nicht gedacht habe, alle Dateien, die nicht im Backup vorhanden sind, werden natürlich als “No match” angegeben und in die resultat.txt geschrieben. Und es gibt einiges auf dem RAID, was nie ins Backup kommt. Diese Daten sind einfach zu unwichtig, tämporäre Dateien, Podcasts oder sonst Daten, die ich leicht aus dem Netz bekommen kann. Das macht die Analyse der Datei nicht einfach, aber da muss ich jetzt durch… Wie zu erwarten war, steht am Ende der Datei natürlich “hashdeep: Audit failed”.

Das macht aber nix, ich war tapfer und bin die ganze Datei durchgegangen. Das ist auch relativ einfach, da die Einträge ja nach Verzeichnissen sortiert waren. So konnte ich die unwichtigen Verzeichnisse einfach durchblättern.

War der Ausfall des RAIDs letztens jetzt eigentlich folgenlos? Sind meine Daten evtl. in Mitleidenschaft gezogen worden? Diese Fragen kann ich jetzt mit einem definitiven “Alles ist gut, nichts ist kaputt!” beantworten! Das beruhigt mich ja ungemein, auch wenn das jetzt echt Arbeit war, das zu prüfen.

Für die Zukunft

Jetzt, wo ich weiß, dass die Daten auf dem RAID OK sind, kann ich es mir ja bedeutend einfacher machen. Statt nach einem Desaster mühsam alle Backupplatten zu hashen, werde ich jetzt in größeren Abständen die Daten direkt auf dem RAID hashen. Hierfür werde ich folgenden Befehl nutzen:

sudo hashdeep -re /raid1/daten >hashes.txt

Die hashes.txt liegt dann in meinem Homeverzeichnis auf der SSD. Sollte ich nun mal wieder das Bedürfnis haben, die Integrität meiner Daten prüfen zu wollen, so kann ich immer auf diese Datei zugreifen:

sudo hashdeep -vv -rak hashes.txt /raid1/daten

Somit entfällt natürlich der gesamte obere Teil, die Datenbackups zu hashen und die Hash-Datei manuell zu bearbeiten. Selbstverständlich muss die Hash-Datei gelegentlich aktualisiert werden, aber das dürfte ja klar sein.

Fazit

Ich bleibe dabei, das Linux Software-RAID ist echt robust und kann ganz schön was ab, bevor es zu Datenverlusten kommt. Aber, und das kann ich gar nicht oft genug sagen, wer kein Backup hat, hat ein größeres Problem, als nur paar Tage mit Hashen und Prüfen zu verlieren.

Homeserver 24: RAID-Ausfall, was tun?

Heute Morgen geriet ich dann doch etwas in Panik! Mein Postfach war voller Fehlermeldungen vom RAID-System und von S.M.A.R.T. Demnach waren zwei Festplatten ausgefallen. S.M.A.R.T. war der Meinung, /dev/sdb und /dev/sdc seien zwar noch da, könnten aber nicht geöffnet werden oder seien keine Laufwerke, die S.M.A.R.T.-Daten zur Verfügung stellten. Und MDADM, das RAID-System, war der Meinung, die Laufwerke hätten ein Problem und setzte mal eben das RAID herab. Da es ja jetzt aber zwei Platten sind, ging am RAID erst mal gar nichts mehr!

Eine kurze Abfrage der /proc/mdstat ergab leider auch nichts brauchbares, da SDb1 und SDC1 einfach nur als defekt markiert wurden. Nun hätte ich viele der Reparaturversuche sofort machen können, tat dies aber nicht. Ich hatte nämlich vorher, als ich mich noch in Linux eingelesen hatte, in einem Forum gesehen, dass so ein Problem, ganz wie bei Windows, bei einem Reboot wieder verschwindet. Gesagt, getan, und nicht gestartet. :-( Der Server fuhr einfach nicht mehr hoch. Und da ja nun kein Bildschirm und keine Tastatur angeschlossen ist, wusste ich auch nicht, was denn nun vor sich geht. Also habe ich den Server abgebaut und zu mir an meinen Schreibtisch geholt.

Erinnert ihr euch, dass ich relativ kurz nach der Installation BRLTTY wieder deinstalliert hatte, weil es ja nicht benötigt würde? Ganz schlechte Idee, wie sich jetzt herausstellt. :-) Aber, halb so wild, ich habe es ja wieder installieren können, für so was einfaches reichte mein Sehrest noch. Aber nur so zur Info, lieber nicht deinstallieren. :-)

Startversuch

Das System bleibt mitten im Bootvorgang stehen und meldet einen Fehler. Ich habe die Fehlermeldung nicht mehr genau im Kopf, aber in Etwa sah es so aus:

FSCK died with exit code 8

Oder so etwas ähnliches. Und dann noch ein englischer Text, dass nun eine Maintenance Shell gestartet würde, damit man das Problem beheben könne. Und wenn man dies getan hätte, könne man ja Ctrl+D drücken, um normal weiterzubooten. Gut, ich habe das ignoriert und habe gleich Ctrl+D gedrückt.

RAID analysieren

Wenn ich mir nun die /proc/mdstat angucke, steht das RAID MD0 dort als inactive, also es ist nicht gestartet. Alle Platten stehen dort als Spare, also hinter jeder Bezeichnung der Platten steht ein (S).

Manuelles Starten des RAID

Bevor man nun irgendetwas tut, muss das RAID erst mal gestoppt werden:

sudo mdadm --stop /dev/md0

Gibt man folgenden Befehl ein,

sudo mdadm --assemble /dev/md0

müsste das RAID sich selbst wieder zusammensetzen und starten. In meinem Falle ging das aber nicht. Also habe ich den Befehl noch etwas anders eingegeben:

sudo mdadm --assemble --verbose /dev/md0

Dieser Befehl gibt eine Menge Informationen aus, ob etwas klappt, und wenn nicht, warum nicht. Allerdings hatte ich diese Befehle alle angewendet, als mein Server hier am Schreibtisch Stand und keine Netzverbindung hatte. Ich habe daher die Ausgaben nicht gespeichert und gebe die Daten aus dem Kopf wieder.

Bei den Festplatten /dev/sdb1 und /dev/sdc1 bekam ich die Fehlermeldung “has no Superblock”. Der Superblock ist der Bereich, indem das RAID eine Menge an Informationen über das RAID selbst und seine beteiligten Festplatten ablegt.

Das selbständige zusammensetzen hat also nicht geklappt, dann also per Hand. Und, bevor ein Array wieder gestartet und zusammengesetzt werden kann, muss es immer erst gestoppt werden. Also setze ich das RAID so zusammen:

sudo mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

Auch kein Glück:

MDADM: Assemby of /dev/md0 from 3 drives, not enough to start the array.

Aus dem Kopf geschrieben, die Formulierung könnte geringfügig anders sein.

Reparieren des RAID

Zunächst überprüfe ich erst mal, ob die Festplatten wirklich nicht kaputt sind. Ich mache keine außerordentlich ausführliche Prüfung, sondern ich checke einfach nur mal, ob die durch S.M.A.R.T. gemeldeten Probleme noch da sind:

sudo smartctl -a /dev/sdb

Und das mache ich natürlich mit allen als defekt gemeldeten Platten. Die Ausgabe ist sehr umfangreich, zumeist reicht aber, die ersten paar Werte zu sehen, und ob sie in Ordnung sind. In meinem Fall sind beide Platten in Ordnung, weiß der Geier, warum die rumgezickt haben.

Wie auch immer, wo ja nun klar ist, dass /dev/sdb1 und /dev/sdc1 in Ordnung sind, können wir das RAID wieder reparieren. Und zwar teile ich MDADM mit, dass die Platten in Ordnung sind und er sie starten soll, auch wenn er meint, er würde Fehler finden.

sudo mdadm --assemble --force /dev/md0

Nun startet zwar das RAID, aber nur mit 4 statt 5 Platten. Aber es startet. Nun gucke ich mit cat /proc/mdstat mal rein, was das Problem ist, und /dev/sdb1 ist aus irgendwelchen Gründen nicht hinzugefügt worden. Es ist also gar nicht mehr im RAID-Verbund. OK, dann müssen wir diese Platte wieder hinzufügen:

sudo mdadm --add /dev/md0 /dev/sdb1

Die Platte wird dem RAID hinzugefügt und die Rekonstruktion des RAID beginnt. Dies kann einige Zeit dauern, in meinem Fall so um die 5 Stunden.

Fazit

Das Schöne ist, man kann den Rechner jetzt einfach abschalten, zurück in seine dunkle Ecke tragen und dort wieder in Betrieb nehmen. Der Server startet wieder normal und beginnt sofort die Rekonstruktion.

Ich habe von meinen Daten ein Backup. Schlimmstenfalls wäre mir Arbeit von 3 oder 4 Tagen verlorengegangen, damit hätte ich leben können. Ich bin aber dennoch erstaunt, wie robust das RAID-System ist. Zwar war wieder eine Menge Lesen angesagt, aber letztlich kann man sich selbst aus so einer Situation wieder retten.

Andererseits habe ich nicht die geringste Ahnung, was eigentlich passiert ist. Wieso waren die beiden Laufwerke auf einmal nicht mehr ansprechbar? Da ich die Ursache nicht kenne, und auch irgendwie nicht rausfinde, bleibt mir nur zu hoffen, dass es so schnell nicht wieder passiert. Und falls doch, immer schön das Backup aktuell halten!

Homeserver 23: Webserver absichern

Der Webserver ist zwar zur Zeit nur von meinem internen Netz erreichbar, das soll sich aber später noch ändern. Aber so, wie er jetzt ist, wäre es fahrlässig, ihn für das Internet zu öffnen. Jeder könnte meine Server-Logs sehen, jeder könnte die Daten für PHP und MySQL finden, die auf meinem Server laufen. Für einen Angreifer sind das wichtige Daten. Also muss ich, bevor ich Zugriff von außen erlaube, den Webserver absichern.

Passwortschutz einrichten

Meine Server-Startseite hat Links zu allen wichtigen Punkten meines Servers. Jeder, der auf die Startseite kommt, kann sich meine Hardware, Systemdetails und Logs angucken. Also muss ich dafür sorgen, dass man dafür einen Benutzernamen und Passwort braucht. Und das ist gar nicht so schwer.

Zunächst müssen wir am Webserver was umkonfigurieren.

sudo nano /etc/apache2/sites-enabled/000-default

Ihr erinnert euch? Das ist die gleiche Datei, in der wir das DocumentRoot, also das Verzeichnis festgelegt haben, wo Apache nach den Website-Daten suchen soll. Hier müssen wir eine kleine Kleinigkeit ändern. Der Abschnitt sieht ursprünglich so aus:

    <Directory /raid1/web/HTML/>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        allow from all
    </Directory>

In der Zeile, wo “AllowOverride None” steht, müssen wir das “None” durch “all” ersetzen. Dann sieht die Zeile so aus: “AllowOverride all”.

Dann noch die Datei speichern, und den Webserver neu starten:

sudo service apache2 restart

Nun müssen im Verzeichnis “HTML” in der Web-Freigabe zwei Dateien erstellt werden. Die erste Datei erstellen wir mit einem Texteditor. Um es einfach zu machen, mache ich das wieder von der SSH-Kommandozeile:

nano /raid1/web/HTML/.htaccess

Das sudo ist hier nicht nötig, weil wir die Datei mit den Rechten des angemeldeten Benutzers, also kamil, anlegen. Und in das leere Editorfenster schreibe ich folgendes rein:

AuthType Basic
AuthName "Passwort eingeben"
AuthUserFile /raid1/web/HTML/.htpasswd
require valid-user
  • AuthType Basic: Das sorgt für die Abfrage von Nutzerdaten.
  • AuthName “Passwort eingeben”: Dieser Text erscheint im Dialogfeld, wenn jemand die Seite aufruft. Hier könnte alles mögliche stehen.
  • AuthUserFile /raid1/web/HTML/.htpasswd: Das ist der Pfad zur Passwort-Datei, dazu komme ich gleich noch.
  • require valid-user: Jeder in der Passwort-Datei eingetragene Nutzer kann sich an der Seite anmelden.

OK, soweit so gut, aber die Passwort-Datei muss noch angelegt werden. Dies machen wir nicht mit einem Editor, weil das Passwort ja verschlüsselt abgelegt werden soll. Wäre ja witzlos, wenn das Passwort im Klartext auf der Platte liegen würde. Also nehmen wir ein Programm dazu, dass der Apache gleich mitgebracht hat:

sudo htpasswd -c /raid1/web/HTML/.htpasswd kamil

Falls noch keine Passwort-Datei existiert, muss sie angelegt werden, das macht der Parameter -c. Falls die Datei bereits existiert, braucht ihr den Parameter später nicht mehr. Dann kommt der Pfad zur Passwort-Datei, und am Ende der Benutzername.

Nun werde ich nach dem Passwort für kamil gefragt, dieses gebe ich zwei mal ein. Fertig, die Datei wurde erstellt und der Nutzer eingetragen.

Wenn ich jetzt entweder mit der IP-Adresse, oder auch mit http://server01 auf die Seite gehen will, öffnet sich ein Dialogfenster, welches mich nach Benutzername und Passwort fragt. Erst dann bin ich auf meiner Startseite und kann die Links anklicken und mir z. B. die Logs angucken.

Zugriff mit SSL erzwingen

Das ist erst mal die halbe Miete, die andere Hälfte ist die Absicherung mit einem SSL-Zertifikat. Wenn ihr in einem unverschlüsselten WLAN seit, dürft ihr auf gar keinen Fall auf den Server zugreifen, wenn die Verbindung nicht mit SSL abgesichert ist. Jeder, der wollte, könnte mitlesen. Wenn aber der Zugriff über SSL erfolgt, sind eure Daten sicher. Daher richte ich jetzt den Server so ein, dass er alles nur noch über SSL macht.

SSL-Zertifikate sind teuer, wenn man sie sich von einer offiziellen CA-Stelle ausstellen lässt. Die Browser kennen die CAs, (Certificate Authorities), und vertrauen den SSL-Zertifikaten. Ich hingegen will für meinen Homeserver jetzt nicht so viel Geld ausgeben, daher erstelle ich selbst ein Zertifikat und beglaubige es auch selbst. Nachteil, die Browser kennen das Zertifikat nicht und wollen, dass man es selbst bestätigt. Auch muss dieses Zertifikat dann manuell in die liste vertrauenswürdiger Zertifikate aufgenommen werden. Aber für einen Privatserver ist das OK. Wenn ich bei meinem Mailanbieter oder bei der Bank auf solch ein Zertifikat stoßen würde, würden bei mir alle Alarmglocken Sturm läuten.

Zunächst müssen wir am Apache-Webserver die SSL-Unterstützung einschalten. Dazu müssen Module geladen werden.

sudo a2enmod ssl
sudo a2ensite default-ssl

So, nun noch selbstsignierte SSL-Zertifikate erstellen:

sudo make-ssl-cert generate-default-snakeoil --force-overwrite

Damit nun alle Zugriffe auf den Webserver verschlüsselt passieren, müssen alle HTTP-Anfragen in HTTPS-Anfragen umgeleitet werden. Dies kann Apache, aber dazu muss erst wieder ein Modul aktiviert werden:

sudo a2enmod rewrite

Nun muss noch die Regel erstellt werden, die dafür sorgt, dass die Anfragen jeweils umgeleitet werden. Dies ändert man wieder in der 000-default-Datei:

sudo nano /etc/apache2/sites-enabled/000-default

Unter die Zeile, die mit “ServerAdmin” beginnt, füge ich folgende Zeilen hinzu:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

Diese Datei speichern wir noch und müssen noch eine Datei editieren. Die default-ssl-Datei zeigt noch auf die falschen Verzeichnisse.

sudo nano /etc/apache2/sites-enabled/default-ssl

Hier müssen wieder genau die gleichen Zeilen angepasst werden, damit Apache die Webseite findet und auch die Passwortabfrage funktioniert.

Die Zeile “DocumentRoot” muss geändert werden, damit da wieder /raid1/web/HTML steht.

Die Zeile <directory /var/www></directory> muss in <directory /raid1/web/HTML></directory> geändert werden.

Die Zeile “AllowOverride None” muss zu “AllowOverride all” geändert werden.

Die Datei noch speichern, und nachdem wir all diese Änderungen gemacht haben, den Webserver noch mal neu starten:

sudo service apache2 restart

Wenn ich an meinem Windows-Rechner mit Firefox nun auf die Seite http://server01 gehe, passiert folgendes: Es erscheint eine Meldung, dass dieser Verbindung nicht vertraut wird. Diese Meldung ignoriere ich, und wähle ganz unten den Schalter “Ich kenne das Risiko”. Hierauf erscheint noch mehr Text, welcher einen warnt, und normalerweise würde ich diese Warnungen auch sehr ernst nehmen. Ich weiß aber, dass es mein Server und mein Zertifikat ist, daher gehe ich ganz unten auf die Schaltfläche “Ausnahmen hinzufügen”. In dem nun folgenden Dialog aktiviere ich die Checkbox, “Diese Ausnahme dauerhaft speichern” und klicke auf die Schaltfläche “Sicherheits-Ausnahmeregel bestätigen”.

Fertig!

Von nun an kann ich, ob nun innerhalb meines Heimnetzes oder von außen, auf meinen Server per SSL-Verbindung zugreifen. Falls ich also mal im Zug, im Hotel oder in einem anderen öffentlichen WLAN auf meinen Server will, kann jedenfalls so ohne weiteres keiner mitlesen.

Homeserver 22: Linux Handbuchseiten im Browser ansehen

Eine Kleinigkeit habe ich im vorigen Teil total vergessen, obwohl ich dies für absolut wichtig halte. Nämlich das Lesen von Manpages im Browser.

Manpages sind Handbuchseiten, Manual Pages, die die Optionen und Anwendung von Programmen beschreiben. Im Terminal ruft man die Hilfe zu ls, also dem Tool zum Verzeichnisse anzeigen, so auf:

man ls

Am Terminal liest sich das aber, ehrlich gesagt, nicht so bequem. Und ich will es mir so bequem wie möglich machen. :-)

Installation

Damit Manpages im Browser angezeigt werden können, muss ein Paket nachinstalliert werden:

sudo apt-get install man2html

Das war es schon, das Programm funktioniert schon.

Manpages im Browser ansehen

Nun kann man die Manpages bequem im Browser lesen. Ich habe für meine Server-Startseite bereits einen Link gemacht, so dass ich die Adresse hier nicht immer in die Zeile per Hand eingeben muss. Um sich die Manpages also im Browser anzugucken gibt man folgende Adresse ein: http://server01/cgi-bin/man/man2html. An Stelle von server01 kann auch ein anderer Rechnername stehen, je nach dem, wie ihr euren Server genannt habt, oder eben auch eine IP-Adresse.

Hier kann man nun in einem Suchfeld den Befehl eingeben, zu dem man Hilfe sucht, oder man kann durch die Liste der Sektionen browsen.

Das macht es doch schon viel einfacher, oder? Zumindest muss man sich nicht mehr per SSH anmelden, um mal was nachzugucken. :-)

Homeserver 21: Serverinformationen und Logs im Browser ansehen

In diesem Teil will ich mal ein Paar Anwendungen installieren, mit denen ich über den Webserver einiges an Informationen abfragen oder Datenbanken erstellen kann.

phpMyAdmin

Damit wir jetzt aber mit Datenbanken arbeiten, welche erstellen oder Sicherungen davon machen können, brauchen wir eine bequeme Anwendung. Zwar können wir das auch über die Kommandozeile machen, aber warum kompliziert, wenn es auch einfach geht? phpMyAdmin ist solch eine bequeme Form.

Installation

Wie alles in Linux, wird auch diese Anwendung auf die gleiche Weise installiert:

sudo apt-get install phpmyadmin

Während der Installation werden paar Fragen gestellt.

  • Welcher Webserver soll automatisch konfiguriert werden, damit phpMyAdmin damit funktioniert? Hier gibt es zwei zur Auswahl, ich habe Apache gewählt.
  • Datenbank mit config-db erstellen? Man kann das hinterher auch manuell machen, aber wie das geht, weiß ich nicht. Müsste ich erst lesen. Daher habe ich hier zugestimmt, damit das automatisch gemacht wird. phpMyAdmin funktioniert sonst nicht.
  • Das Datenbank-Administrator-Passwort.
  • Ein phpMyAdmin-Passwort.

Wenn man diese Angaben gemacht hat, ist phpMyAdmin bereits einsatzbereit. Man kann es sehen, wenn man den Browser öffnet, http://<ip des Servers>/phpmyadmin eingibt und die Webseite betrachtet. :-)

Übrigens, offenbar kann man in der Adresszeile des Browsers auch den Rechnernamen eingeben. mit http://server01/phpmyadmin kam ich auch auf die phpMyAdmin-Seite.

Für die Anmeldung muss man als Benutzername “root” und als Passwort das Datenbank-Administrator-Passwort eingeben, welches man bei der MySQL-Installation gewählt hat.

Wie man damit jetzt aber Datenbanken anlegt oder sichert, dazu komme ich, wenn es soweit ist.

phpSysInfo

Diese kleine Anwendung zeigt allerhand nützliche Informationen über den Server an. Hier kann man sehen, wie die Temperatur der Festplatten oder des Prozessors ist, wie der RAID-Status ist oder auch, welche Prozesse gerade laufen. Die Art der Anzeigen ist hier fast frei konfigurierbar.

Installation

Zunächst einmal lädt man sich die Anwendung von der phpSysInfo-Webseite herunter. Die geladene ZIP-Datei muss entpackt, und das darin befindliche Verzeichnis umbenannt werden. Zunächst hat es den Namen “phpsysinfo-<version>“, wobei man das Verzeichnis dann in “phpsysinfo” umbenennt. Das habe ich auf meinem Windows-Rechner gemacht.

Auf dem Server gibt es ja die Freigabe Web, die ich als Netzwerklaufwerk verbunden habe. Dort existiert ein Verzeichnis “HTML”. Hier sucht ja der Webserver nach Dateien. Dort hinein kopiere ich das Verzeichnis “phpsysinfo”. Das war es schon, mehr muss nicht installiert werden.

Konfiguration

Im Verzeichnis “phpsysinfo” liegt nun eine Datei die sich “phpsysinfo.ini.new” nennt. Diese muss umbenannt werden, so dass sie “phpsysinfo.ini” heißt.

Ich habe die INI-Datei aus Bequemlichkeit an meinem Windows-Rechner bearbeitet, aber das ist letztlich euch überlassen. In dieser Datei finden sich alle möglichen Einstellungen, die ihr dem Programm phpSysInfo übergeben könnt. Dies beinhaltet z. B. die Sprache, das Design und viele weitere Parameter. Jede Einstellung hier zu erwähnen würde den Rahmen bei weitem sprengen. Die einzelnen Einstellmöglichkeiten sind in der Datei in Englisch aber ausführlich beschrieben.

Besonders solltet ihr auf die Einstellungen für die Plugins achten. Hier könnt ihr festlegen, ob ihr Prozesse sehen wollt, RAID-Status oder S.M.A.R.T.-Informationen. Aber die meisten anderen Einstellungen können auf Standardwerten bleiben.

Aufruf

Geht mit eurem Browser einfach auf die IP-Adresse eures Servers, z. B. http://192.168.178.10/phpsysinfo. Die Seite baut sich auf, und ihr könnt die Informationen ablesen. Alternativ geht auch http://server01/phpsysinfo.

Log-Dateien im Browser betrachten

So ziemlich alles, was wir dafür brauchen, ist schon installiert. Der Webserver und PHP laufen, MySQL geht auch. Der Dienst rsyslog, den wir dafür brauchen, ist schon vorinstalliert.

Konfiguration der Datenbank

Dieser Punkt hat mich fast den ganzen Tag beschäftigt. Da gibt es so viele veraltete Informationen im Netz, aber egal. Letztlich habe ich es dann doch noch geschafft.

Damit rsyslog in eine Datenbank schreiben kann, muss ein weiteres Modul installiert werden.

sudo apt-get install rsyslog-mysql

Während der Installation werdet ihr gefragt, ob ihr die Datenbanken automatisch erstellen lassen wollt. Das beantwortet ihr mit ja. Dann wird das Datenbank-Administrator-Passwort abgefragt. Anschließend will rsyslog für sich noch ein Passwort erstellt haben. Wenn ihr diese Fragen beantwortet habt, ist rsyslog schon dabei, Logs in die Datenbank zu schreiben.

LogAnalyzer

Dies ist das Programm, mit dem ich mir die Logs angucken will. Dieses bekomme ich auf der Website des Herstellers. Die heruntergeladene Datei wird ausgepackt, und in dem jeweiligen Unterverzeichnis befindet sich ein Verzeichnis “src”. Dieses benenne ich um in “log” und kopiere es in das HTML-Verzeichnis auf der Web-Freigabe.

Nun gehe ich mit dem Browser auf die Seite http://server01/log und folge den Anweisungen.

Eigentlich sind die Felder selbsterklärend. Als Log-Typ wähle ich “MySQL native”, Benutzername ist “root” und Passwort ist das Datenbank-Administrator-Passwort. Als Host wird “localhost” eingegeben.

Hier gibt es zwei Fallen, auf die ihr achten müsst. Der Datenbankname ist vorgegeben, den löscht ihr und tragt “Syslog” ein. Die Tabelle ist ebenfalls vorgegeben, da steht “systemevents”. Da müsst ihr “SystemEvents” eintragen, sonst funktioniert es nicht.

Auf die Frage, ob ich die Benutzerverwaltung installieren will, wähle ich ja, worauf wieder Eingabefelder für Datenbank und Tabellen aufgehen. Hier ändere ich nur den vorgegebenen Datenbanknamen in “Syslog” und trage ansonsten alles so ein, wie vorher. Den Tabellenpräfix lasse ich aber so, wie es vorgegeben war. Anschließend noch schnell den ersten Admin-Benutzer einrichten, fertig.

Die Benutzerverwaltung ist wichtig, weil wir nur so an das Admin-Center rankommen, wo wir Einstellungen machen können. Sonst müssten wir mühsam irgendwelche PHP-Dateien editieren.

Wenn alles geklappt hat, werdet ihr auf die Seite geleitet, wo das Log angezeigt wird. Hier gibt es Suchfelder, viele Möglichkeiten, zu filtern, und eben, wenn alles geklappt hat, eine Menge Logeinträge.

Fazit

Leider stehen die früheren Logs hier nicht zur Verfügung. Die muss man sich evtl. mühsam an der Kommandozeile von Linux angucken. Aber ab jetzt wird jedes Syslog-Ereignis in die Datenbank geschrieben und kann hier über die Webseite ´http://server01/log` angeguckt, oder nach speziellen Einträgen gesucht werden.

Das war’s

Zumindest mal für den Augenblick. Aber damit ihr euch nicht alle URLs zu den unterschiedlichen Diensten merken müsst, könntet ihr euch ja eine Startseite auf http://server01/index.php mit den Links erstellen. Ich habe eine gebastelt, die zum einen die Links zu den Seiten hat, darunter auch die PHP-Info mit vielen nützlichen Infos anzeigt. Ihr könnt das ja als Beispielvorlage nehmen.

Kopiert den folgenden Text und fügt ihn in eine leere Textdatei ein. Speichert diese dann als index.php und kopiert sie in das HTML-Verzeichnis der Web-Freigabe.

<html>
<body>
<h1>System Startseite</h1>
<p>Hier sind die Links, um auf die wichtigsten Systembereiche zu kommen:</p>
<p><a href="/phpsysinfo">Systeminformationen mit PHPSysInfo</a></p>
<p><a href="/phpmyadmin">PHPMyAdmin</a></p>
<p><a href="/log">Log Analyzer</a></p>
<h1>PHP-Informationen</h1>
<?php
phpinfo();
?>
</body>
</html>

Damit müsst ihr euch jedenfalls nicht alle URLS merken und habt auch noch alle PHP-Funktionen und Einstellungen auf dem Bildschirm.

Homeserver 20: Webserver und Komponenten installieren

Als nächstes möchte ich auf dem Server einen Webserver installieren. Ich möchte jetzt nicht irgendwelche Webseiten im Internet anbieten, dafür wäre mein Server vielleicht zu schwach, oder zumindest mal die Anbindung ans Internet wäre dünn. Aber mit einem installierten Webserver kann man eine Menge interessanter Sachen machen. Zum Beispiel habe ich Tools gefunden, mit denen ich den Rechnerstatus abfragen kann, wie Temperatur, Lüfter und andere Parameter. Und das bequem im Browser, ohne dass ich mit SSH verbinden muss und Befehle eingeben muss. Dann habe ich Tools gefunden, mit denen ich die Server-Logdateien anzeigen und bequem durchsuchen kann. Auch das bequem im Browser. Das Management von Datenbanken geht auch super mit phpMyAdmin, also auch prima im Browser. Später soll vielleicht eine Cloud-Lösung installiert werden, ob es nun Owncloud wird, oder ein anderes Produkt welches mir CalDAV und CardDAV anbietet, weiß ich noch nicht. Aber auch hier, ein laufender Webserver sollte schon da sein.

Ich habe so was noch nie gemacht, das wird spannend. Vor allem die Konfiguration, denn besonders viele Informationen habe ich jetzt auf die Schnelle nicht gefunden. Aber, ich weiß ja ungefähr, wo die Konfigurationsdateien des Webservers abgelegt werden, versuche ich mich mal durchzuwühlen. Bei konkreten Fragestellungen kann ich ja immer noch im Netz suchen.

Es soll also Apache, der Webserver, PHP und MySQL als Datenbank installiert werden. Ob dann noch andere Tools installiert werden müssen, sehe ich dann, wenn es soweit ist.

Installation des Webservers

Das ist, denke ich, mit der einfachste Schritt. Man installiert einfach das Apache-Metapaket, und gut. Metapakete sind übrigens leer, sie fassen eine Gruppe von Paketen je nach Zweck zusammen. Das Apache-Metapaket installiert 4 oder 5 Pakete, die zum Betrieb des Webservers nötig sind. So muss man nicht alle Pakete einzeln installieren. Auch MySQL hat solche Metapakete, die die Installation vereinfachen.

Die Installation ist daher denkbar einfach. Das haben wir ja schon dutzende Male gemacht:

sudo apt-get install apache2

Fertig! Im Grunde läuft der Server schon. Man kann das sofort prüfen, in dem man im Browser mal die IP-Adresse des Servers eingibt. Aber das ist ja noch nicht alles. Ich habe ja auf dem RAID ein Verzeichnis web eingerichtet. Also muss Apache so konfiguriert werden, dass es die Webseiten-Daten dort sucht.

Konfiguration des Webservers

Der Webserver sucht seine Webseiten standardmäßig im Ordner /var/www. Das möchte ich aber nicht. Ich habe auf dem RAID einen Ordner web eingerichtet, damit ich die Website-Daten dort ablegen kann. Ich muss also dafür sorgen, dass Apache dort nach den Website-Dateien sucht.

Damit ich später kontrollieren kann, ob es geklappt hat, verschiebe ich erst mal die Test-Index-Datei, die im /var/www-Verzeichnis liegt, auf das RAID.

sudo mv /var/www/index.html -t /raid1/web/HTML

Im Verzeichnis web habe ich das Verzeichnis HTML erstellt, wo die ganzen Website-Daten reinkommen.

Nun teile ich Apache mit, dass der DocumentRoot, das ist das Verzeichnis mit den Website-Daten, auf dem RAID liegt.

sudo nano /etc/apache2/sites-enabled/000-default

In dieser Datei sind einige Werte eingestellt, aber die lassen wir erst mal in Ruhe. Zunächst müssen wir zwei Zeilen ändern.

    DocumentRoot /var/www

Diese Zeile müssen wir so ändern, dass sie auf das HTML-Verzeichnis auf dem RAID zeigt.

    DocumentRoot /raid1/web/HTML

Damit sucht der Server die Dateien nun in diesem Ordner. Es gibt aber noch eine Zeile, die die Rechte innerhalb des Verzeichnisses regelt. Hier muss auch noch etwas geändert werden.

    <Directory /var/www/>

Diese Zeile muss hinterher so aussehen:

    <Directory /raid1/web/HTML/>

Den Rest der Datei können wir in Ruhe lassen. Einfach speichern und dann noch den Webserver neu starten.

sudo service apache2 restart

Und wenn der Server wieder gestartet ist, öffnet mal euren Browser und gebt mal die IP-Adresse eures Servers ein. Ich habe meinem Server ja eine feste IP gegeben, daher weiß ich diese. Wenn alles geklappt hat, erscheint eine Webseite mit ungefähr diesem Text:

It works!

This is the default web page for this server.

The web server software is running but no content has been added, yet.

OK, läuft! Am Webserver müssen wir so jetzt nichts mehr machen.

PHP installieren

Damit gewisse in PHP programmierte Webseiten laufen können, muss PHP auf diesem Server installiert werden.

sudo apt-get install php5

Auch dies hat nun geklappt. Während der Installation wurde der Apache-Server neu gestartet. Damit ist auch die PHP-Installation erledigt.

MySQL installieren

Damit Datenbank-Anwendungen laufen können, muss ein MySQL Server und ein MySQL Client installiert werden. Und damit PHP-Anwendungen auf MySQL zugreifen können, muss PHP5-MySQL installiert werden.

sudo apt-get install mysql-server mysql-client php5-mysql

Während der Installation von MySQL werde ich nach einem Root-Passwort für den Datenbank-Administrator gefragt. Zwar ist das nicht unbedingt erforderlich, es wäre dennoch zu empfehlen, hier eines einzugeben. Es sollte sinnvollerweise nicht das gleiche Passwort sein, welches ihr am Server nutzt. Dann noch das Passwort erneut eingeben, fertig!

Fazit

Die Installation der Komponenten ist wirklich nicht so das Problem. Aber im nächsten Teil möchte ich ein paar Programme für den Webserver installieren, zum Beispiel phpsysinfo, mit dem man allerhand Statusinformationen zum Server bekommt. phpMyAdmin brauchen wir noch, um die Datenbanken managen zu können, und eine Anwendung, um die Logdateien zu durchsuchen wäre auch schön. Diese Dinge kommen in den nächsten Teilen nach und nach dran.

Homeserver 19: Nachtrag zu öffentlichen Ordnern mit Samba

Während des Betriebes ist mir aufgefallen, dass der öffentliche Ordner, den ich mit Samba eingerichtet hatte, nicht öffentlich zugänglich war. Irgendetwas war da falschgelaufen. Also habe ich mir den Vorgang noch einmal angesehen, mich noch weiter eingelesen und korrigiert. Und so funktioniert es dann auch wirklich, mehrmals ausprobiert! :-)

Anlegen des freizugebenden Ordners

Ich wechsele also in das Hauptverzeichnis meines RAIDs:

cd /raid1

Hier erstelle ich einen Ordner namens public:

sudo mkdir public

Anschließend übernehme ich den Ordner in meinen Besitz:

sudo chown -c -R kamil:kamil public

Und nun gebe ich jedem, der auf den Ordner zugreifen will, alle Rechte. Das beinhaltet lesen, schreiben und auch Programme ausführen. Das ist ein Punkt, den hatte ich vorher nicht gemacht:

sudo chmod 777 public

Kleine Anpassung der Samba-Konfiguration

Hier müssen wir zwei Dinge ändern. Zum Einen muss der Gast-Benutzer festgelegt werden, zum Anderen muss die Gast-Freigabe angepasst werden. Zunächst mal muss die Samba-Konfigurationsdatei geöffnet werden:

sudo nano /etc/samba/smb.conf

Nun könnt ihr im Editor Nano den Suchbefehl nutzen, um einen bestimmten Begriff zu finden. Der Befehl wird mit STRG+W aufgerufen. In das Eingabefeld gebt ihr “guest account”, natürlich ohne die Anführungsstriche, ein.

Hier steht in der Zeile:

   guest account = nobody

Den Wert “nobody” habe ich durch meinen Benutzernamen, also kamil, ersetzt.

Freigabe ändern

Die Freigabe, wie sie im früheren Teil beschrieben wurde, solltet ihr löschen. Ich habe die Freigabe nun angepasst, diese sieht jetzt so aus:

[Public]
path = /raid1/public
comment = Öffentlicher Ordner
public = yes
guest only = yes
writable = yes
browseable = yes
directory mask = 0777
vfs object = recycle
recycle:repository = /raid1/public/@recycle
recycle:keeptree = Yes
recycle:touch = Yes
recycle:versions = Yes
recycle:maxsize = 0
recycle:directory_mode = 0777
recycle:exclude_dir = @recycle

Nun noch die smb.conf speichern und mit

sudo service samba restart

den Samba-Service neu starten. Jetzt sollte die öffentliche Freigabe auch für Gäste mit Lese- und Schreibzugriff funktionieren.

Fazit

Fehler können leider immer mal passieren. Sobald mir welche auffallen, werde ich sie jedoch zu korrigieren versuchen. Ich hoffe aber, das war der bisher einzige Fehler. Der Rest scheint bisher super zu funktionieren. Das automatische Leeren der Netzwerk-Mülleimer klappt, das RAID arbeitet schnell und auch sonst ist mir noch nichts aufgefallen.

Aber bevor ich weitermache, dem Server mehr und mehr Arbeit aufzuhalsen, kümmere ich mich als nächstes lieber mal darum, wie man die Server-Logdateien auswerten kann. Schließlich will man ja wissen, was der Server so tut, und ob er es so tut, wie man es erwartet.

Homeserver 18: Das RAID erweitern

Mein RAID läuft ja als RAID 5. Ich habe das RAID mit der Mindestanzahl von drei Festplatten erstellt. Somit war ich in der Lage, den Server bereits zu nutzen, da ich ja schon Daten auf ihm lagern kann. Mein Time Machine Backup läuft darauf, Daten werden Stück für Stück kopiert und später kommen noch Webserver-Daten dazu.

Der Server war aber von Anfang an für ein wesentlich größeres RAID ausgelegt. Denn nicht nur für mich, sondern auch für den Rest meiner Familie, dient der Server als Datenablage. Und da kommt bei HD-Camcordern und hochauflösenden Digitalkameras so einiges an Daten zusammen. Das RAID wird jetzt also, je nach Bedarf, erweitert.

Vorher

Schauen wir uns doch mal an, wie viel Speicherplatz wir auf dem RAID gerade haben. Dazu benutze ich den Befehl “df”, kann man sich gut mit “Disk Free” als Eselsbrücke merken. :-)

df -h /raid1

Das vorangestellte sudo ist hier nicht nötig. Der Parameter -h sorgt dafür, dass die Ausgabe für Menschen lesbar wird. Sonst bekommen wir monströse Zahlen, die nur die Dateisystemblöcke angeben. Rechnen dürfen wir dann selber… Und zum Schluss das Verzeichnis /raid1, an dem ja unser RAID angedockt ist. Die Ausgabe sieht dann so aus:

Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        7.3T  4.4T  2.9T  62% /raid1

Sagt doch eigentlich alles, oder? Um die 62 % sind schon belegt, weil ich schon mit dem Kopieren der Daten angefangen habe. Ich werde aber nicht fertig, weil mir der Speicherplatz nicht ausreichen wird, das weiß ich jetzt schon. Die Zahl, die für uns jetzt interessant ist, ist die Zahl unter Size, also 7,3T (Terrabyte). Nur, damit wir später den Unterschied sehen.

RAID Erweitern

Jetzt werde ich dem RAID also zwei Festplatten hinzufügen. Wieso gerade zwei? Nun, eine, damit ich alle Daten von meinem QNAP NAS kopieren kann. Danach wird das QNAP NAS nicht mehr benötigt. Dort steckt aber schon eine ST4000VN000 drin, weil ich ursprünglich dessen RAID neu anlegen wollte. Später habe ich mich dann aber für den Bau dieses Servers entschieden. Diese Festplatte nehme ich dann natürlich aus dem NAS raus und baue sie in meinen Server ein. Hier wird nix verschwendet… :-)

Festplatten vorbereiten

Genau so, wie ich im Teil 12 beschrieben habe, müssen nun die neuen Festplatten partitioniert werden. Das sind dann die Laufwerke /dev/sde und /dev/sdf. Insbesondere bei der Festplatte, die ich aus dem QNAP NAS rausgenommen habe muss ich darauf achten, dessen Partitionstabelle mit O zu löschen und mit einer leeren zu überschreiben. Danach läuft alles wie bisher ab, Partition erstellen, Typ auf FD00 stellen und Daten mit W auf die Platten schreiben.

Festplatten in den RAID-Verbund aufnehmen

Dies passiert in mehreren Schritten. Laut einer Webseite im Internet ist es möglich, den Prozess auch mit mehreren Festplatten gleichzeitig durchzuführen. Das ist mir auch lieber, weil ich sonst für jede Festplatte erst warten müsste, bis der Synchronisationsvorgang abgeschlossen ist. Das kann Tage dauern. Die Wartezeit halbiert sich quasi, wenn man das nur ein mal tun muss… Ich Probiere es mal, falls es nicht klappt, dann halt einzeln.

Um die nun partitionierten Festplatten in den RAID-Verbund aufzunehmen, nutze ich diesen Befehl:

sudo mdadm --add /dev/md0 /dev/sde1 /dev/sdf1

Mit dem Parameter --add wird MDADM mitgeteilt, dass nun neue Festplatten hinzugefügt werden, nämlich dem RAID-Verbund /dev/md0. Und die Platten sind /dev/sde1 und /dev/sdf1.

Wir können uns auch gleich angucken, ob das zumindest schon mal geklappt hat, indem wir uns mal die mdstat angucken. Die sieht nach dieser Aktion nämlich so aus:

Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdf1[6](S) sde1[5](S) sdb1[0] sdd1[3] sdc1[4]
      7813772544 blocks super 1.2 level 5, 128k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Wie ihr jetzt sehen könnt, sind die Platten sde1 und sdf1 als Spares, also als Ersatzplatten hinzugefügt worden. Daher steht neben diesen Platten ein S in Klammern. Würde jetzt eine der ursprünglichen aktiven Platten ausfallen, würde MDADM sofort eine der Ersatzplatten nehmen, um das RAID wiederherzustellen. Das will ich ja nicht, also muss ich jetzt das RAID auf die beiden zusätzlichen platten erweitern.

RAID vergrößern

Der Grow-Modus von MDADM kann ziemlich viel. Man kann viele Parameter des RAIDs ändern. Wenn man z. B. merkt, die Chunk-Size von 128K ist zu klein, könnte man sie auf 512K erweitern oder sogar auf 64K verkleinern. Auch ein Wechsel des RAID-Level wäre möglich. Das will ich jetzt gar nicht machen, ich will die Anzahl der an dem RAID beteiligten Platten erhöhen.

sudo mdadm --grow /dev/md0 --raid-devices=5

Zuvor waren es ja 3, nun habe ich es auf 5 Platten erweitert. Die Platten sind bereits im Verbund, also erweitert MDADM das RAID auf die Spares, die schon hinzugefügt wurden.

MDADM fängt sofort damit an, das RAID auf die zusätzlichen Platten auszuweiten. Das kann man an der mdstat-Datei gut sehen, die jetzt so aussieht:

Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdf1[6] sde1[5] sdb1[0] sdd1[3] sdc1[4]
      7813772544 blocks super 1.2 level 5, 128k chunk, algorithm 2 [5/5] [UUUUU]
      [>....................]  reshape =  0.0% (927744/3906886272) finish=2565.2min speed=25377K/sec

unused devices: <none>

Das kann jetzt eine gehörige Zeit dauern. MDADM verteilt die Daten und ihre Wiederherstellungsinformationen jetzt auf die 5 Platten. Hierbei müssen eine ganze Menge Daten bewegt werden.

Die ersten paar Sekunden sind kritisch. Fällt jetzt der Strom aus, oder sonst irgendwas passiert, ist das RAID futsch. Das sind, wie gesagt, nur die ersten paar Sekunden, so um die 5 bis 10. Danach ist das RAID wieder ausfallsicher. Man könnte jetzt den Rechner sogar herunterfahren, und MDADM würde nach dem Einschalten dort weitermachen. Ich lasse ihn aber mal durchlaufen, der Prozess dauert so schon lange genug.

Auch auf die Daten kann man zugreifen. Aber auch hier, jeder Zugriff verlangsamt die Rekonstruktion des RAIDs. Und fertig sind wir ja noch nicht, es müssen noch ein paar Dinge erledigt werden. Dies können wir aber erst machen, wenn das RAID fertig ist mit Daten Umverteilen.

Man kann sich den Fortschritt des Reshape auch ganz bequem anschauen, ohne dass man ständig die mdstat-Datei aufrufen muss. Hierfür gibt es den Watch-Befehl. Der Aufruf sähe so aus:

watch cat /proc/mdstat

Das Terminal-Fenster wird jetzt komplett geleert und die mdstat-Datei angezeigt. Alle zwei Sekunden wird die Anzeige aktualisiert. Die Anzeige der Datei unterbricht man mit STRG+C, somit steht man wieder im Terminal-Fenster und kann weitere Befehle eingeben.

Natürlich macht es keinen Sinn, sich den Fortschritt die ganze Zeit anzugucken, aber wenn man mal über eine Minute sich anschauen will, was da passiert, ist das eine bequemere Lösung, als die Datei ständig immer wieder aufzurufen.

Dateisystem anpassen

Na, das hat ja mal richtig lange gedauert! Anfänglich sah es so aus, als bräuchte er ganze 2 Tage, aber so ab 50 % hat er mal so richtig Gas gegeben und war schon in 1,5 Tagen fertig.

Wir sind aber noch lange nicht fertig damit, das RAID zu erweitern. Bis eben noch sah die 3. Zeile von mdstat so aus:

      7813772544 blocks super 1.2 level 5, 128k chunk, algorithm 2 [5/5] [UUUUU]

Erst, seit der Prozess ganz fertig ist, steht die volle Größe zur Verfügung. Jetzt sieht die Zeile so aus:

      15627545088 blocks super 1.2 level 5, 128k chunk, algorithm 2 [5/5] [UUUUU]

Noch steht uns die volle Kapazität aber nicht zur Verfügung, da müssen wir noch einiges tun.

Dateisystem erweitern

Zwar hat das RAID jetzt eine höhere Kapazität, das Dateisystem ist weiterhin auf 7,3T. Wir haben quasi das bestehende Dateisystem von 3 auf 5 Platten verteilt. Also muss es auf die volle Kapazität erweitert werden.

Um die folgenden Schritte gefahrlos für Daten ausführen zu können, werde ich das Dateisystem aushängen. Dies geht mit folgendem Befehl:

sudo umount /dev/md0

Es könnte sein, dass umount den Dienst verweigert, weil das Dateisystem angeblich noch in Benutzung ist. Dies passiert vor allem dann, wenn man mit seinem Windows-Rechner verbunden war. Um das Problem zu lösen, kann man einfach vorübergehend den Samba-Service stoppen:

sudo service samba stop

Dann sollte auch das Aushängen klappen.

Um Problemen vorzubeugen, werde ich zunächst das Dateisystem auf Fehler prüfen. Klar, es ist noch neu und viel passiert ist ja darauf nicht, aber sicher ist sicher. Also starte ich die Prüfung mit folgendem Befehl:

sudo e2fsck -f -C 0 /dev/md0

Dieser Befehl erzwingt die Fehlerprüfung, auch wenn das Dateisystem als sauber markiert ist, zeigt einen Prozentbalken an und führt die Prüfung auf dem RAID /dev/md0 aus. Mit dem Prozentbalken sehe ich wenigstens, ob das Programm noch arbeitet, oder ob etwas hängt.

Die Dateisystemprüfung war jetzt bei mir problemlos durchgelaufen und keine Fehler gefunden. Also kann ich jetzt das Dateisystem erweitern. Hierzu nehme ich den Befehl:

sudo resize2fs -p /dev/md0

Der Parameter -p zeigt mir wieder einen Fortschritt an, so dass ich sehe, ob das Programm noch was tut. Die Änderung soll auf /dev/md0 ausgeführt werden. Ich habe hier jetzt hinter /dev/md0 keine Größe angegeben. Dann wird das Dateisystem auf die maximal mögliche Größe erweitert. Ich könnte aber natürlich auch eine feste Größe hier eingeben. Das möchte ich aber nicht, sondern ich will die ganze Kapazität für mich alleine! :-) Dieser Vorgang kann eine ganze Weile dauern.

Zur Sicherheit mache ich noch mal eine Dateisystemprüfung, vielleicht ist beim Vergrößern ja was schiefgelaufen? Dafür nehme ich wieder den gleichen Befehl wie oben.

Stride und Stripe-Width

Ihr erinnert euch? Der Stride-Wert ist die Chunk-Größe dividiert durch Dateisystem-Blockgröße. Diese Werte haben sich nicht geändert, also ist es immer noch 128 / 4 = 32. Aber der Stripe-Width-Wert ist der Stride-Wert mal Nutzplatten. Zuerst waren es 2 Nutzplatten, jetzt sind es 4, also 5 Platten minus eine Paritätsplatte, gleich 4. Also hat sich der Stripe-Width-Wert geändert, 32 * 4 = 128. Dies müssen wir dem Dateisystem natürlich auch klar machen.

Diese Werte lassen sich ganz einfach nachträglich anpassen. Hierzu nimmt man das Programm tune2fs. Der Befehl würde hier also so lauten:

sudo tune2fs -E stride=32,stripe-width=128 /dev/md0

Dateisystem mounten

Nun muss das Dateisystem nur noch wieder in den Verzeichnisbaum eingehängt werden. Da das RAID bereits in der fstab-Datei eingetragen ist, ist die Prozedur ziemlich einfach. Der Befehl lautet:

sudo mount /raid1

Und das war es auch schon. Schauen wir doch mal, wie viel Platz wir jetzt haben. Vorher waren es ja 7.3T. Zwischenzeitlich habe ich weiter Daten auf das RAID kopiert, aber mich interessiert ja nur der Wert unter Size. Ich verwende wieder den gleichen df-Befehl wie oben. Jetzt ist der Wert unter Size bei 15T. Ja, das sollte für die nächste Zeit reichen. :-)

Fazit

Wenn man Platz im Server hat, könnte man das RAID noch um wer weiß wie viele Platten erweitern. Ich weiß ehrlich gesagt gar nicht, wo da die Grenze ist. Aber für den Hausgebrauch reicht es alle mal.

Und jetzt noch ganz schnell die Daten vom QNAP kopieren! Weil ich eine der Platten, nämlich die 4-TB-Platte, aus dem RAID-Verbund gepflückt habe, läuft dieses jetzt im degraded mode, also im herabgesetzten Modus. Ich kann drauf schreiben, ich kann davon lesen, aber die Ausfallsicherheit ist dahin! Gut, die platten sind noch nicht alt und ein Ausfall daher nicht zu erwarten, aber sicher ist sicher, je eher ich damit fertig bin, desto besser.

Super, das hat auch geklappt. Nun ist mein Server vollständig einsatzbereit. Das war’s! Nein, natürlich nicht für das Projekt Homeserver im Eigenbau. Aber der erste große Meilenstein, das QNAP NAS zu ersetzen, ist erreicht. Alles, was jetzt kommt, ist Bonus!

Ich habe noch einige Dinge mit dem Server vor. Was sich aber wie bewerkstelligen lässt, wird sich nach und nach ergeben. Daher mache ich jetzt auch erst mal keinen Ausblick darauf, was wohl als nächstes kommt. Das weiß ich selbst noch nicht so genau. Eines der Ziele, die in nächster Zeit angegangen werden, wird wohl ein Webserver sein, der auf dem Server läuft. Nicht, weil ich Webseiten im Internet damit anbieten will, sondern weil ich z. B. von außen auf meine eigenen Daten zugreifen können will, oder vielleicht auch einen CalDAV und CardDAV Dienst für die Synchronisation meiner Handydaten betreiben will. Aber wie gesagt, ob und wie, das muss ich selbst erst noch rausfinden.

Also, auch wenn es jetzt etwas länger dauert, bis wieder ein Beitrag kommt, es kommt sicher noch mehr.

Homeserver 17: Optionen der fstab optimieren

Mein Server ist gerade dabei, das RAID zu erweitern. Das kann noch eine ganze Weile dauern, daher kümmere ich mich mal um ein Thema, dass ich etwas vernachlässigt habe. Ich will die Dateisysteme des Servers etwas optimieren, genauer gesagt, die Optionen in der fstab-Datei.

Optimierungen für die SSD

Wenn man auf der SSD etwas löscht, so wird der Block nicht sofort freigegeben. Das Dateisystem markiert den Block lediglich als “Frei”. Der Controler der SSD selbst, der auch die Speicherverwaltung und die zu beschreibenden Blöcke verwaltet, erfährt davon nichts. Dieser Block, obwohl nicht mehr benötigt, wird ständig weiter mitgeführt und bei Schreiboperationen evtl. weiter mitgeschrieben. Das kann, in gewissem Maße, die Lebensdauer der SSD beeinflussen.

Dafür gibt es den TRIM-Befehl, der solch eine Löschung auch an die Hardware der SSD meldet, so dass der Block wirklich als nicht mehr genutzt markiert wird. Linux unterstützt diesen Befehl, aber nicht standardmäßig.

Für weitere Informationen könnt ihr euch ja den Wikipedia-Artikel zu TRIM durchlesen.

Um die TRIM-Funktion zu aktivieren, fügen wir der fstab die Mount-Option “discard” hinzu.

Eine weitere Optimierung ist, die letzte Zugriffszeit auf eine Datei nicht mitzuprotokollieren. Dies ist zum einen nicht unbedingt nötig, und macht die SSD auch unnötig langsamer. Um dies zu erreichen, fügen wir die Option “noatime” hinzu.

Die fstab-Datei öffnen wir so:

sudo nano /etc/fstab

Ganz unten stehen die Zeilen mit den Dateisystemen, die zum Systemstart automatisch eingehängt werden. Die Zeile für mein Root-Verzeichnis sieht also so aus:

UUID=1d7a581e-f7da-4325-9600-438f4fabb75d /               ext4    errors=remount-ro 0       1

Wenn ich jetzt die oben angegebenen Änderungen durchführe, sieht die Zeile anschließend so aus:

UUID=1d7a581e-f7da-4325-9600-438f4fabb75d /               ext4    errors=remount-ro,discard,noatime 0       1

Beide Parameter, “discard” und “noatime”, zumindest aber “discard”, sollten wir auch in die Swap-Zeile darunter einfügen.

RAID-Optimierung

Hier gibt es nicht so viel zu optimieren. Lediglich die letzte Zugriffszeit auf eine Datei möchte ich nicht automatisch protokollieren, weil dies das RAID zum Einen langsamer macht, und zum Anderen meinen Netzwerkpapierkorb stört.

Wenn ich eine Datei in den Papierkorb lege, also lösche, setzt Linux automatisch den Löschzeitpunkt als letzten Zugriffszeitpunkt. Diese Zugriffszeit nutze ich, um die automatische Leerung des Papierkorbs zu erledigen. Öffne ich die Datei, um zu gucken, ob die wirklich weg kann, aktualisiert sich die Zugriffszeit, und das Löschen dieser Datei aus dem Papierkorb verzögert sich nach hinten.

Insgesamt wird das RAID aber langsamer, weil bei jedem Dateizugriff dieser Wert angepasst wird. Das können durchaus viele Dateizugriffe sein, wenn z. B. ein Batch-Backup läuft. Also empfiehlt es sich hier auch, die Option “noatime” zu setzen. Die Zeile sieht nach der Änderung also so aus:

/dev/md0    /raid1      ext4    noatime,defaults    0   2

Dieser Parameter beeinflusst aber nicht das gewollte Setzen der Zugriffszeit als Löschzeitpunkt. Das funktioniert weiterhin.

Fazit

Nun noch die fstab speichern, fertig. Im Falle des RAID reicht es, es mit umount auszuhängen und wieder mit mount zu mounten. Aber im Falle des Root- und Swap-Dateisystems wird man um ein Reboot nicht herumkommen. Daher sollte man vielleicht gleich einen Reboot machen.

Die Optimierungen fallen vielleicht nicht auf den ersten Blick auf, langfristig wird sich das aber schon bemerkbar machen. Windows ist, zumindest bei meinem Windows 7, standardmäßig so eingestellt, dass es die letzte Zugriffszeit nicht mitschreibt.

So, dann warte ich mal, bis mein Server mit RAID Erweitern fertig ist, dann kommt der Beitrag dazu.

Homeserver 16: Den Server als Time Machine Backupziel nutzen

Der Server hat eine riesengroße Festplatte, also warum nicht auch das TimeMachine-Backup darauf machen lassen? Zur Zeit wird mein TimeMachine-Backup auf meinem QNAP NAS gemacht. In diesem Artikel möchte ich also zwei Dinge tun, zum Einen TimeMachine auf dem Server installieren, zum Anderen meinen bisherigen Backupverlauf vom QNAP auf diesen Server übertragen. Das ist durchaus möglich. Ich habe Anleitungen im Netz gefunden, wie man Backups von einer TimeCapsule zu einer Anderen transferieren kann. Und auch wenn das Backup-Ziel QNAP oder Selbstbauserver heißt, es simuliert letztlich doch nur eine TimeCapsule. Vielleicht klappt es ja…

Vorbereitungen

Zunächst einmal muss auf dem RAID ein Verzeichnis angelegt werden, in dem das TimeMachine sein Backup speichert. Ich befinde mich bereits im Hauptverzeichnis /raid1.

sudo mkdir timemachine
sudo chown -c -R kamil:kamil timemachine

Somit wurde das Verzeichnis unter /raid1/timemachine erstellt und das Eigentum an mich übertragen.

Nun muss noch das Paket installiert werden, welches das AFP-Protokoll spricht, welches der Mac benötigt.

sudo apt-get install netatalk

Damit TimeMachine funktioniert, muss es noch konfiguriert werden. Dazu muss die Datei /etc/netatalk/AppleVolumes.default editiert werden.

sudo nano /etc/netatalk/AppleVolumes.default

Nun muss ganz unten an die Datei folgende Zeile hinzugefügt werden:

/raid1/timemachine "TimeMachine" allow:kamil options:usedots,upriv,tm cnidscheme:dbd volsizelimit:500000

Alle Optionen habe ich auch nicht verstanden. Nur das Erste ist der Pfad zu dem Verzeichnis, wo das Backup angelegt werden soll. Danach, in Anführungszeichen, der Name, wie es erscheinen soll. Der Parameter Allow bestimmt einen User, für den das TimeMachine angezeigt werden soll, hier solltet ihr einen User eintragen, der auch an eurem Mac eingerichtet ist. Der letzte Wert legt die Größe des TimeMachine-Backuplaufwerks fest. Ich habe zwar nur 500 Megabyte angegeben, aber für meinen Fall reicht das dicke. Die meisten Daten habe ich sowieso auf dem NAS und dem Mac gleichzeitig, da muss es nicht auch noch im TimeMachine-Backup vorhanden sein. Daher sind meine Backups immer recht klein.

Nun starten wir mal den Service neu.

sudo service netatalk restart

Unglaublich, aber auf der Server-Seite war es das schon! :-) Von jetzt geht es am Mac weiter.

TimeMachine auf dem Mac Konfigurieren

Das Laufwerk des Servers für die TimeMachine-Backups auszuwählen läuft auch nicht anders, als jede andere TimeCapsule oder QNAP NAS als Backup-Ziel auszuwählen.

Ich habe meine Anleitung übrigens von dieser Seite, wo noch beschrieben wird, dass im Terminal was eingegeben werden muss, damit Mac OS den Server sieht. Er hat das dort mit Mavericks gemacht, ich habe bereits Yosemite installiert. Es scheint hier nicht weiter nötig zu sein, im Terminal was einzugeben, der Server wird sofort gesehen.

Ich werde jetzt im nächsten Schritt nicht nur das TimeMachine-Backup auf dem Mac konfigurieren, sondern auch den bisherigen Backupverlauf auf den neuen Server zu ziehen versuchen.

Server als TimeMachine auswählen

Damit mein MacBook sein TimeMachine-Backup auf dem Server machen kann, müssen wir das Laufwerk dafür festlegen. Hierzu gehe ich mit der Tastenkombination VO+MM in den Statusbereich und wandere mit VO+Pfeil-rechts zu TimeMachine. Mit VO+Leertaste öffne ich das Menü und gehe auf “Systemeinstellung Time Machine öffnen”.

In diesem Dialog suche ich mir die Taste “Volume wechseln” und aktiviere diese. Nun dauert es eine kleine Weile, bis die einzelnen, über das Netzwerk erreichbaren, TimeMachine-Laufwerke angezeigt werden. Ich wähle “TimeMachine auf Server01″ aus. Die Option, das Backup zu verschlüsseln, kann jeder so setzen, wie er mag. Anschließend gehe ich auf den Schalter “Volume verwenden” und aktiviere diesen.

Es öffnet sich nun ein Fenster, wo ihr nach Benutzernamen und Passwort gefragt werdet. Ich gebe hier die Daten an, die ich auch zum Anmelden auf den Server benötige.

Wenn ihr einen komplett neuen Backupsatz anfangen wollt, und keinen älteren Backupsatz von einer TimeCapsule oder NAS kopieren wollt, war es das schon. Euer Mac wird in Zukunft seine Backups auf dem neuen Server durchführen.

Backupsatz vom QNAP NAS übernehmen

Nun beginnt ein Sekundenzähler zu zählen, nachdem das erste Backup erstellt wird. Ich warte ab, bis das Backup anfängt, und tatsächlich auch Daten übertragen werden. Das ist wichtig, damit auf dem Server die entsprechenden Strukturen erstellt werden.

Der Status ist im Fenster der TimeMachine-Einstellungen direkt über der Taste “Volume wechseln” zu sehen. Zuerst steht da, “Backup Volume suchen”, anschließend “Backup vorbereiten”. Sobald der Status zu “Backup erstellen” wechselt, und tatsächlich Daten kopiert werden, gehe ich auf die Schaltfläche “Stopp” darüber und breche das Backup ab. Anschließend suche ich mir die Taste “Aus”, um die automatischen Backups abzuschalten.

Warum das alles?

Jetzt sind auf dem Server die Strukturen erstellt, damit die Freigabe “TimeMachine” tatsächlich auch als TimeMachine fungieren kann. Die automatischen Backups habe ich ausgeschaltet, da während des Kopiervorganges des alten Backups vom QNAP-NAS auf gar keinen Fall ein weiteres Backup angelegt werden darf!

Backupverlauf vom QNAP übernehmen

Als ich die Anleitung gelesen hatte, erschien mir das ziemlich kompliziert. Jetzt, wo ich vor dem Mac sitze und das ausprobiere, wirkt das gar nicht mehr so komplex. Hier mal die Schritte:

Ich öffne irgendein Finder-Fenster, zum Beispiel das Home-Verzeichnis mit Befehl+Shift+H. Nun stoppe ich die Interaktion mit der Listenansicht und gehe mit VO+Pfeil-links zur Seitenleiste. Mit dieser interagiere ich.

Relativ weit unten befindet sich eine Freigabe, die sich “QNAP – Timemachine” nennt. Je nach dem, wie ihr euer QNAP NAS benannt habt, könnte es auch etwas anders heißen. Jedenfalls navigiere ich mit VO+Pfeil-rechts dort hin, drücke VO+Leertaste und beende die Interaktion mit der Seitenleiste. Wenn ich jetzt mit VO+Pfeil-rechts wandere, komme ich auf eine Taste, die sich “Verbinden als” nennt, die drücke ich mit VO+Leertaste.

Nun öffnet sich ein Fenster, in das ich Benutzernamen und Kennwort eingeben soll. Bei QNAP ist der Benutzer für die TimeMachine “timemachine”. In das Passwort-Feld tragt ihr das Kennwort ein, welches ihr auf der QNAP-Oberfläche für die TimeMachine festgelegt habt. Anschließend drückt ihr einfach Enter. Nun sollte in der Listenansicht “TMBackup” erscheinen. Das ist ein Ordner, den wir mit Befehl+Pfeil-runter öffnen. Damit haben wir es gemounted, so dass er als Symbol auf dem Desktop zu sehen ist.

Das Gleiche müssen wir jetzt noch mit server01 machen, um uns auch mit dessen TimeMachine zu verbinden. Ich gehe also wieder in die Seitenleiste, interagiere damit, und suche “server01″. Hier drücke ich wieder VO+Leertaste, stoppe die Interaktion mit der Seitenleiste und gehe wieder zum Schalter “Verbinden als”. Das Kennwort und der Benutzername sind die gleichen Daten, mit denen ich mich auf dem Server anmelde. Hier befinden sich dann sogar zwei Ordner, wobei mich aber nur der Ordner “TimeMachine” interessiert. Auch hier gehe ich mit Befehl+Pfeil-runter rein. Auch dieses Verzeichnis ist nun mit einem Symbol auf meinem Schreibtisch vertreten.

Laut eines englischen Support-Artikels von Apple sollte es also ausreichen, wenn ich das eine Volume auf das andere kopiere, also mache ich das doch mal…

Ich gehe also auf das Volume “TMBackup Volume” und öffne es mit Befehl+O. Hierin befindet sich eine Sparsebundle-Datei, die je nach dem Namen eures MacBooks anders heißen kann. Diese copiere ich mit Befehl+C. Nun kann ich dieses Fenster mit Befehl+W wieder schließen.

Anschließend gehe ich auf das “TimeMachine Volume” und öffne es mit Befehl+O. Hier setze ich das Sparsebundle mit Befehl+V ein.

Der Kopiervorgang startet. Je nach Größe des alten Backups kann es eine sehr lange Zeit dauern, bis die Daten kopiert sind.

Wenn das Kopieren beendet ist, schließe ich die Finder-Fenster, die noch offen sind, und werfe beide Volumes, TMBackup und TimeMachine mit Befehl+e aus.

Funktionalität überprüfen

Oh man, 8 Stunden, wieso habe ich das MacBook nicht mit einem Kabel ans Netz gehängt? Naja, nu is es passiert, und das Kopieren war erst mal erfolgreich. Aber funktioniert es denn nun auch? Das werden wir jetzt überprüfen.

Wiederherstellungsumgebung

Was nutzt uns das beste Backup, wenn wir unseren Mac nach einem Totalausfall nicht von der Recovery-Umgebung aus wiederherstellen können? Um sicherzugehen, dass unser Server das Backup auch über die Recovery-Umgebung wiederherstellen kann, gehen wir mal kurz da rein. Ich werde das Backup nicht wiederherstellen, ich will nur sehen, ob ich den Server ansprechen und die Liste der Backups angezeigt bekomme.

Um dies zu tun, müssen wir den Mac im Recovery-Modus starten. Geht mit VO+M in die Menüzeile, dort auf das Apple-Menü, hier weit unten auf Neustart. Der Mac fährt jetzt runter. Wenn er neu startet, ertönt der Mac-Einschaltton. Sobald ihr den hört, drückt ihr Befehl+r für eine ganze Weile, so um die 15 Sekunden sollten ausreichen. Da man nicht wirklich hören kann, wann die Recovery-Umgebung gestartet ist, warte ich immer so um die 1 Minute, dann drücke ich Befehl+F5, um VoiceOver zu starten.

Nun stehe ich in einer Tabelle, aus der ich eine ganze Reihe von Optionen auswählen kann. Die oberste Option ist “Aus Time Machine Backup wiederherstellen”. Das will ich ja gerade sehen, ob das geht. Also gehe ich mit VO+rechts auf “Fortfahren button” und drücke VO+Leertaste. Das sich nun öffnende Informationsfenster übergehe ich, indem ich wieder auf “Fortfahren” gehe und mit VO+Leertaste aktiviere.

Nun öffnet sich ein Fenster, in dem ich das Backup-Laufwerk auswählen kann. Angeboten werden mir die TimeMachine auf meinem server01 und TMBackup auf meinem QNAP NAS. Ich wähle TimeMachine auf server01. Anschließend gehe ich mit VO+rechts auf die Schaltfläche “Verbinden” und aktiviere diese. Es öffnet sich ein Fenster, in dem ich Benutzername und Passwort meines Benutzers auf dem Server eingebe und Enter drücke.

Es kann nun in der Tat eine ganze Weile dauern, bis das Dienstprogramm den Server nach den Backups durchsucht. Bei mir hat es fast 2 Minuten gedauert, also nicht gleich ungeduldig werden. Jedenfalls hat sich dann ein Fenster geöffnet, aus dem ich das Backup auswählen soll. Bei mir ist es “Kamils MacBook Pro auf TimeMachine”. Dann gehe ich wieder auf die Schaltfläche “Fortfahren”.

Jetzt öffnet sich in der Tat eine Liste meiner Backups. Das neueste, von heute Morgen um 06:15 Uhr, steht dabei ganz oben.

Weiter werde ich hier nicht gehen. Es ist klar, dass mein Mac die Backups findet und auch wiederherstellen würde, wenn ich jetzt weiter auf “Fortfahren” ginge. Das will ich ja nicht, ich wollte nur sehen, ob die Backups gefunden werden. Also schließe ich die Wiederherstellung mit Befehl+q. Auch die Recovery-Umgebung beende ich mit Befehl+q und bestätige die Abfrage zum Neustart.

Backup-Integrität prüfen

Nun will ich noch schnell prüfen, ob das Backup auch wirklich in Ordnung ist. Dass es da ist und auch angezeigt wird, heißt ja noch nicht, dass der Kopiervorgang auch wirklich sauber durchgelaufen ist. In regelmäßigen Abständen macht Mac OS X diese Prüfung automatisch, aber ich kann sie auch manuell anstoßen.

Mit VO+MM gehe ich in den Statusbereich und bewege mich mit VO+Rechts zu “Time Machine”. Mit VO+Leertaste öffne ich das Menü und gehe mit Pfeil runter auf “Backup jetzt erstellen”. Ich will ja kein Backup erstellen, daher drücke ich auch nicht Enter. Aber wenn ich jetzt die Wahltaste drücke, ändert sich der Befehl in “Backups überprüfen”. Genau das will ich, daher drücke ich Wahl+Enter. Die Überprüfung beginnt, und ich warte ab, ob es mir Fehler meldet. Dieser Vorgang kann auch eine ganze Weile dauern. Im Statusmenü für Time Machine kann man immer sehen, wie weit er schon ist.

Fazit

Die Überprüfung war erfolgreich, somit hat Einrichtung und Kopieren geklappt. Der Server ist nun mein TimeMachine-Backupziel. Daher stelle ich die automatische Sicherung in den Systemeinstellungen für Time Machine auch wieder auf ein.

Zuvor jedoch mache ich, nur um sicher zu gehen, ein manuelles Backup. Hierbei kann es passieren, dass ein Fenster aufgeht, welches euch darüber informiert, dass sich die Identität des Backup-Volumes geändert hat. Dies ist ja auch klar, wir haben es ja von einem anderen Server hier her kopiert. Daher ignoriere ich die Warnung und gehe auf die Schaltfläche “Dieses Volume verwenden”. Anschließend dauert es eine Weile, bis das Backup beginnt, da Time Machine es erst noch neu indizieren muss.

Eine Aufgabe weniger, die mein QNAP erledigen muss. Um genau zu sein, noch habe ich auf den Server nicht alle Daten kopiert. Wenn das aber passiert ist, wird das QNAP NAS nicht mehr gebraucht. Ich weiß noch nicht, was ich dann damit mache. Wahrscheinlich benutze ich es dann nur noch, um meine Daten zu sichern, wie ich schon sagte, ein Backup haben ist dreiviertel der Miete. :-)