OpenMediaVault: Umstieg auf RAID

Nachdem ich mich wegen der zusätzlichen Komplexität zuerst gegen ein RAID System entschieden habe, ist in mir der Entschluss gereift, es nun doch zu wagen. Den Umstieg von OpenMediaVault auf RAID möchte ich hier ausführlich dokumentieren. Doch langsa...

Nachdem ich mich wegen der zusätzlichen Komplexität zuerst gegen ein RAID System entschieden habe, ist in mir der Entschluss gereift, es nun doch zu wagen. Den Umstieg von OpenMediaVault auf RAID möchte ich hier ausführlich dokumentieren. Doch langsam, zuerst einmal die Vor- und Nachteile eines RAID-Systems.

Vorüberlegungen

Vorteile RAID

Ein RAID (Redundant Array of Independent Disks)  ist ein Verbund mehrerer Festplatten. Es gibt unterschiedliche RAID-Levels, sie hier alle zu erläutern würde den Rahmen des Artikels sprengen. Ich empfehle die Beschreibung bei Wikipedia. Abgesehen von RAID-0 hat  man bei RAID immer eine Redundanz, d.h. es kann eine (oder auch mehrere) Platte ausfallen, ohne dass Daten verloren gehen. Ich habe mich hier für ein RAID-5 entschieden.

  • Man hat einen großen, virtuellen Datenträger und muss sich nicht um die Festplatteneinteilung kümmern. Platten können nicht zu klein werden, denn man kann das RAID später einfach erweitern.
  • Bei Ausfällen bekommt man eine Warnung und kann die defekte Platte einfach austauschen. Die Redundanz wird dann von alleine wiederhergestellt. Das ist gerade auch deshalb interessant, weil Platten in einem NAS durch den 24/7 Betrieb stark belastet werden.
  • BEI RAID-5 hat man bei 3 x 1TB Platten eine Kapazität von 2 TB. 1 TB ist Parität. Dieses Verhältnis ist besser als z.B. bei RAID -1. Hier fiele die Hälfte der Kapazität weg.
  • Die Performance ist besser als bei RAID-1, allerdings die CPU-Last höher, wegen der Paritätsberechnung.

Nachteile RAID

  • Höherer Stromverbrauch, da immer drei Festplatten rotieren. Ohne RAID könnten vielleicht zwei davon schlafen.
  • Man braucht für RAID 5 mindestens drei Platten. Die Kapazität des RAID-5 richtet sich dann nach der Kleinsten.
  • Eine zusätzliche Abstraktionsebene, dies spielt vorallem bei der Datenrettung eine Rolle.
  • Hohe Kosten für RAID-Hardware, ich setze aber auf ein OS-RAID, das kostet nichts und ist nur wenig langsamer.

Ich finde die Vorteile überwiegen hier ganz klar, gerade wenn der Server zuverlässig sein soll. Die Datenrettung ist hier auch nicht so problematisch wie bei einem Hardware- oder BIOS-RAID, weil nur die Software eine Rolle spielt.

Festplatten

Als Platten habe ich zwei WD Caviar Green 1TB
und eine WD Caviar Red 2TB
im Einsatz. Die Green-Platten sind für den Einsatz im NAS eigentlich nicht so gut geeignet, aber sie tun ihren Dienst. Die Unterschiede liegen neben der aus Dauerbetrieb ausgelegten Hardware vorwiegend in der Software, die dann z.B. bei den Red-Platten schneller meldet, dass ein Block nicht gefunden wurde. Das OS holt sich diesen Block dann von einer anderen Platte. Im Heimbetrieb hat man ja i.d.R. auch keinen 24/7 Dauerbetrieb der Platten, weil sie sich nach 30min Inaktivität schlafen legen.

RAID-Methoden

RAID-Adapter / Hardware-RAID

Im professionellen Umfeld werden spezielle PCIe-Steckkarten eingesetzt. Diese sind beim Aufbauen und Wiederherstellen des RAID deutlich schneller, kosten aber mehrere 100 €. Die Hersteller halten diese TEile lange vorrätig, denn bei einem Fehler könnte käme man sonst nicht mehr an seine Daten.

BIOS-RAID

Viele BIOS-Setups erlauben die Einrichtung eines RAID, das dann vom Betriebssystem unabhängig ist. So kann das gesamte OS auf ein RAID installiert werden. Von dieser MEthode ist aber abzuraten, denn im Fehlerfall darf man das exakt gleiche Motherboard finden. Dies ist schon nach 2 Jahren kaum noch möglich. Von der Geschwindigkeit her ähnlich dem OS-RAID.

