ubuntuusers.de

... das heißt es eigentlich nicht.

... aber mindestens doppelt so viel Speicherkapazität (wie das, was du sicherst) auf deinem Fileserver brauchst du.

theinlein schrieb:

... das heißt es eigentlich nicht.

Damit meinst Du meine Vermutung mit tar.gz? Dann ist mir völlig rätselhaft, wie so ein Backup vor sich gehen sollte.

theinlein schrieb:

... aber mindestens doppelt so viel Speicherkapazität (wie das, was du sicherst) auf deinem Fileserver brauchst du.

So sehe ich das auch.

Gruß compiopa

nein, nicht mit tar.gz. Man kann ja lokal durchaus rsync verwenden.

Er meint aber (so wie ich das verstanden habe), die Rechte ändern. Und dann als 'backupuser' weiterarbeiten. Das kann man ja wieder mit rsync. Nur hätte man dann eben die Rechte verfälscht. Es mag ja so sein, dass der backupuser nicht alles lesen darf ☹

Wenn man stattdessen zusammenpackt und transferiert, kann man ja gleich tar verwenden - das würde ich dann auch so sehen.

theinlein schrieb:

nein, nicht mit tar.gz. Man kann ja lokal durchaus rsync verwenden.

Das ist schon klar, aber die clevere speicherplatzschonende hardlink Methode mit Bezug auf die letzte Sicherung von rsync würde meiner Meinung nach nicht funktionieren.

Er meint aber (so wie ich das verstanden habe), die Rechte ändern. Und dann als 'backupuser' weiterarbeiten. Das kann man ja wieder mit rsync. Nur hätte man dann eben die Rechte verfälscht. Es mag ja so sein, dass der backupuser nicht alles lesen darf ☹

Die Rechte sollten schon so bleiben wie sie sind. Könnte ja sein, man muß mal ein komplettes Backup zurücksichern. Wer stellt dann die Rechte wieder richtig ein. 😀

Wenn man stattdessen zusammenpackt und transferiert, kann man ja gleich tar verwenden - das würde ich dann auch so sehen.

Das war ja auch mein erster Gedanke.

Gruß compiopa

Hallo allerseits,

gemäß meinem Motto (siehe unten) hab' ich es hinbekommen. 😀

Die Lösung möchte ich Euch natürlich nicht vorenthalten.

Hinweis: beachte, dass das Backup vom Backupserver gesteuert wird, also rsync holt die Daten auf den Rechner, auf dem das Script läuft.

Hier nun meine Lösung:

### Einstellungen SSH
SSHUSER="backupuser"                                                # Username des Users für SSH auf dem Server
SERVER_IP="###.###.###.###"
SSH="/usr/bin/ssh -i /home/backupuser/.ssh/id_rsa"                  # der komplette SSH Aufruf

### Einstellungen rsync
QUELLE="${SSHUSER}@${SERVER_IP}:/pfad/zur/quelle/"                  # Pfad zur Quelle
RSYNCZIEL="/datensicherung/2010-11-04/"                             # Pfad zur Sicherung (erzeuge ich zur Laufzeit [LZ])

RSYNC="/usr/bin/rsync -abv --stats --delete --delete-excluded -e"   # Rsync-Befehl mit den Optionen OHNE Zusatzangaben

RMSYNCBEFEHL="--rsync-path="                                        # remote rsync
RMSYNCPATH="sudo /usr/bin/rsync"                                    # Aufruf des remote rsync
EXCLBEFEHL="--exclude-from="                                        # auszuschliessen aus
EXCLDATEI="/home/backupuser/bin/excludedatei.txt"                   # Datei (relativ zur Quelle!)

# Folgesicherungen mit Hard-Links
LIDESTBEFEHL="--link-dest="
LIDESTPATH="/datensicherung/2010-11-03"                             # Der Pfad auf den sich die Hard-Links beziehen [LZ]
LOGDATEI="/home/backupuser/logs/logdatei"                           # Logdatei



$RSYNC "${SSH}" ${RMSYNCBEFEHL}"${RMSYNCPATH}" ${EXCLBEFEHL}"${EXCLDATEI}" ${QUELLE} ${RSYNCZIEL} >> $LOGDATEI 2>&1

Das funktioniert bei mir sowohl "manuell" als auch per cron.

Randbedingungen bzw. sonstige Einstellungen:

1) "backupuser" ist auf beiden Systemen eingerichtet

