(gelöst) rsync backup ohne Password über ssh

[TomL]

Im Moment sehe ich noch keine Lösung für mein Problem, aber viele neue Ansätze.

Schau Dir mal mein Backup-Konzept an... das verfolgt exakt auch den von MSfree genannten Ansatz... das "Womit" ist tatächlich nämlich die letzte Entscheidung. http://www.thlu.de/extrabaki.html.

Das "Womit" habe ich am Ende mit einem eigenen Script lösen können, nach dem ich wusste, was ich überhaupt will. Das Script und die Beschreibung dazu ist im Artikel-Menu verlinkt. Das ist vielleicht nicht die Lösung für jedermann, aber es sollte allemal tauglich dazu sein, mit mehr Kenntnis und Grundlagen eine belastbare eigene Entscheidung treffen zu können.... egal, ob tar, rsync oder verschlüsselt extern Lagern die Lösung ist... in meinem Konzept findet alles 3 Berücksichtigung, weil alles 3 automatisch läuft. Meine Prämissen waren "Mannlos, Einfach, Sicher, autom. Reports, kompromisslose Eindeutigkeit und Sicherheit bei der Rekonstruktion von Daten im Notfall".

[Peter18]

Hallo schwedenmann,

Dank Dir.

Aber ich schlage niemanden tot . Spaß beiseite, genau so habe ich meinen User angelegt. Über Puty einloggen geht! Die Rootrechte waren auch nur dazu, dass ich beim ersten Mal mit sicherheit alles gesichert bekomme.
rsync rufe ich in der kommandozeile auf:
"sudo /usr/bin/rsync --delete --numeric-ids --bwlimit=1000 -azbv /media/platte1 backup@10.168.2.6:/media/platte1/Backup"
Ist vielleicht der Grund, dass ich kein Skript verwende? Wie müsste das aussehen? (noch nicht gemacht; fange grad an)

Grüße von der wolkigen Nordsee

Peter

[MSfree]

Soweit ich gelesen habe macht rsync auch nicht immer ein vollständiges Backup, sondern sichert nur die Daten, die sich geändert haben.

Das ist soweit auch richtig. nur des erste Backup muß notwendigerweise vollständig sein. Folgende rsyncs übertragen nur noch Änderungen. Aber hier muß man eben auch aufpassen, um vor bösen Überraschungen gefeit zu sein.

Nehmen wir an, du hast einen Dateibestand, der auch schon gesichert ist. Jetzt löscht man aus diesem Bestand eine Datei. Mit dem nächsten rsync besteht die Änderung eben genau darin, daß eine Datei gelöscht wurde, also wird sie auch aus dem Backup gelöscht.

Dieses Dilemma kann man durch geeignete Aufrufparameter von rsync umgehen, im einfachsten Fall verbietet man das Löschen von Dateien im Backup. Sollte man aber einen bestimmten Datenbestand wieder restaurieren müssen, ist die Information, daß Dateien eigentlich zu löschen waren, verloren gegangen.

Auch dagegen kann man etwas tun, indem man rsync so einrichtet, daß es Backups nicht einfach im Zielverzeichnis erzeugt, sondern eine aus Hardlinks bestehenden Kopie anlegt, die dann mit dem Änderungen "überschrieben" wird. Die Hardlinkkopie kostet nur wenig Speicherplatz, geht verhältnismässig schnell und erlaubt ein vollständiges Abbild des Bestandes zum Zeitpunkt des Backups, inklusive löschen von Dateien (im Vortagesbackup bleibt die jetzt gelöschte Datei also bestehen).

Den zuletzt genannten Ansatz verwende ich, um meinen Server mit 2TB Datenbestand täglich vollständig zu sichern. Das dauert im Schnitt 10 Minuten und ist über ein Shellskript, das letztlich rsync aufruft, realisiert, das auch noch ein Log mit Übertragungsinformationen erzeugt

[Peter18]

Hallo Thomas,