Betriebssystem-RAID

Diese Variantesetzt ein RAID-fähiges Betriebssystem vorraus. Es ist eine reine Software-Lösung. performancemäßig sicher nicht die schnellste Variante, aber besser als das BIOS-RAID. Diese Methode setze ich ein.

Backup

Für die RAID-Einrichtung müssen die Platten komplett gelöscht werden. Deshalb ist ein Backup vonnöten. Ich nutze meinen Server für vielerlei Daten. Auf den zwei bestehenden 1 TB Platten sind jeweils um die 450 GB belegt. Sie sollen auf eine externe 1,7 TB USB3 Platte. Doch diese ist unversehens voll, obwohl der Platz doch gut reichen sollte. Was ist passiert?

Für das Backup meiner Linux-Rechner nutzte ich Backintime. Dieses sehr nützliche Tool erzeugt Hard-Links um Speicherplatz zu sparen. Für das Backup auf die externe Platte habe ich rsync benutzt. Dieses setzt hard-Links standardmäßig überhaupt nicht um sondern kopiert die gleiche Datei zigmal. Dies lässt dich durch die Option -H verhindern. Die Berechnung ist allerdings aufwändig.

Ein weiterer Punkt warenFestplattenabbilder von VirtualBox. Diese nutzen Sparse-Images, d.h. der Platz wird nur soweit belegt wie notwendig. Auch damit kann rsync standardmäßig nicht umgehen und erzeugte so zigfach 20 GB große Dateien. Die Option –sparse schafft Abhilfe.

Letztlich lautet der Aufruf

rsync -avpH --sparse <Quelle> <Ziel>

Die Optionen -H und –sparse muss man in den zusätzlichen Optionen des USB-Datensicherungs-Plugins von OpenMediaVault manuell eingeben. Dieses Plugin hat den Vorteil, dass das Kopieren von selbst läuft und nicht der PC wegen SSH mitlaufen muss. Denn das Kopieren von 1 TB dauert einen 3-4h. Deshalb sollte man auf garkeinen Fall USB2-Platten benutzen! Diese übertragen nur magere 25 MB/s.

RAID einrichten

Sind die Daten gesichert, muss man in OpenMediaVault sämtliche Freigaben löschen und bei den Diensten entfernen. Ansonsten kann man die Platte nicht löschen. Das ist leider sehr umständlich gelöst. Ich brauchte eine halbe Stunde bis ich die letzte Stelle gefunden hatte, wo noch eine Freigabe eingetragen war.

Hat man das geschafft, kann man unter Datenspeicher > Raid-Verwaltung das RAID erzeugen. Die Festplatten werden dann Bit für Bit überschrieben, was wieder sehr lange dauert. Kleiner Platten gehen schneller als große.

Ist dieser Vorgang abgeschlossen, formatiert man den RAID-Verbund noch mit EXT4 und kann seine Daten dann zurückspielen und die Freigaben ggfs. wieder einschalten.

Es lohnt sich übrigens, sich ein Schema zu überlegen wo welche Daten abgelegt werden. Dienste, die über das Internet erreichbar sind oder wie mysql häufig gebraucht werden, liegen bei mir auf der Systemplatte, damit nicht immer die großen Festplatten anspringen. Auf dem RAID liegen Backups, Home-Verzeichnisse, Medien-Dateien usw.

Ergebnisse

Vor dem RAID-Umstieg erreichte ich bei Rsync-Backups (backintime) maximal 95 MB/s. Mit RAID sind Werte von 113 MB/s normal, ich habe auch schon Spitzen von 118 MB/s gesehen.  Das liegt sehr nahe am theoretischen Maximum von Gigabit Ethernet (125 MB/s). Die CPU Last auf dem Server (Dual Core Xeon, 2,3 GHz, 4 GB RAM) pendelt sich dann bei 40 und 50% ein. Das liegt an der Paritätsberechnung. Beim internen Kopieren von einer USB3-Platte lag die CPU Last sogar bei 70%. Diese Daten zeigen, dass mit meinem alten Prozessor, dem Celeron kein RAID5 zu machen gewesen wäre. Er lag ja schon im Leerlauf bei 20% Last.

Der Stromverbrauch bei Leerlauf stieg wegen der dritten Platte von 36 auf 40 W. Beim internen Kopiervorgang schluckte das System 72 W. Im Betrieb bei Netzwerkzugriffen sind es 43 W.

 

 

