Hi.
Endlich haben wir ein NAS fürs Backup. von QNAP, habe ca. 2,5TB zur Verfügung.
Wie soll ich das NAS anbinden, um dort mein Backup abzulegen?
NFS
samba
iSCSI [1]
was ich mit absteigender Priorität bedenken will:
Disaster-Recovery möglichst einfach (in den Serverraum tragen, an einen neuen host anschließen, daten kopieren, reboot, fertig)
einfache handhabung + zuverlässigkeit (ich möchte nicht eingreifen wollen)
performance
datensicherheit (verschlüsselung auf dem NAS?)
die letzten zwei kann man m.E. getrost vergessen. Eine Einschränkung: Ich traue dem NAS nicht über den Weg: das NAS hängt auch noch in einem Netz mit Windows-clients für die ich keine Verantwortung übernehme. d.h. vielleicht sollte wg. crypto-trojanern das NAS selbst keinen Zugriff auf die Daten haben. Dann spräche das für iSCSI oder eine andere Möglichkeit finden, dass mir das Backup nicht korrumpiert wird. Ist der Gedanke arg paranoid?
Disaster-Recovery möglichst einfach (in den Serverraum tragen, an einen neuen host anschließen, daten kopieren, reboot, fertig)
Ich denke, dass hängt auch davon ab, wie dein Backup anfertigst. Welche Software verwendest du? Virtualisierst du? Je nach den Gegebenheiten gibt es verschiedene Lösungen.
einfache handhabung + zuverlässigkeit (ich möchte nicht eingreifen wollen)
Wir nutzen XenOrchestra für unseren Server. Damit klappt das bisher ohne Probleme.
meiner Meinung nach NFS v2/3 mittels UDP . Ist am flexibelsten und für allen Arten von Backup/Restore geeignet (VMs als auch klassisch). Um ein wenig Sicherheit zu haben, den Zugriff aber auf IPs einschränken. Das Backup zu ver-/entschlüsseln, wäre zwar super, ist aber aus Geschwindigkeitssicht nicht praktikabel. Der ISCSI Zugriff erfolgt blockbasiert, also wie auf eine HDD, die an den Rechner angeschlossen wird. Ist für ein Backup/Restore aus meiner Sicht wenig praktikabel, nicht wesentlich schneller und auch nicht sicherer.
Ich habe jetzt im zweiten Anlauf NFS genommen und die IP des servers darf mounten. Performance: rsync auf das nfs-mount den kompletten Server von 290GB in 104 Minuten = ca. 50 MB /Sek. Das ist doch mal nicht schlecht auf Anhieb.
Ich könnte auch rsync, aber ich sehe, du machst mir mit rsync -aP auch nicht so viel Gedanken, ob -H -L und --numeric-ids so noch vorsichtshalber mit rein sollte. Das wollte ich dann nämlich fragen: muss man bei NFS-mount sich sorgen um die Rechte/Ownership/hardlinks etc. machen?
Den ssh-Zugang hab ich irgendwie verk***t. Ich wollte meinen eigenen User reinbauen und nach einem /etc/init.d/login.sh restart tat ssh nur noch in immer kürzeren Abständen und jetzt ist der port dicht. Muss das NAS mal rebooten, scheint mir.
danke, auf deine Nachricht hin habe ich NFS probiert (siehe anderer post):
gibt es spezielle Optionen, die man beim Mounten beachten muss? Kann NFS mit hardlinks umgehen? google bringt mir auf Anhieb nichts stichfestes und wenn NFS keine Hardlinks unterstützt, dann werde ich rsync nehmen
VG und danke, Tobias
bei NFS gehen Rechte … verloren. Bei Backups von ganzen VMs oder Mondo Rescue ist das egal, da diese Daten innerhalb des Backup erhalten bleiben. Für Rsync ist NFS also ungeeignet. Hier ist es notwendig, direkt in ein ext3/4 … zu schreiben. Nur ein rsync-Backup zu haben, ist für einen Desaster-Fall aus meiner Sicht zu wenig. Hier würde ich auf jeden Fall, wenn es sich nicht um eine VM handelt, ein Backup z.B. mittels Mondo Rescue oder CloneZilla vorhalten, weil ich hier den Server als Ganzes wiederherstellen kann.
bleiben. Für Rsync ist NFS also ungeeignet. Hier ist es notwendig,
direkt in ein ext3/4 … zu schreiben. Nur ein rsync-Backup zu haben, ist
für einen Desaster-Fall aus meiner Sicht zu wenig. Hier würde ich auf
jeden Fall, wenn es sich nicht um eine VM handelt, ein Backup z.B.
mittels Mondo Rescue oder CloneZilla vorhalten, weil ich hier den Server
als Ganzes wiederherstellen kann.
ich mache seit Jahren meine Backups als Vollbackups vom lvm Snapshot
mittels rsync auf ein NAS.
So habe ich auch den Server im Seminar als auch den Server n der Schule
„umgezogen“.
Bisher keine Probleme.
Letztes Jahr mußte ich auch zwei ownclouds so nach zwei WOchen
wiederherstellen (was dann der Grund war zu nextcloud zu wechseln …).
Ich mag mondo und Clonezilla nicht so sehr, da ich sie in KVM in einer
extramaschine für den Snapshot booten müßte um dann das Backup zu erstellen.
Ich bleib mal bei snapshot und rsync…
Ich würde diese Tools ja auch nur im Falle von echten Servern verwenden. Für den Fall des Desasters habe ich halt schon oft die Erfahrung gemacht, da es sich im allgemeinen um eine stressige Situation handelt, dass eine Wiederherstellung so einfach wie möglich sein sollte. Bei diesen Tools können die Server als Ganzes wiederhergestellt werden und ich muss keine Ahnung davon haben, was die Systeme eigentlich machen.
Im Falle von KVM habe ich mir das hier im Forum genannte BackupSkript einmal angeschaut, dass die KVM-VM als Ganzes mitttels LVM-Snapshot im laufenden Betrieb sichert (inklusive Komprimierung)
Im Falle des Restores muss ich nur die XML-Datei der VM als Maschinendefinition und die Disk per dd ins LVM wiederherstellen. Das Ganze dann z.B. von einem NFS-Volume …
Wenn ich von XEN,ESX … also mal weg bin, werde ich das verwenden.
ich machs wie Holger. Ich habe ein NAS auf Basis von FreeNas ven dem aus bindet XenServer produktiven Speicherplatz ein, z.B. für die Cloud.
Fürs eigentliche Backup mach ichs auch so wie Holger (nur mit Synology NASen).
Warum? Backup auf ein „gemountetes“ Share ist mit großer Vorsicht zu genießen, Wenn ich auf dem Quellsystem versehentlich einen dumm genugen Befehl absetze oder mir einen Verschlüsselungstrojaner fange, ist mein Backup nämlich unter Umständen auch weg.
Darum habe ich immer mindestens eine Version in einem „nicht gemounteten“ Speicher Repo liegen - außer rsync kann man da duply (Wrapper für duplicity), borg Backup und wenn man auf dem Ziel Software installieren kann rdiff Backup empfehlen.
Gegenüber rsync haben die den Vorteil, dass sie schön versionieren.
danke für die Ausführungen. Ist mir bisher nicht aufgefallen…hm.
Holgers Art ist ja auch direkt per rsync auf das ext3 auf dem NAS zu schreiben. Dann mach ich das halt auch so, also ohne NFS.
Stimme ich dir zu. Ich habe bisher: ein rsync-Backup versioniert mit rsnapshot der Daten vorgehalten und dazu noch die VM-snapshots in einer Datei.
Das ist zwar für andere richtig, aber ich halte mich an die Devise, es für mich so einfach wie möglich zu machen. Clonezilla bediene ich zwar auch, aber nicht so regelmäßig, dass ich dem so gut über den Weg traue, wie ein von Hand abgesetztes rsync
Ich möchte nochmal kurz einhaken: bei NFS gehen die folgenden Rechte nicht verloren: UID, GID, die standard modifier für owner, group, other.
Ob extended attributes und ACLs gespeichert werden können, habe und will ich nicht überprüfen, ist mir auch egal.
@alle die geantwortet haben (danke!)
Ich mache jetzt folgendes:
mit Hilfe von rsnapshot ein tägliches Datei-basiertes Backup von (fast) allem (mit LVM-snapshot bei laufenden VMs) auf eine interne Festplatte (deduplizierend per hardlinks)
mit Hilfe von qemu-img (dd) monatlich ein Image-Backup aller VM-Disks und der Metainformationen zur schnellen Wiederherstellung auf ein beliebiges KVM-System , alles auf das NAS über NFS
mit Hilfe von rsnapshot ein monatliches Datei-basiertes Backup der letzten internen täglichen Backups auf das NAS über NFS (deduplizierend via hardlinking)
Das ist so nicht korrekt. Die ursprünglichen Rechte gehen verloren! Welche Rechte im NFS-Filesystem Anwendung finden, hängt vom Export auf dem NFS-Server ab:
root_squash Weist alle Anfragen der UID/GID 0 auf die UID/GID anonymous zu. Zu beachten ist, dass damit andere sensible bzw. mächtige UserIDs wie etwa "bin" oder "staff" nicht geändert werden. X
no_root_squash Legt man als Nutzer root per NFS Dateien oder Verzeichnisse an, werden diese standardmäßig dem Nutzer nobody zogeordnet ('root_squash'). Um dieses Sicherheitsmerkmal von 'root_squash' zu umgehen und die, vom User root geschriebenen Daten, auf dem Server nicht auf einen anderen User als ihn selbst zu mappen (UID/GID 0 bleiben erhalten), verwendet man den Parameter 'no_root_squash'. -
all_squash Ordnet alle UserIDs dem Nutzer anonymous zu. Nützlich für NFS-exportierte öffentliche FTP-Verzeichnisse oder News-Spool-Verzeichnisse. -
anonuid anongid Diese Option setzt die anonyme User- und Gruppen-ID explizit auf die angegebenen Werte. Diese Option ist primär für PC/NFS Clients gedacht, wo davon ausgegangen wird, dass alle Nachfragen von einem bestimmten Rechner immer von einer Person kommen. Beispiel: /home/joe pc001(rw,all_squash,anonuid=150,anongid=100)
M.E. hat @Tobias da schon recht. no_root_squash bezieht sich nur aufs Kopieren von Dateien, die root gehören, d.h. bei Verwendung bleibt die UID 0 erhalten, sonst nicht. Alle von Tobias genannten Attribute bleiben auch so (außer bei root) erhalten (aber natürlich nur, wenn auch bei rsync oder cp die entsprechende Option -p verwendet wird)
nehme alles zurück. Hatte bei meinem Test gerade die Option
"no_root_squash’ vergessen. UID und GID bleiben erhalten!
Hier auch noch als Ergänzung: Soweit ich mich richtig erinnere, muss ohne
no_root_squash das Verzeichnis auf dem Zielsystem auch noch schreibbar für
alle sein, sonst darf root (bzw. ja dann nobody) da gar nichts
hinschreiben.