Dank auch Dir. Hatte nicht gesehen, dass es noch eine 2. Seite gibt. Da hab ich ja wieder was zum Lesen! Werde es mir zu Gemüte führen und die Skripte ansehen.

Grüße von der wolkigen Nordsee

Peter
Nach oben

[Peter18]

Hallo MSfree,

nochmals Dank!

Diese Problematik kenne ich. Es kommt mir darauf an, dass ich schnell auch auf einzelne Dateien zugreifen kann, daher kommt eine konventionelle Datensicherung oder ein Archiv nicht in Frage. Damit nicht versehentlich gelöschte Dateien verlohren sind, erstelle ich mehrere Datensicherungen. Eine Gesamtsicherung täglich gegen Mitternacht, eine Teilsicherung von Arbeitsbereichen wie Softwareentwicklung, Steuerunterlagen oder Privatverkäufe. Diese Teilsicherungen werden in kurzen Abständen, täglich und wöchentlich durchgeführt. Damit habe ich auch auf Daten Zugriff, die einige Tage zuvor versehentlich gelöscht, oder die beschädigt wurden, ohne es zu merken, weil der Cursor im falschen Fenster stand. Bei der Softwareentwicklung kann es etwas Aufwändig werden solche Fehler zu finden und zu beheben. Einen Punkt kann man schnell übersehen!

Ich hatte eigentlich ein Raid1 aufbauen wollen, der kleine Raspberry kam damit aber nicht zurecht, auch 2 Platten mochte er nicht und hat sich mit dem System in die ewigen Jagdgründe begeben. Vielleicht klappt das mit den 2 Platten an einem aktiven Hub. Vorläufig soll aber ein "Backup-Server" die Daten erhalten.

Grüße von der Nordsee

Peter

[MSfree]

Diese Problematik kenne ich. Es kommt mir darauf an, dass ich schnell auch auf einzelne Dateien zugreifen kann...

Genau dafür ist das Szenario, das ich mit den Hardlinks oben beschrieben hatte, da. Die Hardlinks braucht man nicht selbst anzulegen, das macht rsync mit entsprechenden Optionen selbst.

Ich lasse mein Backupskript täglich laufen und habe so seit mehr als einem halben Jahr täglich ein mit Datum bezeichnetes Unterverzeichnis, in dem sich eine volständige Kopie des Datenbestandes befindet. Bei Apple gab es sowas unter dem Namen TimeMachine, die das ganze aber noch graphisch hübsch aufbereitet hat. Damit man nicht täglich 2TB Platz, im Jahr also über 700TB, braucht, werden unveränderte Dateien nur einmal physikalisch auf dem Backupmedium gespeicher und nur auf den Tagesverzeichnissen verlinkt. Dadurch hält sich der Plattenplatzbedarf in Grenzen.

Ich hatte eigentlich ein Raid1 aufbauen wollen, der kleine Raspberry kam damit aber nicht zurecht,

Mir ist eine kleine Synology 218 zulaufen, da steckt auch ein 4-Kern ARM drin. Die hatte ein Bekannter über und hat sie mir vermacht. Die Dinger laufen ab Werk bereits mit Linux, bringen also auch rsync und SSH zum Andministrieren mit. Ich mußte dort nur 2 Platten reinstecken, mein Backupskript draufkopieren und das Skript als täglich laufenden Dienst aktivieren. Seither läuft das kleine Ding "in der Ecke". Und im Gegenastz zu einem Raspi ist dass keine Kabelverhau, kann echtes SATA und schaufelt über 100MByte/s über den GBit-Netzwerkport.

Das Skript stelle ich hier bei Interesse gerne zur Verfügung. Das ist keine Raketenwissenschaft, es ist aber sinnvoll, sowas vorher verstanden zu haben, statt nur blind irgendwelche Dinge aus dem Internet zu kopieren. Es setzt aber einen laufenden rsync-Daemon auf dem zu sichernden Rechner voraus. Auf SSH ließe sich das aber auch mit wenigen Handgriffen umstellen.