OwnCloud auf Speed

Seit einigen Wochen habe ich eine OwnCloud 8 Installation auf dem MicroServer am Laufen. In dieser OwnCloud habe ich mein 27 GB großes Bildarchiv abgelegt, da man es auf diese Weise auf allen Rechnern zur Verfügung hat. Die Geschwindigkeit der Synchr...

Seit einigen Wochen habe ich eine OwnCloud 8 Installation auf dem MicroServer am Laufen. In dieser OwnCloud habe ich mein 27 GB großes Bildarchiv abgelegt, da man es auf diese Weise auf allen Rechnern zur Verfügung hat. Die Geschwindigkeit der Synchronisation hat mich allerdings bisher nicht wirklich überzeugt. Sie ist nicht mit einem rsync auf den gleichen Server zu vergleichen. Rsync lastet die Gigabit Ethernet Verbindung fast komplett aus. OwnCloud dagegen schlummert mit maximal wenigen MB/s vor sich hin. Und scheint zwischen den einzelnen Dateien eine großzugige Pause einzulegen. In diesem Artikel habe ich einige Tricks und Kniffe gesammelt, die helfen OwnCloud schneller zu machen. 

Optimierungen am Netzwerk

Mein Server hängt an einer FritzBox, für die ich den DynDNS-Dienst myFritz von AVM benutze. Weil das Zertifikat auf die DynDNS-Domain ausgestellt wurde, muss man in den OwnCloud Clients die Domain eintragen. Dadurch werden Anfragen aber über das Internet geroutet:

$ traceroute to xxxx.myfritz.net (109.42.xxx.xx), 30 hops max, 60 byte packets
 1 fritz.box (192.168.179.1) 0.347 ms 0.426 ms 0.504 ms
 2 ip-109-42-xxx-xx.web.vodafone.de (109.42.xxx.xx) 3.973 ms !X 3.982 ms !X 3.979 ms !X

Man beachte die langen Latenzen (Mobilfunk). Trägt man nun in der /etc/hosts Datei folgendes ein

192.168.179.28 xxxx.myfritz.net

liefert traceroute eine Latenz von unter einer Millisekunde und routet direkt zum Ziel. Bei IPv6 ist dieser Schritt übrigens nicht nötig, Der Router erkennt dann von selbst, dass diejenige IP ‚ihm gehört‘ und fragt garnicht erst den DNS Server des Hosters. Dazu muss man aber eine IPv6 Adresse vom Provider erhalten haben und auch im Heimnetz solche IPs per DHCPv6 verteilen. OpenMediaVault hat mit IPv6 leider noch seine Probleme. Auch auf manchen Android-Geräten scheint IPv6 fehlerhaft implementiert, wie mir AVM bestätigte.

Update 21.04.2015:  Im WLAN blockierte bei mir die FritzBox die Auflösung des Domainnamens. Owncloud funktionierte dadurch im WLAN nicht (ohne hosts-Eintrag). Um das zu ändern, muss man den DNS-Rebind-Schutz für diese Domain deaktivieren. Das geht unter Heimnetz > Netzwerkeinstellungen.

Update 28.05.2016: Es gibt leider ein ernstzunehmendes Problem mit IPv6. Die Owncloud-App für Android hat im WLAN einen Bug, es kommt keine Verbindung zustande. Dieser Bug wird hier  getrackt und hoffentlich bald gefixt. Wenn man diesen Bug kennt, kann man Die App halt nur noch von draussen nutzen. Nervig ist es nur für den Foto-Upload.

 

Eine weitere gute Idee ist auch das aktivieren von Jumboframes. Standardmäßig ist die Nutzlast (Maximum Transfer Unit – MTU) bei Ethernet auf 1500 Bytes beschränkt. Dieser Wert wird aber vorallem aus Gründen der Abwärtskompatibilität benutzt. Bei Gigabit Ethernet sollte ein größerer MTU kein Problem sein. Dazu muss man auf beiden Seiten der Verbindung

$ sudo ifconfig eth0 mtu 9000

setzen. Diese Änderung ist erstmal nicht permanent. Um die festzuklopfen,  ändert man den MTU-Wert in der Datei /etc/network/interfaces. Ich kann allerdings nicht versprechen, dass alle Umgebungen damit klar kommen.

Update:  FritzBoxen können überhaupt nicht mit JumboFrames umgehen. Sehr schade. Das erklärt auch meine Verbindungsabbrüche, wenn ich sie aktiviert habe.

Optimierungen bei OwnCloud

