Sonntag, 25. August 2013

Mögliche Backups via Time Machine, Synology, Qnap oder OSX Server

Backup-Strategie für ein Heimnetzwerk oder ein kleines Firmennetzwerk.


Wenn man nicht nur für die kleinen alltäglichen Dinge seinen Mac braucht, sondern immer größer werdende Datenmengen in den Griff bekommen möchte, dann bieten sich externe Netzwerklösungen zur Datenablage an.

Wir vergleichen hier 3 Möglichkeiten die sich für den privaten sowie SOHO (Small Office / Home Office) Bereich anbieten


1. Backup mit Apple Time Capsule via Time Machine


Eigentlich eher für den kleinen Heimanwender geeignet, der ein Backup der aktuell auf seinem Rechner befindlichen Daten braucht. Es werden also keine Daten vom Rechner ausgelagert, wie es bei einem klassischen Server / NAS Modell der Fall ist. Diese Möglichkeit ist also weniger für z.B. Macbook-Air Anwender ratsam, die wenig SSD-Speicher auf dem Rechner installiert haben und ihre Daten eher gerne auslagern möchten, wie z.B. Videos und Fotos.


 

Vorteil hier: Leichte Bedienung und Einrichtung, wie man es von Apple Produkten kennt.
Nachteil: Eben nur ein Backup vom Datenbestand auf dem Rechner, wenige individuelle Einstellmöglichkeiten und im Verhältnis für das, was es kann: etwas teuer. Aber so ist es eben bei Apple: Hier zählt weniger individuelle Funktionsvielfalt, sondern mehr die durchdachte Anwendung und auf das Nötige reduziert, was es demnach auch so einfach macht und den Preis denn wenn als einziges überhaupt rechtfertigt.



1. Datenauslagerung inkl. Backup via RAID1 auf einem Netzwerkspeicher (NAS).


Jetzt wird's interessant für alle diejenigen, die viele Daten besitzen und diese gerne via LAN oder WLAN oder gar Online abrufbar haben möchten. Der Datenbestand ist nicht mit dem auf dem Anwender-Rechner synchron, sondern komplett ausgelagert. Um aber im Falle eines Festplattendefektes ein Minimum an Sicherheit via Daten-Redundanz zu gewährleisten, bietet sich hier ein RAID 1 an. Raid 0 ist hier keine Option, da Raid 0 nur auf Performance setzt und nicht auf Sicherheit via Redundanz eines RAID 1.


Vorteile von Raid 1: 

Es wird sofort 1:1 gespiegelt was auf den Datenträger gelangt. Bedeutet, dass im Ausfall einer Festplatte ohne Unterbrechung weitergearbeitet werden kann.


Nachteile eines Raid 1:

Es ist kein richtiges Backup! Denn es wird nicht nur das gespiegelt was drauf kommt, sondern auch was ungewollt verändert oder gar gelöscht wird!


Typische Kandidaten wären NAS-Lösungen von z.B. Qnap, Synology die eine sehr gute Bedienungsoberfläche und alle benötigten Funktionen für einen Heimserver besitzen



 

Links das Qnap TS220 und rechts die Synology Diskstation DS213J.




3. Datenauslagerung inkl. Backup via Time Machine auf einem OSX Server.

Jetzt wird's richtig interessant, denn es gibt auch noch die Möglichkeit die ausgelagerten Daten nicht via RAID 1 auf der zweiten Platte des Servers als Kopie zu speichern, sondern via Time Machine. 
Die Idee ist hier z.B. einen Mac Mini als Server zu nehmen und die beiden internen Platten NICHT in einen Raid-Verbund zusammen zu schließen sondern als einzelne Volumes im Server mounten zu lassen. Somit kann auf dem Server im Hintergrund Time Machine auf der zweiten Platte ein Duplikat von der ersten – im Netzwerk freigegebenen – Platte erstellen und dies .... stündlich aktualisieren.
Der Vorteil hier ist ein ganz besonderer: Hier werden alte Backup-Versionen beibehalten und man kann im Time Machine Programm auf dem Server via der Backup-History auch auf ältere Backup-Stände zurückgreifen. 
Wenn man also etwas ausversehen löscht, ungewollt verändert oder ansonsten ein Fehler verursacht wird, kann man ohne Probleme auf den vorletzten Stand der Backups zugreifen und ... wiederherstellen. Der einzige Nachteil gegenüber RAID 1 ist hier nur, dass lediglich jede Std. das Backup aktualisiert wird. Aber im privaten Bereich ist das, denke ich, vertretbar.

Jetzt bietet der Mac Mini OSX Server aber auf Grund der intern verwendeten 2.5 Zoll Laufwerke maximal 2x 1TB Festplattenkapazität, was selbst für manche Heimanwender die z.B. eine komplette HD-Filmsammlung auslagern wollen, zu wenig ist. 

