Duplicity und Cronjob

[Strpfl]

Hallo Zusammen,

ich habe hier in ein komisches Problem und bin mit meinem Latein langsam am Ende.
Ich habe ein Script, welches duplicity aufruft (zuvor werden noch die notwendigen Umgebungsvariabeln gesetzt). Damit werden die Daten auf einen Amazon S3 Account gepusht.
Das Ganze läuft als Cronjob (/etc/crontab) einmal täglich.

Nun ist es so, dass das Script per Cronjob sauber ausgelöst wird und auch durchläuft. Nur macht Duplicity genau beim ersten Mal seine Aufgabe, ab dem zweiten Mal beendet es ohne Durchführung des Backups oder Ausgabe eines Fehlers.
Wenn ich das Script hingegen selber auf dem Terminal starte (auch mehrfach), funktioniert es jedes Mal und das Backup wird schön brav wie gedacht durchgeführt.

Die Sache ist also nicht die, dass das Script nicht ausgeführt wird, sondern duplicity ab dem 2. Mal irgendein Problem hat.

Das Script

export AWS_ACCESS_KEY_ID=XXX
export AWS_SECRET_ACCESS_KEY=YYY
export PASSPHRASE=ZZZ

BUCKET=s3+http://com.path.bucket/backup
FILES=/root/backup/files
LOGFILE=/root/backup/duplicity.log

backup() {

TIME=$(date +"%m.%d.%Y %T")

echo "$TIME | BACKUP Start" >> $LOGFILE

duplicity --full-if-older-than 28D --s3-use-new-style --s3-european-buckets --archive-dir /volume1/Backup_Archive/amazon_backup --tempdir /volume1/Backup_Archive/tmp --verbosity 4 --asynchronous-upload --include-filelist $FILES 
/volume1 $BUCKET >> $LOGFILE

TIME=$(date +"%m.%d.%Y %T")

echo "$TIME | BACKUP End" >> $LOGFILE
}

export AWS_ACCESS_KEY_ID=
export AWS_SECRET_ACCESS_KEY=
export PASSPHRASE=

Das Script stammt ursprünglich von hier: http://thomassileo.com/blog/2012/07...remental-backups-with-duplicity-on-amazon-s3/
Ich habe es nur noch angepasst.

Die Ausgabe

1. Mal:
05.21.2013 12:00:00 | BACKUP Start
[Ausgabe von Duplicity]
05.21.2013 12:20:58 | BACKUP End

2. und weitere Male:
05.22.2013 12:00:00 | BACKUP Start
05.22.2013 12:00:01 | BACKUP End

Hat jemand eine Idee, woran das liegen könnte? Gibt es hier ein Rechteproblem, oder sonst irgendeinen Grund das duplicity nicht ausgeführt wird.
Vielen Dank schon mal für jedwede Hilfe

 

[jahlives]

Grundsätzlich sollte man in Scripten welche von cron abgearbeitet werden immer vollständige Pfadangaben zu den Kommandos machen v.a. beim duplicity Kommando
Dann würde ich mal noch beim Kommando selber nicht nur die Ausgabe ins Logfile umleiten sondern auch die Fehler

.... >> $LOGILFE 2>&1

 

[Strpfl]

Grundsätzlich sollte man in Scripten welche von cron abgearbeitet werden immer vollständige Pfadangaben zu den Kommandos machen v.a. beim duplicity Kommando

Habe das so angepasst, hätt ich ja auch selber sehen können.

Dann würde ich mal noch beim Kommando selber nicht nur die Ausgabe ins Logfile umleiten sondern auch die Fehler

Auch das hätte ich doch einfach mal sehen und machen können.
Danke für die beiden Inputs.

Ich habe jetzt den Cron auf alle 2 Minuten gesetzt und Duplicity wurde immer ausgeführt. Vielleicht lags echt nur am Pfad (was dann die Frage aufwirft, wieso es beim ersten Mal ging... naja).
Ich werde noch eine Testreihe im normalen Intervall durchlaufen lassen, da das NAS auch jeden Morgen neu gestartet wird.

 

[itari]

bei den $-Variablen (z.B. $FILES) sollte man immer genau prüfen, ob irgendwelche Pfad-/Dateinamen mit Leerstellen vorkommen könnten (diese werden dann meist als 2 Dateinamen interpretiert und dabei fällt das Skript auf die Nase) ... eine Möglichkeit wäre dann, die $Variable zu quotieren (z. B. "$FILES") ... passt nicht immer, aber oft 99,9% ... deswegen auch immer der Tipp, sich das ins Logfile zu schreiben und dann zu kontrollieren

Itari

 

[Strpfl]

Danke an Itari und jahlives für eure Antworten.

Dank dem Hinweis von jahlives kann ich jetzt immerhin eine Fehlermeldung liefern:

Cleanup of temporary directory /volume1/Backup_Archive/tmp/duplicity-1ktbZN-tempdir failed - this is probably a bug.
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
Traceback (most recent call last):
File "/opt/bin/duplicity", line 1311, in <module>
with_tempdir(main)
File "/opt/bin/duplicity", line 1304, in with_tempdir
fn()
File "/opt/bin/duplicity", line 1285, in main
check_last_manifest(col_stats) # not needed for full backup
File "/opt/bin/duplicity", line 1017, in check_last_manifest
last_backup_set.check_manifests()
File "/opt/lib/python2.6/site-packages/duplicity/collections.py", line 185, in check_manifests
remote_manifest = self.get_remote_manifest()
File "/opt/lib/python2.6/site-packages/duplicity/collections.py", line 219, in get_remote_manifest
manifest_buffer = self.backend.get_data(self.remote_manifest_name)
File "/opt/lib/python2.6/site-packages/duplicity/backend.py", line 538, in get_data
fin = self.get_fileobj_read(filename, parseresults)
File "/opt/lib/python2.6/site-packages/duplicity/backend.py", line 501, in get_fileobj_read
return tdp.filtered_open_with_delete("rb")
File "/opt/lib/python2.6/site-packages/duplicity/dup_temp.py", line 114, in filtered_open_with_delete
fh = FileobjHooked(path.DupPath.filtered_open(self, mode))
File "/opt/lib/python2.6/site-packages/duplicity/path.py", line 741, in filtered_open
return gpg.GPGFile(False, self, gpg_profile)
File "/opt/lib/python2.6/site-packages/duplicity/gpg.py", line 152, in __init__
'logger': self.logger_fp})
File "/opt/lib/python2.6/site-packages/duplicity/GnuPGInterface.py", line 357, in run
create_fhs, attach_fhs)
File "/opt/lib/python2.6/site-packages/duplicity/GnuPGInterface.py", line 401, in _attach_fork_exec
if process.pid == 0: self._as_child(process, gnupg_commands, args)
File "/opt/lib/python2.6/site-packages/duplicity/GnuPGInterface.py", line 442, in _as_child
os.execvp( command[0], command )
File "/opt/lib/python2.6/os.py", line 344, in execvp
_execvpe(file, args)
File "/opt/lib/python2.6/os.py", line 380, in _execvpe
func(fullname, *argrest)
OSError: [Errno 2] No such file or directory

===== End GnuPG log =====

Noch ein bisschen Kontext:
Wenn ich das Skript direkt ausführe, habe ich nie diese Fehlermeldung.

Das NAS wird jedoch jeden morgen um 6 neu gestartet und führt, wie gesagt, das Skript mit Cron aus.
Kann es sein, dass die Umgebung des root-Nutzers nicht richtig aufgebaut wird oder entsprechende Rechte fehlen und daher GPG nicht korrekt initialisiert ist?

Danke für eure Hilfe.

 

[bubbas]

Auch ich hatte das selbe Problem. Wenn man das Skript von Hand auf der Konsole ausführt funktioniert es, wenn man es dagegen über cron laufen lässt nicht. Nach einer ganzen Nacht rumprobieren, habe ich jetzt für mich eine Lösung gefunden:
Ich logge mich einfach mit einem Skript per ssh von der diskstation auf die diskstation ein, und führe das Skript aus, somit läuft das Skript wie als ob ich mich selber einloggen würde ...

Dazu muss man den login mit preshared key per ssh aktivieren:
- Einloggen als root auf der Diskstation
- Erstellen eines rsa Keys und diesen dann in die authorized keys datei kopieren, somit kann sich die diskstation per ssh ohne key auf sich selber einloggen ;-)

ssh-keygen -t rsa
umask 077; cat ~/.ssh/*.pub |  cat >>~/.ssh/authorized_keys

Ein neues Skript erstellen (run.sh), dass per ssh sich einloggt ein Terminal öffnet, den gewünschten Befehl in der /opt/bin/bash ausführt und das Terminal dann wieder schließt:

#!/opt/bin/bash
ssh -o PreferredAuthentications=publickey root@diskstation << EOT
/opt/bin/bash /path/duplicity-backup.sh -c /path/duplicity-backup.conf --backup > /path/duplicity.log 2>&1
EOT

Skript ausführbar machen:

chmod +x /path/run.sh

Diese Skript kann dann sogar über den Synology Aufgabendienst ausgeführt werden. Im Webinterface unter Aufgabenplanung, Benutzerdefiniertes Skript, Zeit anpassen und den Befehl eingeben:

/path/run.sh

Ach ja als duplicity-backup Skript fand ich folgendes sehr schön gemacht und benutze ich erfolgreich:
https://github.com/zertrin/duplicity-backup