1
Rsync-Backup unabhängig von ssh-version?
Hallo!
Bin gerade einen Backup-Server für Linux Rechner am bauen. Habe dafür ein Bash-Skript geschrieben, welches die Informationen (IP, Welche Pfade sollen gesichert werden) aus einer config zieht, daraus die rsync-befehle baut und nacheinander ausführt (mit automatischer ssh-Einwahl über public-keys). Allerdings bin ich jetzt bei ein paar älteren Linux Rechnern auf die SSH-Protokollversion 1 gestoßen. SSH Verbindungen funktionieren dahingehend (ssh -1 *IP*), doch für rsync habe ich da noch keine Lösung gefunden. Gibt es eine Möglichkeit, rsync zu sagen, dass der zu sichernde Rechner noch mit der version 1 läuft? Kann man vielleicht sogar irgendwo einstellen, dass es rsync "egal" sein soll? Möchte ungern ssh auf den alten Rechnern updaten, da sich dort oft noch andere Server über einen Public-key einwählen. Ich nicht weiß, welche Auswirkungen das hätte, bzw inwiefern man die authorized_keys übernehmen kann.
Mein bisheriger Versuch:
rsync -avz --delete -e "ssh -1" user@ip:/Pfad /lokaler/Pfad/
Funktionierte, allerdings möchte ich, dass während dem rsync nicht mehr vorhandene Dateien/Ordner in einem Backup-Pfad gesichert werden, also:
rsync -avzb --backup-dir=/lokaler/Pfad/.gelöscht/ --delete user@ip:/Pfad /lokaler/Pfad/
Funktionierte auch. Blöd ist nur, dass ich es bisjetzt nochnicht geschafft habe, diese beiden Befehle zu kombinieren:
rsync -avzb --backup-dir=/lokaler/Pfad/.gelöscht/ --delete -e "ssh -1"user@ip:/pfad /lokaler/pfad
Fehler: rsync: unrecognized option `--backup-dir'
Bin gerade einen Backup-Server für Linux Rechner am bauen. Habe dafür ein Bash-Skript geschrieben, welches die Informationen (IP, Welche Pfade sollen gesichert werden) aus einer config zieht, daraus die rsync-befehle baut und nacheinander ausführt (mit automatischer ssh-Einwahl über public-keys). Allerdings bin ich jetzt bei ein paar älteren Linux Rechnern auf die SSH-Protokollversion 1 gestoßen. SSH Verbindungen funktionieren dahingehend (ssh -1 *IP*), doch für rsync habe ich da noch keine Lösung gefunden. Gibt es eine Möglichkeit, rsync zu sagen, dass der zu sichernde Rechner noch mit der version 1 läuft? Kann man vielleicht sogar irgendwo einstellen, dass es rsync "egal" sein soll? Möchte ungern ssh auf den alten Rechnern updaten, da sich dort oft noch andere Server über einen Public-key einwählen. Ich nicht weiß, welche Auswirkungen das hätte, bzw inwiefern man die authorized_keys übernehmen kann.
Mein bisheriger Versuch:
rsync -avz --delete -e "ssh -1" user@ip:/Pfad /lokaler/Pfad/
Funktionierte, allerdings möchte ich, dass während dem rsync nicht mehr vorhandene Dateien/Ordner in einem Backup-Pfad gesichert werden, also:
rsync -avzb --backup-dir=/lokaler/Pfad/.gelöscht/ --delete user@ip:/Pfad /lokaler/Pfad/
Funktionierte auch. Blöd ist nur, dass ich es bisjetzt nochnicht geschafft habe, diese beiden Befehle zu kombinieren:
rsync -avzb --backup-dir=/lokaler/Pfad/.gelöscht/ --delete -e "ssh -1"user@ip:/pfad /lokaler/pfad
Fehler: rsync: unrecognized option `--backup-dir'
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 235587
Url: https://administrator.de/contentid/235587
Printed on: April 23, 2024 at 15:04 o'clock
1 Comment
Hallo,
Damit kannst du stündliche, tägliche und wöchentliche Backups planen, welche dann eine bestimmte Zeit lang vorgehalten werden.
Es ist damit auch möglich, die Backups von einem Remote-System über SSH abzuholen.
Weiterhin kann SSH über folgende Parameter konfiguriert werden:
- cmd_ssh (gibt den Pfad zu SSH an -> Im Notfall halt ein kleines Wrapper-Script schreiben)
- ssh_args (übergibt Argumente an SSH)
Für den Benutzer sieht ein sauber konfiguriertes rsnapshot Backup dann (zum Beispiel) so aus:
/data <- Aktueller Datenstand
/data/.snapshot <- Backup Link (unzerstörbar)
/data/.snapshot/hourly.0 <- Zustand der Daten bei der letzten stündlichen Sicherung
/data/.snapshot/hourly.1 <- Zustand der Daten bei der vorletzten stündlichen Sicherung
...
/data/.snapshot/daily.0 <- Zustand der Daten heute um Mitternacht
/data/.snapshot/daily.1 <- Zustand der Daten gestern um Mitternacht
...
/data/.snapshot/weekly.0 <- Zustand der Daten letzten Sonntag um Mitternacht
/data/.snapshot/weekly.1 <- Zustand der Daten vorletzten Sonntag um Mitternacht
Der Clou daran ist, dass nur Speicherplatz für die Unterschiede benötigt wird, der User aber trotzdem immer alle Daten in den Snapshots sieht.
Wenn das über SSH läuft, brauchst du halt zusätzlich den Speicherplatz für ein vollständiges Backup.
Grüße,
Daniel
Bin gerade einen Backup-Server für Linux Rechner am bauen. Habe dafür ein Bash-Skript geschrieben, welches die
Informationen (IP, Welche Pfade sollen gesichert werden) aus einer config zieht, daraus die rsync-befehle baut und nacheinander
ausführt (mit automatischer ssh-Einwahl über public-keys).
Du musst das Rad nicht neu erfinden, rsnapshot (siehe rsnapshot.org) macht genau das.Informationen (IP, Welche Pfade sollen gesichert werden) aus einer config zieht, daraus die rsync-befehle baut und nacheinander
ausführt (mit automatischer ssh-Einwahl über public-keys).
Damit kannst du stündliche, tägliche und wöchentliche Backups planen, welche dann eine bestimmte Zeit lang vorgehalten werden.
Es ist damit auch möglich, die Backups von einem Remote-System über SSH abzuholen.
Weiterhin kann SSH über folgende Parameter konfiguriert werden:
- cmd_ssh (gibt den Pfad zu SSH an -> Im Notfall halt ein kleines Wrapper-Script schreiben)
- ssh_args (übergibt Argumente an SSH)
Für den Benutzer sieht ein sauber konfiguriertes rsnapshot Backup dann (zum Beispiel) so aus:
/data <- Aktueller Datenstand
/data/.snapshot <- Backup Link (unzerstörbar)
/data/.snapshot/hourly.0 <- Zustand der Daten bei der letzten stündlichen Sicherung
/data/.snapshot/hourly.1 <- Zustand der Daten bei der vorletzten stündlichen Sicherung
...
/data/.snapshot/daily.0 <- Zustand der Daten heute um Mitternacht
/data/.snapshot/daily.1 <- Zustand der Daten gestern um Mitternacht
...
/data/.snapshot/weekly.0 <- Zustand der Daten letzten Sonntag um Mitternacht
/data/.snapshot/weekly.1 <- Zustand der Daten vorletzten Sonntag um Mitternacht
Der Clou daran ist, dass nur Speicherplatz für die Unterschiede benötigt wird, der User aber trotzdem immer alle Daten in den Snapshots sieht.
Wenn das über SSH läuft, brauchst du halt zusätzlich den Speicherplatz für ein vollständiges Backup.
Allerdings bin ich jetzt bei ein paar älteren Linux
Rechnern auf die SSH-Protokollversion 1 gestoßen. SSH Verbindungen funktionieren dahingehend (ssh -1 *IP*), doch für
rsync habe ich da noch keine Lösung gefunden. Gibt es eine Möglichkeit, rsync zu sagen, dass der zu sichernde Rechner
noch mit der version 1 läuft? Kann man vielleicht sogar irgendwo einstellen, dass es rsync "egal" sein soll?
[...]
Funktionierte auch. Blöd ist nur, dass ich es bisjetzt nochnicht geschafft habe, diese beiden Befehle zu kombinieren:
rsync -avzb --backup-dir=/lokaler/Pfad/.gelöscht/ --delete -e "ssh -1"user@ip:/pfad /lokaler/pfad
Fehler: rsync: unrecognized option `--backup-dir'
Das kommt vermutlich daher, dass auf den alten Kisten mit SSH 1 auch ein ewig altes rsync rumliegt, welches mit dem Parameter --backup-dir nix anfangen kann.Rechnern auf die SSH-Protokollversion 1 gestoßen. SSH Verbindungen funktionieren dahingehend (ssh -1 *IP*), doch für
rsync habe ich da noch keine Lösung gefunden. Gibt es eine Möglichkeit, rsync zu sagen, dass der zu sichernde Rechner
noch mit der version 1 läuft? Kann man vielleicht sogar irgendwo einstellen, dass es rsync "egal" sein soll?
[...]
Funktionierte auch. Blöd ist nur, dass ich es bisjetzt nochnicht geschafft habe, diese beiden Befehle zu kombinieren:
rsync -avzb --backup-dir=/lokaler/Pfad/.gelöscht/ --delete -e "ssh -1"user@ip:/pfad /lokaler/pfad
Fehler: rsync: unrecognized option `--backup-dir'
Möchte ungern ssh auf den alten Rechnern updaten, da sich dort oft noch andere Server über einen Public-key
einwählen. Ich nicht weiß, welche Auswirkungen das hätte, bzw inwiefern man die authorized_keys übernehmen
kann.
Ich bin jetzt nicht fit mit SSHv1, aber allein deswegen würde ich dieses Sicherheits-Scheunentor nicht offen stehen lassen.einwählen. Ich nicht weiß, welche Auswirkungen das hätte, bzw inwiefern man die authorized_keys übernehmen
kann.
Grüße,
Daniel