[Peter18]

Hallo MSfree,

Nochmals Dank! Auf Dein Angebot mit dem Script komme ich gern zurück. Das kann ich dann auf meinen Bedarf anpassen und sehe wie so etwas aussieht. Ein Tipp, was für SSH anzupassen ist wäre toll. By the way, mein backup user hat kein Homedirectory Kann das die Ursache für die Probleme sein?

Grüße von der Nordsee

Peter

[uname]

Ich habe nicht alles gelesen. Aber was willst du mit "sudo"? Du kannst doch einfach den SSH-Zugriff per SSH-key auf "rsync" einschränken.

https://ramblings.narrabilis.com/using-rsync-with-ssh
https://www.thomas-krenn.com/de/wiki/Au ... %C3%A4nken

Natürlich ist hierbei die Frage ob du die zu backupenden Daten ziehst oder schiebst

[MSfree]

Auf Dein Angebot mit dem Script komme ich gern zurück.

Ich habe das Skript, das ich benutze, mit Kommentaren versehen und hier hochgeladen:
40928

Ein Tipp, was für SSH anzupassen ist wäre toll.

Im wesentlichen muß man den rsync-Aufruf in Zeile 64 um die nötigen SSH-Parameter ergänzen. Das kann man machen, indem man sie dort direkt einträgt oder eine neue Variable im Kopf erstellt, die die Parameter beinhaltet. Diese Variable muß dann noch in den rsync-Aufruf mit eingefügt werden.

z.B.:

Code: Alles auswählen

SSHTRANSPORT=-e "ssh -l ssh-user -i /home/sshuser/.ssh/hostkey.rsa"

und dann statt (Zeile 64)

Code: Alles auswählen

rsync -av --link-dest=$PREV $SRC $BUS >> $LOG 2>&1

auf

Code: Alles auswählen

rsync -av $SSHTRANSPORT --link-dest=$PREV $SRC $BUS >> $LOG 2>&1

abändern.

mein backup user hat kein Homedirectory Kann das die Ursache für die Probleme sein?

Um Paßwörtern aus dem Weg zu gehen, brauchst du SSH-Schlüssel. Wie die erzeugt werden, erfährt man in der Anleitung zu ssh-keygen, die man mit man ssh-keygen auf der Kommandozeile lesen kann. Der private Schlüssel muß in das Home-Verzeichnis des Benutzers kopiert werden, der das Skript aufrufen soll. Um ein Home-Verzeichnis kommst du also nicht herum, es kann aber bis auf .ssh leer bleiben.

Das erste Backup wird je nach Datenumfang lange dauern. Die 2TB von meinem Server haben meiner Erinnerung nach so um die 7 Stunden benötigt. Die täglichen Änderungen sind dann aber typischerweise in 10 Minuten übertragen.

[Lord_Carlos]

Bei der Softwareentwicklung kann es etwas Aufwändig werden solche Fehler zu finden und zu beheben. Einen Punkt kann man schnell übersehen!

Da wuerde ich zusaetzlich noch git oder aehnliches einsetzten.
Gerade bei Softwareentwicklung bringt es einige Vorteile mit sich. Schnell zwischen versionen hin und her wechseln, ganz ohne Daten per hand zu kopieren.

[Peter18]

Hallo MSfree,

vielen Dank für Deine Antwort!!! An ein NAS hatte ich auch schon mal gedacht, aber dann habe ich mir einen Raspberry zur Weinüberwachung bestellt. Als ich sah, was der alles kann, dachte ich "Der kann auch Server spielen!" zumal meine Novell.Server Hardware schon sehr betagt war. Dass mein Backup-user sich unter SSH nicht anmelden ließ, lag daran, dass er nicht Mitglied der Gruppe ssh war.

Dann werde ich mich mal mit dem SSH-Schlüssel befassen und Dein Script kräftig abspecken (will verstehen, was da passiert), damit erst mal etwas läuft und mich dann mit Script und vielleicht auch mit awk befassen. Da werden vielleicht noch weitere Fragen kommen.

Mein erstes Backup ist schon gelaufen, hat mehrere Tage gedauert (mit gebremsten Schaum [--bwlimit=1000]).

Hallo Lord_Carlos, ???? Wie hilft das in der Sache weiter ?????

Grüße von der Nordsee

Peter

[Lord_Carlos]

Hallo Lord_Carlos, ???? Wie hilft das in der Sache weiter ?????

Der Sache garnicht. Das war ein allgemeiner Tipp an dich. Darf auch ignoriert werden wenn es nicht passt.

[MSfree]

Hallo Lord_Carlos, ???? Wie hilft das in der Sache weiter ?????

Der Sache garnicht.

Naja, so "gar nicht" ist das letztlich nicht.

Git ist ein Revisionsverwaltungssystem. Man kann damit jede Softwareänderung speichern und wieder herstellen. Man kann sogar, wenn man sich verstrickt hat, einfach den Ausgangszustand zurückholen. Es ist netzwerkfähig, was für verteilt arbeitende Teams sinnvoll ist. Und, es ist für einen Neuling nicht gerade trivial. Git ist so gesehen in sich schon eine Art Backup, wobei der Git-Server selbst natürlich auch gesichert werden muß, denn wenn der Git-Server abraucht, muß man den aus dem Backup wieder herstellen können.

Ich habe im Lauf der Zeit immer mit Revisionkontrollsystemen gearbeitet, angefangen bei SCCS, RCS haben wir übersprungen und gleich auf CVS geschwenkt. Dann haben wir einige Jahre mit Subversion gearbeitet und nun sind wir bei Git. Es ist zwar nicht unbedingt nötig, aber wir können theoretisch jeden Source-Zustand bis zurück ins Jahr 1989 wieder herstellen. Da man seine Commits, also das Speichern eines Zustands, auch kommentieren kann, kann man nach ein paar Jahren nachlesen, warum man eine bestimmte Änderung eingeführt hat.

[Peter18]

Hallo MSfree,

ich habe einiges gelesen und nun einen Satz Schlüssel erzeugt. Mit den Schlüsseln kann ich eine Verbindung ohne Password aufbauen. Mit rsync inzwischen ebenfalls. Es gibt aber Fehlermeldungen, die ich bisher nicht auflösen konnte. Vielleicht hast Du ja einen Tipp wo ich Infos finde oder wo der Fehler liegt.

Fehler:

Code: Alles auswählen

rsync: connection unexpectedly closed (2080 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(235) [sender=3.1.2]

Befehl:

Code: Alles auswählen

rsync --delete --numeric-ids --bwlimit=1000 -azbv /media/platte1 ba@10.168.2.6:/media/platte1/Backup

Grüße von der Nordsee

Peter

[MSfree]

Zu diesem code 12 habe ich das hier gefunden:
https://askubuntu.com/questions/625085/ ... -ssh-works

Mögliche Ursachen ist demzufolge:

• Schreibfehler bei den Pfadangaben
• Platte voll
• rsync muß auf beiden Seiten installiert sein
• ...?

[Peter18]

Hallo MSfree,

Dank Dir für die Antwort!

Schreibfehler bei den Pfadangaben scheidet aus, mit diesen Angaben hat eine Teilsicherung stattgefunden.
Platte voll kann nicht sein bei 16% Quelle und Ziel 1% verwendet.
rsync muß auf beiden Seiten installiert sein, ist der Fall, denn ich habe bereits eine Datensicherung durchgeführt.

Die Datenquelle läuft unter Samba. Kann es sein, dass Umlaute oder "ß" in Datei- oder Verzeichnisnamen die Ursache sind? (cifs ist noch nicht bei der Zielplatte montiert)

"Error in rsync protocol data stream" sagt mir nicht viel. (https://lxadm.com/Rsync_exit_codes)

Grüße von der Nordsee

Peter

[debianoli]

Die Datenquelle läuft unter Samba. Kann es sein, dass Umlaute oder "ß" in Datei- oder Verzeichnisnamen die Ursache sind? (cifs ist noch nicht bei der Zielplatte montiert)

Das ist aber eine wichtige Info, die bislang fehlte. Was heißt "Datenquelle läuft unter Samba"? Ist das zu sichernde Verzeichnis per mount.cifs eingebunden und liegt zB auf einem Windows-Server? Oder dient das zu sichernde Verzeichnis als smb-Freigabe und liegt auf einem Linux-Rechner?

[Peter18]

Hallo debianol,

Dank auch Dir! Dass diese Info wichtig sein kann, ist mir auch eben erst aufgegangen, als ich die Antwort schrieb! Der Server ist Linux mit Samba. Der Rechner, der die Sicherung erhält ist ebenfalls Linux, aber noch ohne Samba und cifs. Sonstige Clients sind Windows-Rechner.

Grüße von der Nordsee

Peter

[debianoli]

Der Server ist Linux mit Samba. Der Rechner, der die Sicherung erhält ist ebenfalls Linux, aber noch ohne Samba und cifs.

Hi Peter,

dann sollte es egal sein, wenn da Samba läuft. Du kopierst von Linux auf Linux.

Wie hast du eigentlich den ssh-Key übertragen? Mit ssh-copy-id aus oopenssh-client? Ist eigentlich das einfachste:

Code: Alles auswählen

ssh-copy-id user_am_host@host_IP

Danach läuft ssh und rsync ohne Passwort-Abfrage.

Läuft eigentlich bei Host und Client die gleiche rsync-Version?

Und welche Rechte hat der sichernde User und der user am Host? Sind die alle in den gleichen Gruppen?

[Peter18]

Hallo debianol,

Dank Dir. Ich bin auch davon ausgegangen, dass es nichts aus macht, zumal beide Platten mit ext4 formatiert sind. Den ssh-Key habe ich mit "ssh-copy-id -i ~/.ssh/..." übertragen. Die Passwordfreie Anmeldung funktioniert sowohl manuell als auch mit rsync.

Auf beiden Rechnern läuft die Version "rsync version 3.1.2 protocol version 31". Die User auf beiden Rechnern haben die gleichen Rechte und sind Mitglied der Gruppen root, sambauser, sudo, ssh. Warscheinlich ist vieles nicht nötig, aber es soll erstmal laufen, dann kann ich abspecken.

Vielleicht muß ich mal die Inhaltsverzeichnisse in eine Datei schreiben und vergleichen.

Grüße von der Nordsee

Peter

[Peter18]

Ein freundsliches Hallo an alle,

nach mehreren Tagen Dauerbackup (mit gebremsten Schaum [--bwlimit=1000]) zeigt sich, dass die Probleme bei einem Backup ins Leere, also ohne Vorgängerbackup, nicht auftreten, es gibt also keinen Fehler. In dem ersten Vorgängerbackup zeigten sich aber Fehler in der Gruppenberechtigung (nicht 7). In einigen Fällen fehlte das Schreibrecht. Vermutlich aus der Anfangsphase mit Samba bei der Übertragung von Novell auf Linux entstanden. Daher anscheinend "(code 12)".

Etwas unschön ist, dass im Backup der Backupuser als Eigentümer eingetragen wird, aber nicht der ursprüngliche. Gibt es einen Parameter, mit dem das geändert werden kann? Ich habe noch nichts gefunden (vielleicht übersehen) oder muß ich da mit einem Skript bei?.

Es treten noch Fehler "cannot delete non-empty directory" auf. Verschobene oder gelöschte nicht leere Ordner. Wie kann ich das beheben?

Grüße von der Nordsee

Peter

[Peter18]

Ein freundsliches Hallo an alle,

ich werde diese Fragen noch einmal in einem neuen Thred stellen, sie passen ja nicht ganz zum Thema.

Grüße von der Nordsee

Peter