OwnCloud ist out-of-the-Box sehr konservativ eingestellt und vorallem so ausgelegt, dass es auf auf Webservern läuft, wo man keine Rootrechte hat. Zuhause sollte man unbedingt folgende Änderungen machen:

  1. von AJAX auf richtige Cronjobs umstellen. Das beschleunigt aber vorallem die Weboberfläche.
  2. Statt SQLite eine richtige mySQL-Datenbank einsetzen. Diese hat erheblich mehr Performance.
  3. Die mySQL Einstellungen optimieren
  4. Ein PHP Cache Paket installieren, z.B. PHP APC. Dieses soll zumindest die Weboberfläche um den Faktor 3 beschleunigen.
  5. Umgebungsvariablen für den Owncloud Client setzen.
  6. Update: PHP-FPM und NGINX besser konfigurieren

Cronjobs

Für die Cronjobs benutzt man auf einem Debian den Befehl

$ sudo -u www-data crontab -e

Dies bearbeitet die Cronjobs des Benutzers www-date. Das ist wegen den Rechten wichtig. Dort trägt man die Zeile

*/20 * * * * php -f /var/www/owncloud/cron.php

ein. Dadurch wird dann alle 20min der Owncloud-Cronjob ausgeführt. In der Administrationsoberfläche kann man dann von AJAX auf Cron umstellen und prüfen, ob der Cronjob ausgeführt wird.

Umziehen auf eine MySQL-Datenbank

Das Umstieg von der Dateibasierten sqlite-Datenbank auf mySQL ist komplizierter. Man muss sich damit gut mit mySQL auskennen. Hier gibt es eine Anleitung für OC7. Im Prinzip muss man wie folgt vorgehen:

Das Paket mysql-server installieren

sudo apt-get mysql-server

Bei der Installation vergibt man das Root-Passwort. Nun verhindet man sich mit der Konsole:

$ mysql -u root -p

Man sollte für OC einen eigenen Benutzer haben, der nur auf die OC-Datenbank zugreifen kann. Dazu benutzt man folgende mySQL Befehle

CREATE DATABASE <dbname>
CREATE USER <username>@localhost IDENTIFIED BY <password>

Die Rechte an der Datenbank gibt man dem neun Benutzer mit

GRANT ALL PRIVILEGES ON <dbname> . * TO <username>@localhost;

Verlassen kann man die mySQL Konsole mit exit; Nun das Skript /var/www/owncloud/occ ausführbar machen und ausführen:

$ sudo -u www-data chmod +x occ 
$.sudo -u www-data /occ db:convert-type –password=”<password>” –all-apps <username> localhost <dbname>

MySQL Einstellungen optimieren

Das Skript mySQLTuner gibt Tipps, was man verbessern kann. Die Einstellungen einer mySQL-Datenbank befinden sich unter Debian in /etc/mysql5/my.cnf. Nach Änderungen an dieser Datei muss man mySQL neustarten.

Folgende Variablen habe ich geändert. Mein Server hat 4 GB RAM.

  • innodb_buffer_pool_size von 128 MB auf 1 GB
  • query_cache_size von 16 MB auf 64 MB
  • tmp_table_size von 16 MB auf 32 MB
  • max_heap_table_size von 16 MB auf 32 MB

Variablen zeigt man auf der mySQL Konsole so an und kann sie auch ändern:

> SHOW VARIABLES LIKE 'query_cache_size';
> SET GLOBAL query_cache_size = 33554432;

Diese Änderungen verfallen aber nach einem Neustart. Will man sie behalten, muss man sie in der my.cnf eintragen. Man sollte sich immer informieren, welche Werte gut sind. Viel hilft nicht immer mehr! Manche Caches sollten eine bestimmte Größe nicht überschreiten

PHP Cache aktivieren

Dazu muss man lediglich die entsprechenden Pakete installieren und den Webserver neustarten

$ sudo apt-get install php-pear php-apc $ sudo service nginx restart

Konfigurieren muss man eigentlich nichts. Der Cache verbessert die Verarbeitungszeit der PHP-Skripte auf dem Server um etwa den Faktor 2x. Das ist natürlich insbesondere für dien Zugriff via Browser gut, aber auch der Sync-Client nutzt letztendlich HTTP-Aufrufe von PHP Skripten zur Dateiübertragung.

Umgebungsvariablen setzen

Bei Owncloud ist der Upload über den Browser erheblich schneller als über den Client. Dies liegt unter anderem daran, dass der Client seine Uploads in sog. Chunks einteilt, die standardmäßig nur 10 MB groß sind. Eine automatische Anpassung an die tatsächliche Bandbreite findet leider nicht statt. Man sieht dies sehr schön, wenn man in der Systemüberwachung den Netzwerkverkehr anzeigt.

Die Umgebungsvariable OWNCLOUD_CHUNK_SIZE ändert ihr  unter Linux in der .profile

OWNCLOUD_CHUNK_SIZE=104857600
export OWNCLOUD_CHUNK_SIZE

Dieser Wert entspricht 100 MB und ist für Gigabit Ethernet ausgelegt. Danach einmal abmelden und ihr solltet ordentliche Uploadraten mit dem Client erhalten.

Man sollte auch immer bedenken, dass die hier genannten hohen Geschwindigkeiten nur mit großen Dateien an einem Stück zustande kommen. Bei Bildarchiven z.B. macht OC trotz der Chunksize zu viele Unterbrechungen. Das wird mit folgender Grafik klar (Chunk Size=50 MB, viele 4-6MB große Dateien):

Owncloud Netzwerkstatistik
Owncloud Network Speed

Update: PHP-FPM und NGINX

Bei einem anderen Projekt habe ich gesehen, dass die Anzahl der Prozesse, die PHP-FPM starten darf, zu gering war. Es treten dann Warnungen in den Logfiles auf. Man sollte die Einstellung erhöhen, bis keine Warnungen mehr auftreten.

# /etc/php5/fpm/pool.d<dein-pool>.conf
pm = ondemand
pm.max_children = 32
pm.max_requests = 200
pm.process_idle_timeout = 10s

Diese Einstellungen sind beispielhaft. Durch die Einstellung ondemand werden Prozesse bei Bedarf erzeugt und nicht vorgehalten, was bei Umgebungen mit relativ geringer Last weniger RAM verbraucht [Quelle].

Als Webserver nutze ich Nginx. Bei Apache gibt es natürlich ähnliche Optionen, da verweise ich aber auf Google. Auch in den NGINX-Einstellungen kann man etwas optimieren:

# /etc/ngins/nginx.conf
worker_processes 4; # i.d.R. die Anzahl der CPU-Kerne
gzip on;
gzip_disable „msie6“; # IE 6 deaktivieren
gzip_vary on;
gzip_min_length 10240; # erst ab 10 KB komprimieren
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript # nur Textdateien komprimieren, keine Bilder etc.

Dies verbessert die Performence bei der Komprimierung, da nicht ,mehr jede noch so kleine Datei komprimiert wird. Das Komprimieren von Bildern, Videos usw. kostet nur CPU-Leistung, bringt aber wenig. Daher nur bei Text-Dateien.

Es gibt noch sehr viele andere Einstellungen. Ich möchte hier nur einen Anreiz geben, sich dort einzuarbeiten.

 

Fazit

Nach allen Optimierungen erreiche ich Raten von 50-60 MB/s, (abhängig von der Dateigröße und nicht durchgehend). Die Änderung der Umgebungsvariablen und der Caches auf dem Server hat am meisten gebracht, auch das Routing hatte seinen Anteil. Meine 4 GB RAM auf dem Server sind nun deutlich voller (25% vs. 16%). OwnCloud erzeugt sehr viel Overhead durch die Datenbank, daher lässt sich die Geschwindigkeit nicht mit rsync vergleichen. Für Heimnetz-Geschwindigkeiten ist OwnCloud nicht ausgelegt, aber die Uploadgeschwindigkeit ist trotzdem erheblich besser als per VDSL auf einen fremden Server.

Die Einstellungen bei PHP-FPM und NGINX haben gefühlt etwas mehr Performance gebracht, ich hatte aber auch einen viel zu niedrigen Wert für die Anzahl der Prozesse voreingestellt.

Die Quelle meiner gesammelten Informationen möchte ich euch nicht vorenthalten. Das generelle Problem bei Internetrecherchen zu diesem Thema ist aber, dass sie meistens ältere OC Versionen betreffen.

 

 

Passwortverwaltung mit Owncloud und KeePass 2

Früher hbe ich den komfortablen Passwortmanager LastPass empfohlen. Nun habe ich jedoch einen eigenen Server am Start, mit dem man sehr viel mehr Möglichkeiten hat und nicht mehr einem Drittanbieter vertrauen muss. Durch Owncloud gibt es eine einfach...

