Rsync - Backuprobleme (differentiell)

[Daether]

Moin Moin,
ich verusche gerade mit rsync ein Backupsystem aufzusetzen.
Der Plan sieht dabei vor, auf einem Backupserver ein Skript aufzurufen, welches alte Ordner löscht und neue per Rsync kopiert.
Dabei soll an einem Wochentag immer ein Vollbackup gemacht werden, an den restlichen ein differentielles Backup.
Zusätzlich soll das Ganze nicht über einen Root-Zugang verbunden sein.

Dabei habe ich 2 Ansätze:
1. Skript liegt auf dem Backupserver
Problem: User auf dem zu Backuppenden Server fehlen die Rechte Dateien zu lesen.
Dafür habe ich einen User auf dem zu backuppenden Server angelegt und ihm per visudo "backupper ALL=(root)NOPASSWD:/usr/bin/rsync" eingetragen. Allerdings können Dateien mit "700" die root gehören, nicht kopiert werden. Ich kriege da die Meldung "rsync: send_files failed to open "/root/backup_rsync_test/test.txt": Permission denied (13)".

2. Skript liegt auf dem zu backuppenden Server
Das Problem an diesr Lösung ist, dass --compare-dest nicht mit "root@192....." funktioniert. Der Parameter wird dabei völlig ignoriert und es wird ein Vollbackup gemacht.

Hat jemand eine Idee, wie ich das Ganze lösen kann ?

[uname]

Also ich nutze folgendes Script:

http://wiki.ubuntuusers.de/Skripte/Backup_mit_rsync

Bei Sicherungen über SSH läuft das Script auf dem Backupserver, da nur er inkrementell die Funktion "--link-dest" nutzen kann. Zugriff braucht man auf dem zu backupenden Server natürlich als "root". Um das einzuschränken kann man evtl. in /root/.ssh/authorized_keys2 auf dem zu backupenden Server den Public-SSH-Key des backupenden Benutzers (auch root) des Backupservers mit dem Befehl "command=/usr/bin/rsync" einbauen. Nicht probiert. Unsicherer als das sudo-Zeug ist das auch nicht. Mit "sudo" bist du für den genannten Befehl auch "root". Da gefällt mir die eingeschränkte SSH-Key-Geschichte um einiges besser.

[Danielx]

Zugriff braucht man auf dem zu backupenden Server natürlich als "root". Um das einzuschränken kann man evtl. in /root/.ssh/authorized_keys2 auf dem zu backupenden Server den Public-SSH-Key des backupenden Benutzers (auch root) des Backupservers mit dem Befehl "command=/usr/bin/rsync" einbauen. Nicht probiert. Unsicherer als das sudo-Zeug ist das auch nicht. Mit "sudo" bist du für den genannten Befehl auch "root". Da gefällt mir die eingeschränkte SSH-Key-Geschichte um einiges besser.

Siehe dazu:
viewtopic.php?p=726971#p726971

edit:
@uname
viewtopic.php?p=764011#p764011


Gruß,
Daniel

[Daether]

Moin,
hab mein bestehendes Skript jetzt soweit abgeändert, dass zwar mit root verbunden wird, allerdings die Verbindung von zu backuppenden Server kommt und diese dann auf rsync durch "/usr/local/bin/check_command" geprüft wird.
Danke dir schonmal dafür Daniel !

Allerdings lößt das nicht das Problem, dass ich so immer nur ein Vollbackup mit rsync machen kann .

--compare-dest geht anscheinend nicht über ssh, gibts da nen anderen Weg ?

[Danielx]

rsnapshot sichert inkrementell, nicht differenziell, falls das etwas für dich sein sollte.

Gruß,
Daniel

[Daether]

Moin,
ich schaue mir rsnapshot morgen mal an.

Differentiell wäre mir nur lieber, da sich die Daten auf den Servern nur wenig ändern und differentielle Backups leicht wieder einzuspielen sind.
Zumal ich jeweils einmal die Woche ein Vollbackup machen wollte und ich inkrementellen Backups nicht so sehr traue ^^-

[peschmae]

Wie kommt ihr denn alle drauf, --link-dest und so funktionierten nur wenn das Backup-Script auf dem Backupserver und nicht auf dem zu backuppenden Computer läuft? Ich benutze genau diese Kombination schon seit langem in meinen Scripts...

z.B. so wie hier: http://nopaste.debianforum.de/35098 - das Script läuft auf dem Client (dort zwingenderweise mit Root-Rechten, da es auch /etc und /root backuppen soll, kann z.B. durch cron gestartet weren), loggt sich mittels SSH Public Keys selbständig auf den Backupserver ein (als unprivilegierter User, der nur Rechte am Backup-Zielordner hat) und speichert beginnt zu rsyncen.

