rsync Backup von remote Server mit SSH

cla

cla

Well-Known Member
Ich versuche gerade einen rsync-Kommando zusammenzubasteln um mir folgendes zu ermoeglichen:

- Backup von einem remote Server mit rsync von lokalem Computer, welches
- Vollbackup von "/" und allem darunter (deshalb wohl irgendwie Root-Rechte noetig) macht
- initiert von meinem lokalen Rechner
- mit SSH oder SSH Tunnel
- vorzugsweise mit RsyncD Daemon auf remote server um die Arbeit aufzusplitten und die Root-Rechte zu haben (evtl. habe ich aber die Funktionsweise von rsyncd nicht ganz richtig verstanden...)
​
Leider funktioniert es bisher noch nicht.

Ich habe bisher
- SSH Keys fuer passwortloses Login (das funktioniert; separat getestet)
- RsyncD auf remote Server konfiguriert und laeuft als Root-User.
- RsyncD hat "/" definiert fuers Backup (folgend "RSYNCDMAP" genannt)
- login auf Remote-Server erfolgt nicht mit "root" sondern via separatem Backup-User-Account (daran koennte z.B. auch eins meiner Probleme liegen; ich will aber definitiv keinen SSH-Root-Login freischalten).
​
Jetzt versuche ich etwas wie folgend:

Code: 
rsync -avx --stats --timeout=300 -e "ssh" REMOTESERVER::RSYNDMAP/ /LOKALERZIELORDNER

oder auch

Code: 
rsync -avx --stats --timeout=300 -e "ssh -A REMOTESERVER ssh" REMOTESERVER::RSYNDMAP/ /LOKALERZIELORDNER

wobei "REMOTESERVER" der Kuerzel fuer den Server ist, welcher in meiner ".ssh/config" definiert ist und dort Serverhostnamen, Usernamen und Port definiert.

Leider erhalte ich immer nur "rsync: did not see server greeting".

Ich bin mir ziemlich sicher, das ich irgendwo einen Denkfehler drin habe...sehe ihn momentan aber nicht. Kann mir jemand weiterhelfen?
Das Internet beschreibt zwar 1000x Beispiele selber Natur, aber entweder ist das ohne SSH oder ohne RsyncD oder eben nur von Unterverzeichnissen und nicht vom ganzen "/".

Sobald die Verbindung erfolgreich funktioniert, will ich natuerlich noch eine entsprechende Exclude-Datei mit definieren um unnoetige Verzeichnisse wie z.B. "/dev" mit auszuschliessen.
 
Es macht durchaus Sinn ein ganzen System zu sichern. Der Restore nach einem Hardwareausfall (oder größeren Fehlern vor dem Bildschirm) wir dadurch massiv vereinfacht und beschleunigt. Die Frage ist natürlich ob rsync dafür das richtige Mittel ist. rsync wurde entwickelt um den samba Code zu replizieren und nicht um bootfähige Backups zu bekommen. Sollte auf beide Seiten FreeBSD laufen würde ich mir andere Werkzeuge ansehen z.B. dump/restore für UFS Quellen und zfs send/recv für ZFS Quellen.
 
Also ich mache auch recht gerne Backups mit rsync, nutze aber nicht den Daemon, bei mir ist das auch ohne hinreichend performant.

aufruf:

rsync -aruvz --delete -e ssh /quelle/ benutzer@hostname:/ziel/

Wenn man das ganze System sichern möchte ist rsync nicht das richtige tool, da möchte ich crest rechtgeben. Ist bei uns aber nicht so interessant, zumal man mit rsync auch vortrefflich auf ein ähnlich konfiguriertes "standby" system sichern kann, was im zweifel u.U. mehr hilft als ein kompletter restore.
 
Crest schrieb:
Es macht durchaus Sinn ein ganzen System zu sichern. Der Restore nach einem Hardwareausfall (oder größeren Fehlern vor dem Bildschirm) wir dadurch massiv vereinfacht und beschleunigt.
Zum Vergrößern anklicken....

Du hast Recht, ich nicht.

Jedes Mal, wenn ich das machen mußte, gab es die alte Hardware nicht mehr und ich konnte den ganzen Kram des OS nicht mehr brauchen, aber die Konfigurationsdateien waren wichtig und die sensiblen Daten selber natürlch - quasi die "last line of defence".
 
FreeBSD muss man i.d.R. nicht stark an die Hardware anpassen oft reicht es ifconfig_* in der rc.conf zu ändern um eine Installation zu migrieren. Ich kenne da einen Fall in dem wurde neue Hardware beschafft, die FreeBSD Installation mit allen Daten brav portiert und schließend sollte noch die Platten der alten Hardware genullt werden... du kannst dir denken welches System ich genullt habe? Naja zum glück hatte ich ein Backup das erst wenige Stunden alt war und am morgen lief alles wieder so wie es sollte und die richtigen Platten wurden genullt.
 