Früher hbe ich den komfortablen Passwortmanager LastPass empfohlen. Nun habe ich jedoch einen eigenen Server am Start, mit dem man sehr viel mehr Möglichkeiten hat und nicht mehr einem Drittanbieter vertrauen muss.

Durch Owncloud gibt es eine einfache und zuverlässige Lösung, die Passwort-Datei auf allen Geräten synchron zu halten. Wer keinen eigenen Server hat, kann die Datei aber natürlich auch in der Dropbox speichern, muss dann aber damit leben, dass seine Passwörter – wenn auch verschlüsselt – auf einem Server in den USA liegen.

Es gibt zwar erste Versionen von dedizierten PAsswort-Apps für Owncloud, ich setze bei solchen neuralgischen Sachen aber lieber auf altbewährtes. Mit KeePass 2 konnte ich mich inzwischen so weit anfreunden, dass ich es unter Linux einsetzen kann. Zwar ist die Windows-Emulation via Mono alles andere als schön, aber sie funktioniert. Vorteil von KeePass ist, dass es OpenSource ist und es daher eine Vielzahl von Plugins und Forks für alle denkbaren Plattformen gibt.

die Installation unter Ubuntu ist schnell gemacht

$ sudo apt-get install keepass2 mono-complete

Zu meiner Entscheidung hat auch beigetragen, dass mein Lieblingsbrowser Opera nun auf Chrome basiert und dadurch mit Trick 17 auch Chrome Apps in Opera installiert werden können. Bisher gab es nur für LastPass eine Erweiterung für Opera. Mit der Erweiterung ChromeIPass kann man nun in Chrome bzw. Opera sehr komfortabel auf die Passwortdatenbank in KeePass 2 zugreifen. Eine ähnliche Erweiterung – KeeFox –  existiert auch für Firefox. Somit hat man den Komfort von LastPass auf dem eigenen Server.

Damit Die Browsererweiterung mit KeePass kommunizieren kann, lädt man sich KeePassHttp herunter, man braucht nur die Plugin-Datei.

$ cd /usr/lib/keepass2
$ sudo mkdir plugins
$ cd plugins
$ wget https://chrome.google.com/webstore/detail/chromeipass/
ompiailgknfdndiefoaoiligalphfdae

Danach muss man KeePass 2 neu starten. Es sollte die Erweiterung dann erkennen.

Die Browsererweiterungen unterstützen übrigens nur das aktuelle KeePass 2. KeePass 1 (Classic) und KeePassX (Linux Fork) werden nicht unterstützt, Für den Mac habe ich mir KyPass zugelegt, die App kostet zwar 8 €, tut aber aber Ihren Dienst besser als frühe Versionen von MacPass (kann man nur mit Apples XCode selber kompilieren). Von der Installation von KeePass2 via Mono auf dem Mac schreckte ich dann doch zurück. Auf dem Mac kann ich solche Emulatoren noch weniger leiden als unter Linux.

Für den digitalen Nomaden wird hier auch noch eine WebApp beschrieben, mit der man über den Browser auf den Passwortsafe im heimischen Server zugreifen kann. Ich bin leider noch nicht dazu gekommen, das zu probieren.

Diese Lösung ist auf jeden Fall besser, als der Verschlüsselung eines Drittanbieters zu vertrauen und/oder nicht-freie Software wie 1Password einzusetzen, die ggfs. Backdoors enthält.

Update:
Vor dem Import von KeePass2 kann ich nur warnen. Bei mir fehlen zahllose Einträge. Ich vermute der Import stört sich an bestimmten Sonderzeichen in den CSV-Dateien. Man sollte für alle Fälle irgendwo eine Liste der von Lastpass exportierten Passwörter ablegen!

TimeMachine mit OpenMediaVault – iOS Status 2 Fehler

Nach stundenlangen Versuchen habe ich es endlich geschafft, mein TimeMachine-Backup auf den HP Microserver mit OpenMediaVault zum Laufen zu bringen. Bei den ersten Versuchen erschien auf dem Mac beim Versuch, das Volume für Timemachine auszuwählen im...

Nach stundenlangen Versuchen habe ich es endlich geschafft, mein TimeMachine-Backup auf den HP Microserver mit OpenMediaVault zum Laufen zu bringen. Bei den ersten Versuchen erschien auf dem Mac beim Versuch, das Volume für Timemachine auszuwählen immer folgende Fehlermeldung:

Der Vorgang konnte nicht abgeschlossen werden. (OSStatus-Fehler 2.)