Dateien landen erstmal in /backup/hostname/current, mit hardlinks in den Ordner, auf den der Symlink /backup/hostname/latest verweist; wenn das Backup erfolgreich war, wird "current" in "20101109_xyz" umbenannt und im gleichen Zug der Symlink "latest" auf "20101109_xyz" umgelinkt. Wird das Backup unterbrochen, dann setzt es ein erneuter Aufruf des Scripts so gut wie nahtlos fort, rsync sei Dank...

Neue Komplettbackups erzwingen kann das script noch nicht, genausowenig wie alte Backups löschen (ersteres ist einfach zu implementieren, aber dafür habe ich keinen Bedarf - ein rsync mit checksummen reicht mir da lange als Versicherung; für letzteres habe ich ein weiteres, separates Script gebastelt).

MfG Peschmä

[Daether]

Moin,
ich bin leider nicht sehr gut was shellscripting angeht und werde da erst Montag mit durch sein das Ganze vollständig zu verstehen.

Allerdings sind mir da 2 Dinge nicht ganz klar :
1. Ich nutze folgenden Befehl fürs das reine Vollbackup einzelner Ordner :
"rsync -a --progress --rsh='ssh -p12695' /root backupper@192.168.1.7:/var/backups/testserver/20101111"
Der Befehl wird auch durchgeführt, allerdings gehört dann jede Datei des Backups dem User backupper. Ich bräuchte da eigendlich die original uid/gid des Backupservers, da ich z.B. einen FTP-Server backuppe, auf dem es verschiedene FTP-User gibt. Wie ist das bei euch gelößt ?
2. Was mir nicht ganz klar ist, mit "--link-dest=../latest" vergleichst du doch auf deinem zu backuppenden Server ../latest mit / um die Unterschiede auf $TARGET_HOST:$TARGET_BASEDIR/current zu speichern, oder verstehe ich das falsch ?
Der Gedanke von mir war, mit compare-dest direkt das bestehende Vollbackup auf dem Backupserver mit dem Datenbestand auf zu backuppenden Server zu vergleichen.

[uname]

Wie ist das bei euch gelößt ?

Nur Benutzer "root" darf Dateien mit fremden Benutzerkennungen anlegen.

Code: Alles auswählen

link-dest

Bei link-dest wird mit dem dort genannten Verzeichnis verglichen. Sollte die Datei abweichen, so wird sie neu kopiert. Sollte sie nicht abweichen (also gleich sein), so wird nur ein Hardlink gesetzt.

Beispiel: /etc/passwd hat sich lange nicht geändert (Auszug einer echten Ausgabe):

Code: Alles auswählen

 
stat /media/backup/Tag/101110/etc/passwd
  File: »/media/backup/Tag/101110/etc/passwd«
  Size: 2614            Blocks: 8          IO Block: 4096   reguläre Datei
Device: 302h/770d       Inode: 227555      Links: 15
...
stat /media/backup/Tag/101109/etc/passwd
  File: »/media/backup/Tag/101109/etc/passwd«
  Size: 2614            Blocks: 8          IO Block: 4096   reguläre Datei
Device: 302h/770d       Inode: 227555      Links: 15
...

Interesant sind die Inodes, da sie identisch sind. Insgesamt 15 Dateien (Links: 15) sind identisch. Mein System hat somit 15 Sicherungen der Datei /etc/passwd, die jedoch nur einmalig Platz brauchen. Sollte ich die Datei /etc/passwd ändern, so werden weiterhin die alten Versionen identisch sein und das neue Backup wird auf eine neue Inode verweisen ...

[peschmae]

1. Ich nutze folgenden Befehl fürs das reine Vollbackup einzelner Ordner :
"rsync -a --progress --rsh='ssh -p12695' /root backupper@192.168.1.7:/var/backups/testserver/20101111"
Der Befehl wird auch durchgeführt, allerdings gehört dann jede Datei des Backups dem User backupper. Ich bräuchte da eigendlich die original uid/gid des Backupservers, da ich z.B. einen FTP-Server backuppe, auf dem es verschiedene FTP-User gibt. Wie ist das bei euch gelößt ?

Das habe ich nicht gelöst. Ich wüsste auch nicht wie - auf dem Backupserver gibt es ja nicht notwendigerweise all dieselben User wie auf dem Backup-Client.

Das läuft dann auf eine separate Speicherung der Dateirechte hinaus (in einer eigenen Datei), was meinen eigenen Anforderungen an so ein System (restore durch einfaches zurückkopieren) entgegenläuft...