Bei den paar Fällen, in denen ich das Problem hatte, kam ich nur per ssh auf die Konsole und durfte mit anderen Plattenkonfigurationen arbeiten, andere RAIDS und nur in sehr bestimmten Konfigurationen überhaupt nutzbar, kein SCSI mehr, sondern ATA und irgendwelcher andere Mist. Ich konnte dann zwar ein dump/restore machen, aber dann lief nichts mehr.

Das brachte mich zu der Lösung nur das Wichtigste zu sichern und den Rest einfach neu aufzubauen. Das OS ist in der Regel schnell drauf, Ein Update dazu dauert auch nicht lange und die Ports sind aus einer Datei flott installiert, als pkgs noch schneller. In der Zeit lassen sich die Konfiguartionsdateien auf Inkonsistenzen mit dem neuen System prüfen, Daten drauf und noch ein wenig Ausbügeln, was übersehen wurde.

Zugegeben, das ist alles für den GAU, aber genau dafür machen solche Sicherungen Sinn.
 
Tatsächlich sichere ich unsere Umgebung auch via rsync. Die Betriebssysteme werden nicht gesichert, nur Daten, Datenbanken und Konfigurationen. Für die Installation der Betriebssysteme haben wir Scripts, die innerhalb weniger Minuten das OS wieder installieren, aktualisieren und die Software, die wir brauchen, installieren. Danach Configs zurück und Daten.
Das hat den Vorteil, dass wir vor dem Durchlauf der Scripts noch Änderungen oder Anpassungen an die ggf. neue Hardware machen müssen.
Mir fällt gerade nicht wirklich eine Konstellation ein, in der man ein richtiges Desaster Recovery sinnvoll einsetzen kann. Geht das Motherboard (oder CPU, RAM, usw.) kaputt, tausche ich das, das System läuft weiter. Gehen die Platten vom OS kaputt (oder gehen die Daten kaputt), tausche ich die und installiere per Script das OS neu, die Daten sind dann ja noch da. Gehen die Daten kaputt, tausche ich die Platten (was bei RAID6 unwahrscheinlich ist, dass es dort zum richtigen Gau kommt) und synchronisiere die Daten von einem gleichwertigen Server, der dann übernommen hat, zurück (was automatisch geht) oder von Backup. Brennt der Server ab, brauche ich sowieso einen neuen und habe damit andere Anforderungen.
 
Vielen Dank soweit. Um noch etwas detailierter zu werden:

Mein VPS Server (welchen ich sichern will) hat nur sehr begrenzten Speicherplatz. Deshalb kommt ein tar/dump aufs selbe System mit anschliesendem Transfer nach woandershin nicht in Frage.
Der Server hat ausserdem Jails, wovon ein paar mit geli verschluesselt sind...also nur als verschluesselte, grosse, Image-Dateien vorliegen. Jetzt koennte ich entweder jedes Jail einzeln von intern aus sichern (muehselig) oder einfach das "/" Verzeichnis mit allem darin enthaltenen (abzueglich wirklich unnoetigen Sachen wie /dev, /tmp und /usr/ports etc...). Und das intelligente Rsync wuerde auch bei den grossen Image-Dateien nur die geaenderten Bits uebertragen.

Somit wuerde es mir ermoeglichen, eine lokale Kopie des Servers zu erstellen, welche taeglich aktuell gehalten wird. Und mit Rsyncs Hardlinks auch eine inkrementale History der z.B. letzten Wochen machbar ist.

Taegliche Datenaenderungen am zu sicherenden System sind allerdings sehr wenig und im Gesamten wahrscheinlich weniger als ein paar Megabyte pro Tag. Und wenn ich nur diese paar Megabyte wegsichern muesste, waere das gut.

Meine limitierenden Faktoren sind hier:

- Plattenplatz (auf dem zu sichernden System; also kein Backup-Staging gewuenscht)
- Datenmenge (im Gesamten momentan ca. 20-30GB) doch recht viel, um ueber eine langsame Heim-Internetverbindung zu uebertragen. Ich sehe z.B. Vollbackups dieser Datenmenge monatlich nicht wirklich praktikabel.

Deshalb kommen fuer mich auch dump/restore oder ZFS send/rec nicht in Frage (ZFS schon alleine wg. dem RAM-Bedarf nicht).

Es ist vollkommen richtig, das ich eigentlich nur die wichtigen Config-Dateien und User/Applikationsdaten sichern muesste...und ich brauche auch nicht unbedingt ein vollkommen Recover-faehiges System (bootfaehig muss es wirklich nicht sein...aber es waehre z.B. schoen fuer die Geli-Jail-Images, wenn ich die einfach wiederherstellen koennte)...jedoch bevorzuge ich beim Backup lieber immer die Strategy ALLES zu sichern...so hat man im Ernstfall immer ALLES...auch wenn man dann nur wenig braucht....anstatt dann im Ernstfall festzustellen, das man doch irgendwo vergessen hat ein wichtiges Verzeichnis mit ins Backup einzuschliessen.

