staging.inyokaproject.org

noisefloor schrieb:

Hallo,

relativ zu was bzw. welchem Pfad eigentlich? Das ist mir gerade nicht ganz klar...

Ich wollte eigentlich dieses Skript im Wiki Skripte/Backup mit RSYNC (Abschnitt „Beispiel-Minimal-Variante“) für die Sicherung über ssh abwandeln. Aber hier muss zumindest bei der Option --link-dest ein relativer Pfad zur letzten Sicherung im Target angegeben werden, sonst funktionierte es nicht:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

#!/bin/sh

heute=$(date +%Y-%m-%d)
gestern=$(date -d '-1 day' +%Y-%m-%d)

# aus Ubuntuusers:
# rsync -avR --delete "${quelle}"  "${ziel}${heute}/" --link-dest="${ziel}last/"
# ln -nsf "${ziel}${heute}" "${ziel}last"

rsync --numeric-ids --delete -avze ssh "/home/user" "admin@server:/share/Store/Backup/${heute}/" --link-dest="../${gestern}/"
ssh admin@server ln -nsf "/share/Store/Backup/${heute}" "/share/Store/Backup/${gestern}"

exit 0

Gelöscht (gehörte hier nicht hin)

ui schrieb:

Gelöscht (gehörte hier nicht hin)

Doch. Gehört genau hier hin. Wer hat denn gesagt, dass es nicht hier hin gehört? 😲 Verbesserungsvorschläge zu einem Artikel gehören in die Diskussion zu dem Artikel.

Verbesserungsvorschlag des Abschnitts Sicherung von entferntem Rechner auf lokalen Rechner (Wiki-Artikel rsync (Abschnitt „Sicherung-von-entferntem-Rechner-auf-lokalen-Rechner“)):

Dort steht:

Sollen dem SSH-Befehl weitere Optionen angehängt werden, z.B. -i, um einen abweichenden Private-Key bei der Anmeldung zu übergeben, muss der SSH-Befehl in einfache Anführungszeichen gesetzt werden, etwa so:

Der von mir gelb markierte Teil ist für mich irreführend weil man auch doppelte Anführungszeichen verwenden kann. Mein Vorschlag wäre daher ihn um den unterstrichenen Text zu erweitern: muss der SSH-Befehl in einfache oder doppelte Anführungszeichen gesetzt werden

Ich hab noch nie einen Wiki-Artikel bearbeitet. Soll ich das selber machen? Habt Ihr Verbesserungsvorschläge zu meinem Vorschlag?

ui schrieb:

Ich hab noch nie einen Wiki-Artikel bearbeitet. Soll ich das selber machen?

Bitte. Du wirst sehen, es ist eigentlich ganz einfach.

ui schrieb:

Der von mir gelb markierte Teil ist für mich irreführend weil man auch doppelte Anführungszeichen verwenden kann. Mein Vorschlag wäre daher ihn um den unterstrichenen Text zu erweitern: muss der SSH-Befehl in einfache oder doppelte Anführungszeichen gesetzt werden

Wenn das definitiv so ist, einfach ändern. Wenn sowohl einfache als auch doppelte Anführungszeichen möglich sind, könnte man auch einfach sagen:

muss der SSH-Befehl in Anführungszeichen gesetzt werden

Ich glaube nicht, dass jemand versucht, dreifache Anführungszeichen zu verwenden ☺

Danke, habe den Artikel geändert.

Hallo Da ich rsync im Moment viel nutze, habe ich mich mit dem automatischen Start befasst und der Übergabe des Passwortes an das Programm

Da das hier fehlt? Soll das rein, Passwort automatisch auslesen zum starten?

Grüße

Hallo,

welches Passwort für was? Poste mal hier im Thread bitte den Befehl oder die Befehle, die du einfügen würdest.

Gruß, noisefloor

Hallo

Hier fehlt auch die Installation der aktuellen Version aus der Source. Das war ganz schön wirr, aber ich hab es.

rsync  version 3.2.4  protocol version 31

Somit entfällt die Passwort Abfrage im benutzten Verzeichnis. Für die automatisierte Übertragung (Cronjob), sonnst muss das händisch.

rsync -aP -e \
    "sshpass -f 'pw.txt' ssh -o StrictHostKeyChecking=no" \
    --progress bla bla bla usw.

Im Artikel steht:

-P aktiviert folgende Optionen: --progress Fortschrittsanzeige beim Transfer anzeigen --partial Fortsetzung des Transfers bei Abbruch

rsync hält an / setzt aber nicht fort 7 muss manuell neu gestartet werden

Besser wäre : --partial Bisher übertragene Dateien bleiben erhalten.

Einen automatisierten Neustart von rsync habe ich noch nicht hinbekommen.

Option --timeout=60 sollte mit in die Liste, dies wird benötigt für einen automatischen Neustart nach Abbruch.

Automatisierte Wiederholung sollte mit in den Artikel, wird oft gesucht im Netz. Meine automatische Wiederholung läuft jetzt.

