Probleme mit Duplicity

Hallo,
ich habe auf meinem QNAP TS 459 nun Duplicity installiert, weil die Möglichkeiten (verschlüsselte Backups) des Tools einfach super sind. ABER ich bin vielleicht doch nicht Linux-kompatibel

Ich habe einen Testjob gestartet, der knappe 3,5GB per FTP gesichert hat ohne Beanstandung. Dann wollte ich einen Restore testen und da kam die Meldung, dass kein Speicher mehr im TMP-Verzeichnis ist (No more space on device). Das Verzeichnis, welches ich als tempdir definiert habe, war aber nicht voll. Auch per df war das Standard /tmp/ zu 98% frei. Verwundert hat mich hingegen das Root 100% voll war. Verstehen werde ich das sicher nicht mehr, warum ROOT nur 128MB hat. Nach einem klassischen Reboot war das System wieder auf 85% und jetzt läuft gar kein Job mehr ohne einen Fehler im Log: Specified archive directory /root/.cache/duplicity/..... does not exist, or is not a directory.

Nun was soll ich sagen...nicht mehr, denn meine Recherche im Internet hat mich mal allein gelassen...

Warum Duplicity...weil die Oberfläche vom QNAP nichts vergleichbares bietet.

Hallo,
rsnap sichert doch nur auf NFS und nicht per FTP oder doch? Zudem ist das abgelegte Backup ja nicht verschlüsselt oder?

Meine zwei Hauptprobleme sind sozusagen NUR Zugang per FTP und NUR eingeschränktes Vertrauen gegenüber dem Backup-"Lagerort".

Die wirklichen Auswirkungen dessen, was Du da schreibst sind mir noch nicht ganz klar, weil für mich nicht nachvollziehbar ist, was alles in dem Root liegt. Kurz gesagt, wann wurde das Verzeichnis /root/.cache/duplicity angelegt. In meiner Anleitung, die ich gefunden hatte, war davon nicht die Rede oder ich habe es nicht verstanden.

Hier die Anleitung...mit leichter Abwandlung für das TS 459: http://wiki.qnap.com/wiki/How_…all_Duplicity_On_QNAP_NAS

Also ein paar Versuche weiter bemerke ich, dass fast jeder Befehl in der autorun.sh nicht läuft

cp /share/MD0_DATA/_scb/.profile /root/.profile

Fehler: cannot stat ... No such file or directory

cp -r  /share/MD0_DATA/_scb/.gnupg /root/

Fehler: ..irgendwas kann er nicht schreiben/lesen
Damit geht aber...wer hätte es gedacht...die Verschlüsselung nicht...also habe ich meine Schlüssel manuell neu importiert und getrusted...und schon ist der gpg Fehler weg

ln -sf /share/MD0_DATA/_scb/cacheduplicity /root/.cache

Der geht eigentlich, wird aber scheinbar dennoch nicht ausgeführt, denn wenn ich den Befehl nicht manuell anschiebe, bekomme ich meinen alten Fehler.

Den ersten Befehl bekomme ich nicht ans Laufen und die anderen aber irgendwie auch nur manuell...obwohl ich jetzt besser verstehe, was die Befehle machen.

Nun habe ich eine Erklärung für alle Fehler...an der Lösung arbeite ich noch.

Das die .profile nicht gefunden wird...ist völlig okay...denn die verwende ich nicht und ist auch optional.

Und alle anderen Fehler haben eine gemeinsame Ursache...der Autorun-Skript läuft einfach nicht und das war es schon. Ich kann mir auch vorstellen, dass das Skript zu früh läuft und deswegen nicht die gewünschte Wirkung erzielt.

autorun.sh

#!/bin/sh
cp -r /share/MD0_DATA/_scb/.qnupg /root/
ln -sf /share/MD0_DATA/_scb/cacheduplicity /root/.cache

Der Skript läuft und tut das richtige.

Vielleicht hat jemand einen Tipp?!

Es ist toll...ich habe dank einem Beitrag im Qnap Wiki http://wiki.qnap.com/wiki/Add_items_to_crontab nun auch die Crontab unter Kontrolle. Es lag wohl an der Art, wie ich die Einträge abgespeichert habe.

Wobei jetzt ein interessanter Effekt auftritt, den ich wieder einmal nicht erklären kann.
Starte ich das Duplicity Skript direkt, dann läuft es problemlos im Hintergrund durch. Wird es per Cron gestartet, nimmt es den falschen Schlüssel (obwohl fest codiert). Normal wäre der XYZ (für den auch beide Schlüsselpaare vorliegen). Verwendet wird aber ein SUB schlüssel 123, obwohl die richtige ID im Skript verwendet wird...wie kommt das zustande? Und wie kann ich das ändern?

Edit: Nach einiger Recherche habe ich zwar unzählige Beiträge gefunden, wonach ein per cron gestartetes Skript keine Umgebungsvariablen (oder so ähnlich) hat, aber der Fehler entsteht innerhalb von duplicity und gpgme, worauf ich ja nur bedingt Einfluss habe.

Woran kann es denn noch liegen? Oder wie kann ich den Skript beeinflussen, dass es doch geht?

Danke

Hat denn keiner eine Idee?

Ich habe auch mal probiert, das gpg erst mit dem Cron eingerichtet wird, also garantiert unter dem Context des Cron, brachte aber nicht viel. Denn jetzt wird zwar der richtige Schlüssel angezeigt, aber "No public Key" ausgegeben.

Hilflos...