Die Lösung hier wäre die Platten via externem USB3 Dual-Gehäuse auszulagern.
Solche USB3 2-Bay RAID Gehäuse kosten ca. 70€ und können sogar bis zu 2x4TB aufnehmen.






Links ein Mac Mini als Server und rechts ein Fantec MR-35VU3R Gehäuse.


Der Mac Mini braucht in diesem Falle nur eine kleine interne Platte verbaut zu haben, um das System und die Applikationen zu speichern. Somit reicht auch ein Dual Core Mac Mini mit i5 und 2.5 Ghz. Auf dem externen Gehäuse liegen sodann alle via dem Server freigegebenen Daten. Der USB3 Anschluss eines neueren Mac Mini Modells ist für die spätere Read/Write Performance im Netz völlig ausreichend.
Der Mode, der hier im RAID-Gehäuse gewählt wird ist aber in diesem Fall KEIN RAID 1, sondern die Platten sollen hier als einzelne HFS+ Volumes im System des Mac Mini Server erscheinen, um so – wie im o.g. Beispiel – als freigegebene Datenplatte nebst Backup-Platte für Time Machine zu fungieren.

Es gibt diverse Anbieter von USB3 RAID Gehäusen, aber das o.g. Fantec hat den Vorteil, dass es (obwohl wir seinen RAID Mode nicht brauchen) nach 5 bzw. 15 Minuten in den Ruhezustand geht und nur noch einen Bruchteil der Energie verbraucht.


Diese Methode mit OSX Server und externem Gehäuse hat zudem noch einen folgenden großen Vorteil: Wenn denn mal die Hardware ausfallen sollte (egal ob im Beispiel oben der MacMini oder im Falle eines NAS dessen Controller), dann kann man das Laufwerk einzeln an einen Mac anschließen und auf die Daten direkt zugreifen – das ist mit via NAS initialisierten Platten nicht möglich, da diese nicht mit HFS+ initialisiert sind!

Der OSX Server der neueren Generationen verbraucht 11Watt.
Bedeutet, Daten von Services die immer zwecks Push & Co aktiv bleiben sollen, wie CardDAV und CalDAV oder Daten für einen Mail- oder Webserver, sollten auf der internen Platte abgelegt sein. Die großen Datenfreigaben auf dem Externen Gehäuse, denn wenn man nicht auf die Daten zugreifen muss, gehts stromsparend in den Ruhezustand.




Maximale Sicherheit via Online-Backup


Alle o.g. Möglichkeiten erstellen eine Kopie am selben Ort. Bedeutet, bei Brand oder eingebrochen wird, ist alles weg. 
Wer maximale Sicherheit braucht, kann z.B. eine Kopie via Online Backup auf einem Server an einem anderen Ort erstellen. Hier ist Rsync via SSH eine sehr gute Option da auf dem o.g. Synology NAS und auch natürlich auch auf dem OSX Server anwendbar.



Und was ist mit Verschlüsselung?

Da wir eben die Möglichkeit des Einbruchs genannt haben – wenn denn absolut sensible Daten auf dem Server liegen, sollten diese eigentlich verschlüsselt sein.
Aber wenn es in diese Anforderungsbereiche geht, muss im Falle eines Synology ein größeres Modell als die DS213j her, z.B. die DS213+ da bei Verschlüsselung die Performance sonst nicht mehr ausreicht. Aber selbst bei einer DS213+ sind hier sodann auch nur noch Raten mit 50MB/s read und ca. 25MB/s write zu erreichen.

Es gibt aber einen Trick wie man lediglich die sehr privaten Daten auf dem Server verschlüsselt ablegen kann, denn wenn dieser entwendet wird, ist es weniger schlimm wenn Musik oder Filme für andere zugänglich sind, als wenn sensible private Daten wie z.B. Dokumente und Fotos in fremde Hände gelangen.
Und diesen verschlüsselten Bereich auf dem Server kann man mit einer eigenen Cloud-Lösung via SparkleShare erstellen. Hier werden beim Abgleich die Daten auf dem Server selber immer verschlüsselt abgelegt – das funktioniert im Hintergrund mit GIT. 
Somit werden nur die sehr privaten Daten verschlüsselt und nicht die großen Datenmengen wie Filme und Audio-Dateien.




Der Form halber der Haftungsausschluss: 
Ich übernehme keinerlei Gewähr für die Aktualität, Korrektheit, Vollständigkeit oder Qualität der hier bereitgestellten Informationen. Haftungsansprüche, welche sich auf Schäden materieller oder ideeller Art beziehen, die durch die Nutzung oder Nichtnutzung der hier angebotenen Informationen bzw. durch die Nutzung fehlerhafter und unvollständiger Informationen verursacht wurden, sind grundsätzlich ausgeschlossen.

Montag, 16. April 2012

sFTP-Zugang einrichten

Mit restriktiven Nutzer-Zugang (chroot jail)



sFTP vs FTP 