2. Was mir nicht ganz klar ist, mit "--link-dest=../latest" vergleichst du doch auf deinem zu backuppenden Server ../latest mit / um die Unterschiede auf $TARGET_HOST:$TARGET_BASEDIR/current zu speichern, oder verstehe ich das falsch ?
Der Gedanke von mir war, mit compare-dest direkt das bestehende Vollbackup auf dem Backupserver mit dem Datenbestand auf zu backuppenden Server zu vergleichen.

Genau das mache ich ja auch; ../latest ist auf dem Backupserver, währenddem / auf dem zu Backuppenden Server ist (auf dem auch das Script aufgerufen wird). Unveränderte Dateien werden wie von uname erwähnt mittels Hardlinks aus ../latest in den neuen Verzeichnisbaum übernommen.

MfG Peschmä

[Danielx]

Der Befehl wird auch durchgeführt, allerdings gehört dann jede Datei des Backups dem User backupper. Ich bräuchte da eigendlich die original uid/gid des Backupservers, da ich z.B. einen FTP-Server backuppe, auf dem es verschiedene FTP-User gibt. Wie ist das bei euch gelößt ?

Das habe ich nicht gelöst. Ich wüsste auch nicht wie - auf dem Backupserver gibt es ja nicht notwendigerweise all dieselben User wie auf dem Backup-Client.

Hm, aber da hilft doch "--numeric-ids", wenn ich das Problem richtig verstanden habe, als root muss dabei natürlich auch gearbeitet werden.

Gruß,
Daniel

[Daether]

Ich hab mir das Ganze jezt nochmal durchgelesen und das Skript von peschmae angeschaut.
Ich werde wohl nicht um die Rootrechte herumkommen, da ich die UIDs und GID brauche.

Eines ist mir allerdings imemrnoch nicht richtig klar an peschmaes Skript:
Wenn das Skript von zu backuppenden Server ausgeführt wird, wie kann dann "../latest" auf dem Backupserver sein ? Sucht er nichtr dadurch auf dem Clientserver nach "../latest" ?

[uname]

Wenn das Skript von zu backuppenden Server ausgeführt wird, wie kann dann "../latest" auf dem Backupserver sein ? Sucht er nichtr dadurch auf dem Clientserver nach "../latest" ?

Hätte ich auch gedacht. leider kenne ich noch keine Möglichkeit ein inkrementelles rsync auf dem Client laufen zu lassen. Würde ich aber gerne haben. Im übrigen soll backuppc diese Probleme nicht haben, obwohl es unter anderem auch rsync nutzt. Vielleicht kann das Programm ja mal jemand genauer betrachten.

[Danielx]

Eines ist mir allerdings imemrnoch nicht richtig klar an peschmaes Skript:
Wenn das Skript von zu backuppenden Server ausgeführt wird, wie kann dann "../latest" auf dem Backupserver sein ? Sucht er nichtr dadurch auf dem Clientserver nach "../latest" ?

--link-dest=DIR
(...)
If DIR is a relative path, it is relative to the destination directory.

Und:

Push: rsync [OPTION...] SRC... [USER@]HOST:DEST

Jetzt alles klar?

Gruß,
Daniel

[Daether]

Ich glaub schon *Hand vor Kopf*
Da --compare-dest sich gleich verhält ( "If DIR is a relative path, it is relative to the destination directory." ) hab ich mal was gebastelt und getestet :

Also im Beispiel
BackupServer ( 172.16.1.5 )

Code: Alles auswählen

~/backup_rsync_test/172.16.1.6/changes
~/backup_rsync_test/172.16.1.6/full

Client ( 172.16.1.6 )

Code: Alles auswählen

~/backup_rsync_test/test.txt
später :
~/backup_rsync_test/test.txt
~/backup_rsync_test/test2.txt
Vollbackup = test.txt , differentielles Backup = test2.txt

Ziel:
1. Vollbackup machen und test1.txt syncen.
2. test2.txt anlegen und differentielles Backup machen mit --compare-dest.

Vollbackup :

Code: Alles auswählen

rsync -avz /root/backup_rsync_test/* root@172.16.1.5:/root/backup_rsync_test/172.16.1.6/full
sending incremental file list
test.txt

Differentiell :

Code: Alles auswählen

rsync -avz --compare-dest=/root/backup_rsync_test/172.16.1.6/full /root/backup_rsync_test/* root@172.16.1.5:/root/backup_rsync_test/172.16.1.6/changes
sending incremental file list
test2.txt

Erbebnis :

Code: Alles auswählen

~/backup_rsync_test/172.16.1.6/changes/test2.txt
~/backup_rsync_test/172.16.1.6/full/test1.txt

Sieht doch alles super aus !
Jetzt noch ein management drum bauen für die anderen Tage und rsync funktioniert auch differentiell wenn ichs richtig sehe.

Ich danke euch allen nud vorallem Daniel für die Geduld !

MfG
Daether