2) "backupuser" kann sich mittels public key ohne Passwort bei dem remote host einloggen

3) auf dem remote host steht in der Datei /etc/sudoers "backupuser ALL=NOPASSWD: /usr/bin/rsync"

Gruß compiopa und danke an die, die sich mit meinem Problem beschäftigt haben

Hi compiopa,

Hm, ungefähr so sie das Skript bei mir auch aus, allerdings mit dem Unterschied, dass ich meine Variablen nicht mittels Anfürungszeichen oder geschwungenen Klammern anspreche sondern nur mit Dollarzeichen davor. Das könnte das Problem sein.

1

"${SSH}" ${RMSYNCBEFEHL}"${RMSYNCPATH}"

Kannst du mir kurz erklären, warum du das macht und warum nicht alle Variablen in Anführungszeichen verpackt sind?

jones79 schrieb:

Hm, ungefähr so sie das Skript bei mir auch aus, allerdings mit dem Unterschied, dass ich meine Variablen nicht mittels Anfürungszeichen oder geschwungenen Klammern anspreche sondern nur mit Dollarzeichen davor. Das könnte das Problem sein.

Genau das ist das Problem. 😉

Kannst du mir kurz erklären, warum du das macht und warum nicht alle Variablen in Anführungszeichen verpackt sind?

Nachdem ich etliche alle Artikel zu dem Thema im Netz gelesen habe, und eben so viele Versuche gemacht habe wollte ich mein Script noch mal komplett neu "ansetzen". Dazu öffnete ich es zum bearbeiten mit Kwrite und nicht mit joe, wie sonst. Markieren, kopieren, drag and drop ist manchmal auch nicht schlecht.

Habe nun testweise meinen rsync Befehl mal ohne Variablen in das script geschrieben. Das Syntax highlighting von Kwrite erleuchtete mich dann, zumal das script so lief. Rsync will die Pfad bzw. Dateiangeben bei den Optionen (zb. --exclude-from=) MIT den Gänsefüßchen. Ebenso den KOMPLETTEN SSH Eintrag. Die werden aber beim Auflösen der Variablen nicht "mitgeliefert", also muss man die explizit wieder angeben (z.B. "${RMSYNCPATH}"). Die geschweiften Klammern sind notwendig, damit der Variableninhalt nicht von der bash aufgebröselt wird, wenn ich das richtig verstanden habe.

Gruß compiopa

PS: Für die Mitleser, jones79 schilderte sein Problem dort: http://forum.ubuntuusers.de/topic/ssh-und-rsync-funktioniert-manuell-nicht-als-s/

Hm also so ganz versteh ich das noch nicht und ich weiß auch nicht ob es richtig ist, was du geschrieben hast. Zumal rsync bei mir überhaupt keine Gänsefüßchen in dem aus Variablen zusammengesetzten Befehl hat und funktioniert.

Auch ein Minimalbeispiel um das ganze Elend mal zu testen zeigt keine Gänsefüßchen

1
2
3
4
5
6
7
8
9

#!/bin/bash
HOST="username@hostname"
SOURCEDIR="/"
TARGETDIR="/Backup/"
SSHDIR=$HOST":""$TARGETDIR"
echo 'echo $SSHDIR: ' $SSHDIR
echo 'echo ${SSHDIR}: ' ${SSHDIR}
echo 'echo "${SSHDIR}": ' "${SSHDIR}"
echo 'echo "$SSHDIR": ' "$SSHDIR"

Output überall :

1

username@hostname:/Backup/

Will man die Gänsefüßen wirklich anzeigen so muss man einen Befehl zwischen einfache Anführungszeichen 'also hierhin' setzen. Sollen Sie zwischen doppelten Anführungszeichen angezeigt werden, dann muss man sie "escapen" mittels backslash. Beispiel:

1
2
3
4
5
6

#!/bin/bash
HOST="username@hostname"
SOURCEDIR="/"
TARGETDIR="/Backup/"
SSHDIR=$HOST":""$TARGETDIR"
echo "echo \"$SSHDIR\":" \"$SSHDIR\"

Output:

1

"username@hostname:/Backup/"

jones79 schrieb:

Hm also so ganz versteh ich das noch nicht und ich weiß auch nicht ob es richtig ist,

Ich auch nicht. 😉

Die Frage ist, ob dir echo das anzeigt, was die bash und rsync interpretieren.

Gruß compiopa

hm mal ein andrer Ansatz ?!

Wieso betreibst du eigentlich rsync über ssh ?? Wenn ich das richtig "überflogen" hab dann reicht für dein Szenario ein sync daemon vollkommen aus da brauchst du kein sudo, keine public key's, ja nicht ein mal einen separaten System User, das einzige was man da braucht ist etwas Hirnschmalz ☺ und das spart auch noch Rechenleistung weil da nicht's verschlüsselt werden muss 🤓 außer du hast vor hoch-geheime Dokumente aus dem Pentagon zu Sichern 🐸

kosh30 schrieb:

Wenn ich das richtig "überflogen" hab dann reicht für dein Szenario ein sync daemon vollkommen aus da brauchst du kein sudo...

Welche meiner Äußerungen hat Dich zu dieser Annahme verleitet? Soll ich die Daten unverschlüsselt uber das Internet jagen? 😕

Gruß compiopa

Welche meiner Äußerungen hat Dich zu dieser Annahme verleitet? Soll ich die Daten unverschlüsselt uber das Internet jagen?

Na ja, in den meisten fällen platziert man den Backup Server nicht unbedingt irgend wo am Arsch der Welt, sondern in der nähe des zu Sichernden Servers und hängt beide in einem lokalen netzt zusammen. Damit sparrt man bei Traffic kosten und das Backup funzt auch dann wen die Internet Verbindung gerade nicht so richtig mag. Ausnahmen sind Disaster Szenarios, aber da würde ich eher die Leitung mittels vpn&co sichern.

Aber natürlich kann ich da auch falsch liegen arbeite ja erst seit 15 Jahren als sysadmin 😮

Hallo kosh30,

meiner Meinung nach macht gerade die räumliche Trennung, also in unterschiedlichen Gebäuden, der beiden Server Sinn. Brennt das Haus mit dem Server ab, hat man noch den Backup Server, oder umgekehrt. Wenn ich die nur in getrennten Räumen stehen habe, kann das blöd ausgehen. In Ermangelung einer Standleitung oder sonstiger Verkabelung bleibt ja nur das Internet als Übertragungsweg.

OK, VPN ist auch eine Möglichkeit, allerdings schwieriger zu konfigurieren als SSH, find ich jedenfalls. Jede Methode hat sicher ihre Vor- und Nachteile. Wie SSH und VPN sicherheitstechnisch zueinanderstehen kann ich nicht beurteilen, da fehlt mir noch einiges an Wissen.

Über die daemon Variante von rsync habe ich in der man page auch schon gelesen. Leider bin ich aus der Erklärung nicht so richtig schlau geworden und auch im web habe ich nicht wirklich was erhellendes gefunden. Also wenn Du da einen guten Link kennst (lieber in D als in E, geht aber auch) nur her damit, ich lerne ja gerne was dazu. 😊

Gruß compiopa

meiner Meinung nach macht gerade die räumliche Trennung, also in unterschiedlichen Gebäuden, der beiden Server Sinn.

klar ist eine feine Sache. War in deinem Beitrag allerdings nicht raus zu lesen das es sich um ein disaster Backup handeln soll.

OK, VPN ist auch eine Möglichkeit, allerdings schwieriger zu konfigurieren als SSH, find ich jedenfalls.

wie war dein leitspruch noch ein mal 👍 ? Dank Openvpn ist das recht einfach geworden, ist zwar nicht so schnell wie ipsec aber todl einfach. Aber natürlich wenn man kein vpn nutzen kann/will muss man auf ssh ausweichen.

Über die daemon Variante von rsync habe ich in der man page auch schon gelesen.

 man rsyncd.conf 

sollte da weit hilfreicher sein ❗

lieber in D als in E

ist bei solchen Sachen ganz falscher ansatz 🙄

kosh30 schrieb:

 man rsyncd.conf 

sollte da weit hilfreicher sein ❗

Oh, das hab ich ganz übersehen.

lieber in D als in E

ist bei solchen Sachen ganz falscher ansatz 🙄

Na ja, falsch würde ich jetzt nicht unbedingt sagen, da steht ja "lieber". Um erst mal schnell einen groben Überblick zu bekommen, was, wie, warum usw. tu' ich mir eben in D leichter. Wenn es dann an's Eingemachte geht, latürnich auch E. 😊

Werde mir das mal in einer ruhigen Stunde zu Gemüte führen.

Gruß compiopa