sending incremental file list
karte-07.zip
     42.246.720   2%  558,45kB/s    0:52:28  
[sender] io timeout after 60 seconds -- exiting
rsync error: timeout in data send/receive (code 30) at io.c(200) [sender=3.2.7]
Rsync failure. Backing off and retrying...
sending incremental file list
karte-07.zip
     50.831.936   2%  569,96kB/s    0:51:09  
[sender] io timeout after 60 seconds -- exiting
rsync error: timeout in data send/receive (code 30) at io.c(200) [sender=3.2.7]
Rsync failure. Backing off and retrying...
sending incremental file list
karte-07.zip
    256.483.904  14%  799,26kB/s    0:32:11  ^C
rsync error: unexplained error (code 255) at rsync.c(713) [sender=3.2.7]
Rsync failure. Backing off and retrying...

Habe --timeout=60 heute zugefügt, dies ist wichtig für automatisierte Neustarts bei Verbindungsproblemen. Ein kompletter Absatz wäre Sinnvoll für automatisierten Neustart bei Verbindungsproblemen, sowie automatisiert hochladen ohne manuelle Abfrage des Passwortes für den Zielserver. Ich nutze jetzt rsync mit einer Wiederholungsschleife und automatischem Upload, dass läuft.

Grüße

Im Abschnitt https://wiki.ubuntuusers.de/rsync/#Sicherung-innerhalb-des-Systems heißt es am Schluss des roten Kastens:

Beide Optionen benötigen allerdings wesentlich mehr Zeit, weswegen man dies nur im Notfall einsetzen sollte.

Was soll der Unsinn mit „nur im Notfall“? Ich persönlich setze die Option -c immer, wenn ich eine Spiegelung meines Homeverzeichnisses ziehe. Nur dann weiß ich, dass keine defekten Leichen von früher in der Sicherung liegen, die nicht als solche erkannt wurden. Ich muss halt wissen, dass es mit dieser Option viermal so lange dauert wie ein simpler Vergleich nach Zeitstempel und Größe.

Aber das hat doch nichts mit einem Notfall zu tun! Eher würde ich sagen, dass -c (als sicherere Option) zu bevorzugen ist und man nur dann, wenn die Zeit knapp ist, darauf verzichten sollte.

--ks

Berlin_1946 schrieb:

Im Abschnitt https://wiki.ubuntuusers.de/rsync/#Sicherung-innerhalb-des-Systems heißt es am Schluss des roten Kastens:

Beide Optionen benötigen allerdings wesentlich mehr Zeit, weswegen man dies nur im Notfall einsetzen sollte.

Was soll der Unsinn mit „nur im Notfall“?

Ja, die Formulierung führt in die Irre. Ich habe die Warnbox überarbeitet und nun auch zutreffender als Hinweis formatiert.

Danke für den Hinweis.

Abschnitt "rsync als Daemon"

Nachdem ich wieder um die gleiche "Falle" gestolpert bin, würde ich die Dokumentation hinsichtlich einer Einrichtung eines rsync als Daemon auf zumindest einem Ubuntu 22.04 Server wie folgt um die eigentlich sinnvolle Möglichkeit, bei Systemstart diesen Dienst mit zu starten, wie folgt ergänzen:

1. Überprüfung, ob der Dienst (daemon) gestartet ist oder nicht.

1

sudo systemctl status rsync

2. Dienst (daemon) manuell starten und stoppen

1
2

sudo systemctl start rsync
sudo systemctl stop rsync

3. Server einrichten, Dienst (daemon) bei Systemstart automatisch zu starten bzw. nicht zu starten.

1
2

sudo systemctl enable rsync
sudo systemctl disable rsync

Hintergrund hierfür sind die vielen zum Teil irreführenden Dokumentationen, die zum einen zum Teil gar nicht funktionieren und zum anderen abweichend von dem grundlegenden Prinzip https://wiki.ubuntuusers.de/systemd/ eine Konfiguration vorsieht.

yauu schrieb:

Abschnitt "rsync als Daemon" […]

Ja, im Artikel fehlten Verweise auf systemd und systemctl, die ich nun im Abschnitt Installation ergänzt habe. Eine Wiederholung der bekannten Standardbefehle an Systemd zum Umgang mit Units erscheint mir aber in diesem Artikel entbehrlich.

rsync (Abschnitt „Gesamtes-System-mit-root-Rechten“)

Hierzu habe ich eine Frage. Bei einem Backup, der auf System A erstellten timeshift Schnappschüsse, auf/nach System B, werden für die erzeugten Ordner und Dateien, auf System B, die Besitzrechte des für den Transfer verwendeten Benutzer gesetzt. Ist dies nicht hinderlich bei einer späteren Verwendung des Backups?

Derzeit erstelle ich Backups mit root.

1
2

#!/bin/bash
rsync -aHAXEz --numeric-ids --delete -r --progress /mnt/timeshift/timeshift root@192.168.1.102:/mnt/backup/laptop/