Amanda hatte ich mir auch schon mal naeher angeschaut, da dessen Backup-Datenmengen-Strategy recht interessant erscheint. Jedoch sprechen wir auch hier wieder von Voll-Backups welche regelmaessig ihren Weg von A nach B finden muessen. Auch bin ich mir unsicher ob sich eine zeitliche Investition in Amanda reinzuarbeiten lohnt, da es seit "Zmanda" und jetzt "Carbonite" bei mir irgendwie einen komischen Beigeschmack bezueglich Zukunft und Weiterentwicklung hat (welcher rein subjektiv sein mag und ich gerne bereit bin zu ueberdenken). Irgendwie scheint es fuer mich aber, als ob bei Amanda-Backup die goldenen Tage vorbei sind. Und "tar" als Backup-Archiv-Format ist ja auch umstritten/limitierend.
 
cla schrieb:
... oder einfach das "/" Verzeichnis mit allem darin enthaltenen (abzueglich wirklich unnoetigen Sachen wie /dev, /tmp und /usr/ports etc...). Und das intelligente Rsync wuerde auch bei den grossen Image-Dateien nur die geaenderten Bits uebertragen.

Somit wuerde es mir ermoeglichen, eine lokale Kopie des Servers zu erstellen, welche taeglich aktuell gehalten wird. Und mit Rsyncs Hardlinks auch eine inkrementale History der z.B. letzten Wochen machbar ist.

Taegliche Datenaenderungen am zu sicherenden System sind allerdings sehr wenig und im Gesamten wahrscheinlich weniger als ein paar Megabyte pro Tag. Und wenn ich nur diese paar Megabyte wegsichern muesste, waere das gut.
Zum Vergrößern anklicken....

Mir wäre das zu heiß ,aber ich schmeiß dann auch einfach mit Hardware nach dem Problem.

Amanda hatte ich mir auch schon mal naeher angeschaut, da dessen Backup-Datenmengen-Strategy recht interessant erscheint. Jedoch sprechen wir auch hier wieder von Voll-Backups welche regelmaessig ihren Weg von A nach B finden muessen.
Zum Vergrößern anklicken....

Ja, dann sicher halt nur alle Jubeltage die ganze Schose und ansonsten nur deine 3 MB.

Auch bin ich mir unsicher ob sich eine zeitliche Investition in Amanda reinzuarbeiten lohnt, ...
Zum Vergrößern anklicken....

Alles wichtige habe ich hier eigentlich in verschiedenen Threads zusammengesammelt.

... da es seit "Zmanda" und jetzt "Carbonite" bei mir irgendwie einen komischen Beigeschmack bezueglich Zukunft und Weiterentwicklung hat (welcher rein subjektiv sein mag und ich gerne bereit bin zu ueberdenken).
Zum Vergrößern anklicken....

Bis jetzt macht AMANDA, was es soll. Eine professionelle Service Variante kam für mich nie in Frage.

Irgendwie scheint es fuer mich aber, als ob bei Amanda-Backup die goldenen Tage vorbei sind. Und "tar" als Backup-Archiv-Format ist ja auch umstritten/limitierend.
Zum Vergrößern anklicken....

Es ist das einzige Backup was ich gefunden habe, was gerade aufgrund vo tar und gz JEDERZEIT und ÜBERALL seine Daten aus dem Archiv wieder freigeben kann. Bei allen anderen, die ich gesehen und gefunden habe, bin ich an irgendwelchem proprietären Scheiß gestorben. Man konnte es nur mit dem EINEN Streamer zurücklesen oder nur mit der EINEN Version usw. usw. usw.
 
peterle schrieb:
Es ist das einzige Backup was ich gefunden habe, was gerade aufgrund vo tar und gz JEDERZEIT und ÜBERALL seine Daten aus dem Archiv wieder freigeben kann. Bei allen anderen, die ich gesehen und gefunden habe, bin ich an irgendwelchem proprietären Scheiß gestorben. Man konnte es nur mit dem EINEN Streamer zurücklesen oder nur mit der EINEN Version usw. usw. usw.
Zum Vergrößern anklicken....

Genau deshalb nutze ich auch Tar - was nützt mir das tollste Backup wenn ich im zweifel genau die Software zum auslesen der Software nicht zur Hand habe, im hektischen Fehlerfall - OpenSource lösung sind da vill. ein bisschen ausgenommen, aber in seiner kompatibilität und schlichtheit finde ich tar da schon recht praktisch.
 
Auch wenn es furchtbar Offtopic ist: Kannst du was zu den verschlüsselten Jails schreiben? Wie hast du die eingerichtet - warum die Jails und nicht den ganzen Server?

Gruß
Markus
 
CommanderZed schrieb:
Genau deshalb nutze ich auch Tar - was nützt mir das tollste Backup wenn ich im zweifel genau die Software zum auslesen der Software nicht zur Hand habe, im hektischen Fehlerfall - OpenSource lösung sind da vill. ein bisschen ausgenommen, ...
Zum Vergrößern anklicken....

Amanda ist eigentlich auch nichts anderes, als eine komfortablere Umgebung für tar.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben