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

[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