Das sFTP (Secure FTP) -Protokoll wird anders als das FTP-Protokoll verschlüsselt übertragen. Dies geschieht standardmäßig via Port 22, welcher ebenso für die "entfernte Anmeldung", also dem SecureShell (SSH) genutzt wird. sFTP sollte gegenüber FTP klar vorgezogen werden, da bei FTP-Transfers nicht nur die Daten, sondern auch der Login unverschlüsselt übertragen werden! 


sFTP Nutzer-Zugang unter OSx 

Mit OSx bzw. dem OSX Server ist die Einrichtung eines sFTP-Dienstes ohne Probleme machbar: Um einen sFTP Service anbieten zu können, muss in den Systemeinstellungen unter "Freigaben" die "Entfernte Anmeldung" aktiviert sein.
Bei Benutzer & Gruppen wird in diesem Fall eine Benutzergruppe "sftpusers" für eben diesen Zugang erstellt. 
Alle Nutzer, die später Mitglied dieser Gruppe sind, habe dann die Rechte für den sFTP-Zugriff. 


Der sFTP-Ordner und die erforderlichen Berechtigungen 

In unserem Beispiel würde sich der sFTP-Zugangsordner "sftp" auf oberster Ebene unserer Festplatte "Macintosh HD"  befinden. Der komplette Systempfad lautet sodann wie folgt:

/Volumes/Macintosh HD/sftp

Nun das Programm Terminal auf dem sFTP-Server-Rechner öffnen und den o.g. Ordner erstellen:

$ sudo mkdir "/Volumes/Macintosh HD/sftp"

Goldene Regel für den späteren erfolgreichen Zugang: Alle Ordner in jenem Pfad, inklusive dem sftp Ordner müssen als Besitzer "root" aufweisen und nur "root" darf Schreibrechte besitzen!

$ sudo chmod g-w /
sudo chmod g-w /Volumes
sudo chmod g-w "/Volumes/Macintosh HD/"
sudo chown root "/Volumes/Macintosh HD/"

Nun noch die Lese-Rechte für den sftp-Ordner alleine auf die Mitglieder der Gruppe sftpusers beschränken:

sudo chown root:sftpusers "/Volumes/Macintosh HD/sftp"
sudo chmod 750 "/Volumes/Macintosh HD/sftp"

Um bei Anmeldung via sFTP die Nutzer auf den sftp Ordner weiterzuleiten, müssen in der Datei sshd_config auf dem Server-Rechner noch Änderungen vorgenommen werden.
Aber vorab machen wir eine Sicherungskopie:

$ sudo cp /etc/sshd_config /etc/sshd_config.bkup

Dann die Datei sshd_config zum Bearbeiten auf den Schreibtisch kopieren:

$ sudo cp /etc/sshd_config ~/Desktop/sshd_config

Diese Datei auf dem Schreibtisch in einem Texteditor öffnen und die Zeile 

Subsystem       sftp    /usr/libexec/sftp-server

wie folgt ändern:

#Subsystem       sftp    /usr/libexec/sftp-server
Subsystem       sftp    internal-sftp


sowie am Ende der Datei folgende Zeilen hinzufügen:

Match Group sftpusers
      ChrootDirectory /sftp
      ForceCommand internal-sftp
      AllowTcpForwarding no

Durch ForceCommand internal-sftp werden alle Nutzer der Gruppe sftpusers bei Anmeldung via Port 22 (ssh und sFTP) auf den sFTP-Zugriff beschränkt und können sich nicht mehr im Terminal via ssh anmelden. Daher sollte der Admin-User in jener Gruppe nicht aufgenommen werden. Macht ja auch keinen Sinn, dem Admin nur Zugriff auf den Ordner sftp zu ermöglichen.

Nun die originale sshd_config Datei mit der geänderten Version ersetzen:

$ sudo cp ~/Desktop/sshd_config /etc/sshd_config

und die Rechte vorsichtshalber korrigieren:

$ chown root /etc/sshd_config

Fertig!
Jetzt nur noch testen:

$ sftp user@domain.adress

Der User wäre hier ein Mitglied der Gruppe sftpusers auf dem Server.
Wenn alles klappt, wird man nach dem Password gefragt und hat eben auf nur jenen, für den sFTP-Transfer freigegebenen Ordner Zugriff. Et voilà.

Da der oberste Ordner (in unserem Fall "sftp") ja nur Leserechte besitzt, lassen sich aber vorher via Serveradmin sodann Unterordner mit entsprechenden Schreib- & und Lesebrechtigungen erstellen.





Der Form halber der Haftungsausschluss: 
Ich übernehme keinerlei Gewähr für die Aktualität, Korrektheit, Vollständigkeit oder Qualität der hier bereitgestellten Informationen. Haftungsansprüche, welche sich auf Schäden materieller oder ideeller Art beziehen, die durch die Nutzung oder Nichtnutzung der hier angebotenen Informationen bzw. durch die Nutzung fehlerhafter und unvollständiger Informationen verursacht wurden, sind grundsätzlich ausgeschlossen.