Dies liegt nicht etwa an einem falschen Passwort oder Benutzernamen. Denn wenn man das Passwort falsch schreibt „wackelt“ der Dialog. Bei Google findet man haufenweise Threads dazu, auch in Foren von WD, Qnap und Synology.

Workaround

Gelöst habe ich das Problem erstmal, indem ich einen eigenständigen Benutzer timemachine angelegt habe. Im Homeverzeichnis dieses Benutzers klappte das Backup plötzlich 1A.

TimeMachine Einstellungen

Vorher hatte ich es mit diversen Verrenkungen auf der Backup-Festplatte im Ordner Backup versucht, dort liegen auch meine Linux-Backups.

Die endgültige Lösung

Ich kann nun definitiv bestätigen, dass es an den Rechten liegt. Um as zu prüfen, fügt man den Timemachine-Benutzer zur Gruppe ssh hinzu und loggt sich dann mit diesem Benutzer per SSH ein.  Bei mir waren Verzeichnisse und Symlinks schuld, die ich per SSH als root angelegt hatte. Diese haben dann den Besitzer root und keinerlei Rechte für andere Benutzer.

$ sudo chown -R <benutzername> <Ordnername>

Löste bei mir das Problem. Es ändert den Besitzer rekursiv auf den richtigen User. Den Workaround mit dem Benutzer timemachine braucht man dann nicht mehr.

Und weiter

Wie man anschließend das vorhandene Backup vom alten zum neuen Speicherplatz kopiert wird hier detailliert beschrieben.

Man sollte unbedingt eine Quota (Begrenzung des Speichers für eine Freigabe) setzen, sonst schreibt Timemachine nämlich von sich aus das komplette NAS voll. Dies darf man aber erst machen, nachdem man ein normales Backup auf’s NAS gesichert hat.

Erfahrungsbericht Heimserver (NAS)

Nach reiflicher Überlegung habe ich mir letzte Woche einen Heimserver von HP bestellt. In diesem Artikel möchte ich die nicht ganz triviale Auswahl des Server-Betriebssystems beschreiben. Zur Wahl standen FreeNAS, NAS4Free, OpenMediaVault und Amahi....

Nach reiflicher Überlegung habe ich mir letzte Woche einen Heimserver von HP bestellt. In diesem Artikel möchte ich die nicht ganz triviale Auswahl des Server-Betriebssystems beschreiben. Zur Wahl standen FreeNAS, NAS4Free, OpenMediaVault und Amahi. Außerdem möchte ich einige Probleme beschreiben, die es bei der Einrichtung zu umschiffen gilt.

Die Hardware

Die Entscheidung viel auf den HP ProLiant MicroServer Gen8
mit Celeron DualCore 2.3 Ghz Prozessor und 2 GB RAM. Die Entscheidung fiel mir leicht, denn mit 220 € war der Server ein Schnäppchen, sogar billiger als viele fertige NAS-Boxen und dafür mit vier Festplattenslots, deutlich mehr RAM und einem flotten Prozessor. Die meisten NAS-Boxen in dem Preissegment haben nur 512 MB RAM und einen Atom Prozessor. Bestückt wird mein MicroServer erst einmal mit zwei WD Caviar Green 1 TB.

Update: Inzwischen habe ich den MicroServer aufgerüstet mit einem Xeon Prozessor, 4 GB RAM und RAID-5. Dadurch hat der Server erheblich mehr Power, unter anderem für Owncloud und Piwik.

 

Der einzige Kritikpunkt an diesem Server ist die Festplatten-montage. Nur damit die Festplatten vorne einen Griff bekommen, muss man jede Platte in ein wackeliges Blechgestell schrauben (Torx, liegt bei). Mit diesem Rahmen passen die Platten dann nicht mehr in den Wechselschacht am PC, was gerade das Erstbackup verlangsamt. Hot-Swap wäre bei diesem Rahmen sowieso nutzlos, denn pro Platte braucht man mindestens 15min für die Schrauben. Der Server unterstützt aber eh kein Hot-Swap.

Betriebssystem: BSD-basiert

FreeNAS deklassifizierte sich leider sofort, da es aufgrund des ZFS-Dateisystems mindestens 8 GB RAM braucht. Dieses OS ist also eher auf den professionellen Bereich ausgerichtet. In einem Heimserver ist so viel Speicher reine Verschwendung, da maximal eine Handvoll Leute gleichzeitig darauf zugreifen.

Das wie FreeNAS auf BSD basierende NAS4free machte einen sehr guten Eindruck, es lässt sich in der embedded Variante auch auf einen USB Stick (oder eine µSD) installieren, ohne diesen dann durch intensive Schreibzugriffe (Logfiles, Swap, Temporäre Dateien) innerhalb kurzer Zeit zu schrotten. Das Betriebssystem wird beim Start in den RAM entpackt. Updates und auch Erweiterungen sind dadurch relativ umständlich, man muss die Firmware auf dem USB Stick austauschen. Eigentlich ist das eine prima Idee, denn USB-Sticks sind sehr energiesparend und bieten auch mit USB 2 eine recht hohe Zugriffsgeschwindigkeit. Die Zeit für das Entpacken in die RAMdisk ist vernachlässigbar, denn einen Server bootet man in der Regel nicht ständig. Der Speicherbedarf ist dadurch ein  wenig höher als bei anderen Systemen.

NAS4free unterstützt auch das ZFS Dateisystem, lässt sich aber auch mit UFS betreiben. Moderne Linux-Dateisysteme wie EXT3 und 4 werden übrigens nicht unterstützt, auch wird vor dem Einbinden von NTFS gewarnt. Ob da was dran ist kann ich schwer beurteilen.

Leider ist BSD so garnicht mein Fall. Mir gelang es nicht mal mit einer Anleitung eine frisch formatierte Platte zu mounten. Das liegt neben meiner Stupidizität auch an der nicht vorhandenen Benutzerführung. Man muss wirklich alles selber machen, auch die Auswahl des Dateisystems und Bootsektor-Typs beim Mounten. Fehlermeldungen erhält man oft nur wenn man per SSH arbeitet. Dann muss man aber die BSD-Syntax beherrschen.

Betriebssystem: Linux-basiert

Als nächstes probierte ich dann OpenMediaVault. Dieses System basiert auf Debian, Weshalb ich mich als Ubuntu-Anwender sofort zu Hause fühlte. Viele Sachen gehen per SSH auf dem Terminal doch viel flotter. Updates spielt man einfach per

$ apt-get update
$ apt-get upgrade

ein – sehr angenehm! Es lassen sich auch viele Pakete installieren, die man von Ubuntu kennt, z.B. lm-sensors (Temperatursensoren auslesen) und discus (Festplattenbelegung). Zahlreiche Erweiterungen lassen das Nerd-Herz höher schlagen. Weitere Plugins gibt es durch die Installation von OMV Extras.

Mein Kritikpunkt bei OpenMediaVault ist, dass man keine benutzerdefinierte Partitionierung machen kann. Das System belegt immer die gesamte Platte. Wenn man eine Partitionierung machen möchte, kann man zuerst Debian installieren und anschließend die OMV-Pakete. Debian bietet dann eine normale Partionierung an. Ich habe es jetzt übergangsweise auf einem USB-Stick installiert, später wird dann eine stromsparende 2,5″ Festplatte im 3,5″-Rahmen eingebaut, weil ich auf lange Sicht Angst um meinen Stick habe.

Update März 2015
Der USB Stick hat nach vier Wochen Dauerbetrieb das Zeitliche gesegnet. Die Installation eines normalen Betriebsystemsauf einem USB Stick für den Dauerb etrieb in einem Server ist daher nicht empfehlenswertEs gibt inzwischen ein experimentelles Plugin bei OMV-Extras, welches die Migration auf einen Flash-Speicher erlaubt und dann weniger Schreibzugriffe erzeugt. Das ist aber nicht so praktikabel wie eine Out-of-the-Box Lösung.

Probiert habe ich auch noch Amahi, das als Einsteiger-tauglich angepriesen wird. Es basiert auf Fedora. Leider passt es mir überhaupt nicht, dass man einen (kostenlosen) Installationsschlüssel braucht. Dieser wird dann angeblich für einen DynDNS Dienst und Fernkonfiguration benutzt. Dadurch ist man aber auch perfekt für NSA und Co. verfolgbar. Abwählen kann man diesen Schritt am Ende der Installation nicht.

Fazit

Das getestete BSD basierte System ist für mich zu fummelig. Ich habe zwar als Informatiker das Know-How, mich in BSD einzuarbeiten, aber ich möchte nicht noch mehr meiner knappen Freizeit vor dem PC hocken. Zumal die Linux basierten Systeme für mich deutlich einfacher zu handhaben sind. Zwar gelingt auch in OpenMediaVault nicht alles auf Anhieb, man muss oft herumprobieren, aber im Großen und Ganzen ist OMV ein sehr gutes OS für Leute, die sich bereits etwas mit Linux auskennen.