Problem mit Duplicity/FTPlicity
- Thread starter MacGyver
- Start date
Huschi
Moderator
Was mich stört ist, daß es genau an der Stelle 'STOR remote_filename, source_file' zum Fehler kommt. Es muß also was sein, was entweder auf dem FTP-Server zum Fehler führt oder auf Deinem Rechner.
Auf Deinem Rechner müßte dann das source_file falsch sein.
Auf dem FTP-Server ist es vielleicht der remote_filename, Benutzerrechte, Dateigröße oder zuviele Connection.
Leider liefert das Script an der Stelle keine vernünftige Fehlermeldung. Von daher kann man nur noch raten, raten, raten...
huschi.
Auf Deinem Rechner müßte dann das source_file falsch sein.
Auf dem FTP-Server ist es vielleicht der remote_filename, Benutzerrechte, Dateigröße oder zuviele Connection.
Leider liefert das Script an der Stelle keine vernünftige Fehlermeldung. Von daher kann man nur noch raten, raten, raten...
huschi.
ovizii
New Member
Vielleicht können wir ja durch Ausschließen auf einen grünen Zweig kommen:
Remote: Benutzerrechte passen, hab ich überprüft, Dateigröße ist irelevant, denn ftplicity macht die Backups ja in 5MB großeb Happen wenn ich mich nicht irre, zu viele Connections kann ich mir nicht vorstellen, denn es wird ja sequentiell übertragen und nicht parallel, oder? Bleibt also noch der remote Filename, aber wie gesagt, das Backup lief ja monatelang mit eben dieser Konfiguration... daher tippe ich eher auf was anderes.
Source: was genau kann am Sourcefile falsch sein? Was soll ich denn überprüfen?
Wäre für jeden Vorschlag offen, da ich momentan nicht weiß ob meine Backups funktionieren..
Remote: Benutzerrechte passen, hab ich überprüft, Dateigröße ist irelevant, denn ftplicity macht die Backups ja in 5MB großeb Happen wenn ich mich nicht irre, zu viele Connections kann ich mir nicht vorstellen, denn es wird ja sequentiell übertragen und nicht parallel, oder? Bleibt also noch der remote Filename, aber wie gesagt, das Backup lief ja monatelang mit eben dieser Konfiguration... daher tippe ich eher auf was anderes.
Source: was genau kann am Sourcefile falsch sein? Was soll ich denn überprüfen?
Wäre für jeden Vorschlag offen, da ich momentan nicht weiß ob meine Backups funktionieren..
ovizii
New Member
@ huschi
Ich bin einen GROßEN Schritt weiter:
Habe im conf file vonm ftplicity den Zielpfad von ftpserver/backup/ auf ftpserver/ geändert und hatte die gleichen Fehlermeldungen, also kann ich Probleme auf dem Zielmedium (fast) ausschließen.
Daraufhin habe ich den Sourcepfad von "/" auf "/etc" geändert zum Testen und siehe da, das Backup lief ohne Probleme durch.
===>>> meine Schlußfolgerung: ich habe Probleme mit dem, was ich versuche zu backupen.
Hier der Inhalt meiner exclude Datei:
/dev
/proc
/sys
/tmp
/var/lib/apache2
/var/lib/dcc
/var/lib/mysql
/var/lib/named/dev
/var/run
/var/spool
/var/tmp
Vielleicht kann mir jemand der mit Debian bewandert ist helfen alles Unnötige / Problematische auszuschließen. Was müßte / könnte denn noch auf die Ausschlußliste?
Ich bin einen GROßEN Schritt weiter:
Habe im conf file vonm ftplicity den Zielpfad von ftpserver/backup/ auf ftpserver/ geändert und hatte die gleichen Fehlermeldungen, also kann ich Probleme auf dem Zielmedium (fast) ausschließen.
Daraufhin habe ich den Sourcepfad von "/" auf "/etc" geändert zum Testen und siehe da, das Backup lief ohne Probleme durch.
===>>> meine Schlußfolgerung: ich habe Probleme mit dem, was ich versuche zu backupen.
Hier der Inhalt meiner exclude Datei:
/dev
/proc
/sys
/tmp
/var/lib/apache2
/var/lib/dcc
/var/lib/mysql
/var/lib/named/dev
/var/run
/var/spool
/var/tmp
Vielleicht kann mir jemand der mit Debian bewandert ist helfen alles Unnötige / Problematische auszuschließen. Was müßte / könnte denn noch auf die Ausschlußliste?
Huschi
Moderator
Das ist interessant. Mmmh, aber was sagt uns das jetzt wirklich?
Was mir spontan noch einfällt, sind folgende Verzeichnisse:
/var/log (oder zumindest nicht die rotierten/gepackten Files)
/lost+found
Außerdem bin ich ein Verfechter der "Blos nicht das etc-Verzeichnis backupen und wiederherstellen!"-Fraktion. Denn dann spielt man sich häufig den Fehler wieder ein, der den Server zum Absturz brachte.
Aber eigentlich könntest Du jedes Verzeichnis unter / einzeln Backupen um zu sehen, bei welchem die Probleme auftreten.
huschi.
Was mir spontan noch einfällt, sind folgende Verzeichnisse:
/var/log (oder zumindest nicht die rotierten/gepackten Files)
/lost+found
Außerdem bin ich ein Verfechter der "Blos nicht das etc-Verzeichnis backupen und wiederherstellen!"-Fraktion. Denn dann spielt man sich häufig den Fehler wieder ein, der den Server zum Absturz brachte.
Aber eigentlich könntest Du jedes Verzeichnis unter / einzeln Backupen um zu sehen, bei welchem die Probleme auftreten.
huschi.
ovizii
New Member
hmmm....
Da wird mir wohl nichts andere übrigbleiben als alle einzeln durchzugehen (sichern) und festzustellen, welches Probleme macht... das wird aber ne Heidenarbeit, weil ich die exclude Datei jedesmal wegkopieren muss, weil das Ganze nämlich nicht funktioniert, wenn ich die exclude Datei die zu Sourcepfad / passt mit Sourcepfad /var versuche laufen zu lassen, aber na ja.
Also ich melde mich dann hier mit mehr Details sobald ich das alles gemacht habe aber zuvor hätte ich noch eine Frage bzw. Feststellung:
Normalerweise sieht ein Backupvorgang, bei dem etwas nicht gelesen werden kann so aus:
Sprich ftplicity meldet brav wenn etwas nicht gelesen werden konnte !?
Da wird mir wohl nichts andere übrigbleiben als alle einzeln durchzugehen (sichern) und festzustellen, welches Probleme macht... das wird aber ne Heidenarbeit, weil ich die exclude Datei jedesmal wegkopieren muss, weil das Ganze nämlich nicht funktioniert, wenn ich die exclude Datei die zu Sourcepfad / passt mit Sourcepfad /var versuche laufen zu lassen, aber na ja.
Also ich melde mich dann hier mit mehr Details sobald ich das alles gemacht habe aber zuvor hätte ich noch eine Frage bzw. Feststellung:
Normalerweise sieht ein Backupvorgang, bei dem etwas nicht gelesen werden kann so aus:
Sprich ftplicity meldet brav wenn etwas nicht gelesen werden konnte !?
ovizii
New Member
Ok, ich habe das Ganze etwas mehr eingegrenzt:
Backups von allen Verzeichnissen im Root klappen einzeln, nur bei /var gibt es probleme. Momentan habe ich folgendes im /var:
meien momentane exclude Datei sieht so aus:
mit besonderem Augenmerk auf den rot gekennzeichneten Einträgen.
Gibt es in /var sonst noch Verzeichnisse, die ich ausnehmen sollte? Ansosnten müßte ich wieder per Ausschlußverfahren einzeln durchtesten wo das Problem liegt.
Backups von allen Verzeichnissen im Root klappen einzeln, nur bei /var gibt es probleme. Momentan habe ich folgendes im /var:
meien momentane exclude Datei sieht so aus:
mit besonderem Augenmerk auf den rot gekennzeichneten Einträgen.
Gibt es in /var sonst noch Verzeichnisse, die ich ausnehmen sollte? Ansosnten müßte ich wieder per Ausschlußverfahren einzeln durchtesten wo das Problem liegt.
ovizii
New Member
Ahhhh *Graus* 
Ich hab das Problem eingegrenzt - es liegt eindeutig im /var/www Ordner und da liegen ca. 20-30 Ordner... Das kann ich unmöglich manuell ausprobieren, kennst du vielleicht ne Möglichkeit da etwas mitzutracen oder eine Logdatei zu schreiben? Die duplicity Doku schweigt dazu :-(
###edit###
habe gerade etwas megapeinliches herausgefunden, Einstellung von ftplicity:
wenn das jetzt sofort was brauchbares liefert, werd ich folgenden Eintrag in meiner Signatur machen: "Dämlichster User dieses Forums" - das hab ich dann nämlich verdient ! Also erstmal abwarten was ei nDurchlauf mit VERBOSITY=9 bringt.
Ich hab das Problem eingegrenzt - es liegt eindeutig im /var/www Ordner und da liegen ca. 20-30 Ordner... Das kann ich unmöglich manuell ausprobieren, kennst du vielleicht ne Möglichkeit da etwas mitzutracen oder eine Logdatei zu schreiben? Die duplicity Doku schweigt dazu :-(
###edit###
habe gerade etwas megapeinliches herausgefunden, Einstellung von ftplicity:
wenn das jetzt sofort was brauchbares liefert, werd ich folgenden Eintrag in meiner Signatur machen: "Dämlichster User dieses Forums" - das hab ich dann nämlich verdient ! Also erstmal abwarten was ei nDurchlauf mit VERBOSITY=9 bringt.
Last edited by a moderator:
ovizii
New Member
Muss ich denn das jetzt verstehen?
Kannst du damit irgendetwas anfangen? Wenigstens eine halbwegs qualifizierte Vermutung anstellen?
P.S. da ist in der Tat nichts was mit dem Backup zu tun hat auf dem FTp Server, ich hab ihn nämlich in das Root backupen laßen statt in das normale Verzeichniß, deswegen findet er nichts relevantes, das ist ok soweit.
Kannst du damit irgendetwas anfangen? Wenigstens eine halbwegs qualifizierte Vermutung anstellen?
P.S. da ist in der Tat nichts was mit dem Backup zu tun hat auf dem FTp Server, ich hab ihn nämlich in das Root backupen laßen statt in das normale Verzeichniß, deswegen findet er nichts relevantes, das ist ok soweit.
Cheef-Daniel
New Member
Hallo, ich hoffe es ist noch nicht zu spät.
Ich hatte Anfangs auch die gleichen Schwierigkeiten mit ftplicity, besser gesagt ist duplicity schuld, bis ich die Fehlerursache gefunden habe. Das Problem mit dem broken Pipe was bei mir nur gelegentlich bis regelmäßig auftrat lag vermutlich daran dass die Verbindung zwischen meinem FTP-Server und duplicity aus irgendeinem Grund während des Backups getrennt wurde oder zusammenbrach, oft auch immer an der selben stelle. (Timeout?)
Duplicity versucht beim Auftreten dieses Fehlers allerdings keine Neuverbindung zum Backup-Server sondern zeigt diesen Broken-Pipe Fehler und bleibt deswegen auch bei dem STOR Befehl stehen.
Im Internet bin ich auf einen Patch für Version 0.4.1 gestoßen welcher zwar für dieses Problem gedacht war, bei mir so allerdings nicht in Version 0.4.2 funktionierte.
Deswegen habe ich die zugehörigen duplicity Python-Scripte mithilfe des Patches soweit modifiziert bis dieser Fehler weg war. Alles was zu tun war, war dafür zu sorgen das ftplicity bzw. duplicity bei jedem Verbindungsverlust mindestens einen Reconnect versucht. Ich bin jetzt nicht der Python-Experte deswegen könnten eventuell noch Fehler darin sein, allerdings läuft ftplicity/duplicity nun seit Anfang Februar bei mir wieder ohne Probleme.
Wenn noch Interesse besteht kann ich versuchen ein neues Patchfile zu erstellen.
Edit:
Der Original-Patch (duplicity-0.4.1-timeout.patch) stammte von hier
Damit dieser bei mir für Version 0.4.2 funktioniert habe ich ihn angepasst. Er behebt den broken-pipe Error bei Nutzung des FTP-Protokolls indem bei Verbindungsverlust 3 mal versucht wird die Verbindung wiederherzustellen: (Vielleicht kann sich ein Python-Programmierer das nochmal anschauen weil ich selbst bisher noch nie mit Python programmiert habe und nicht weiss ob das alles so richtig ist, also bitte noch aufpassen wenn ihr das benutzen wollt)
Ich hatte Anfangs auch die gleichen Schwierigkeiten mit ftplicity, besser gesagt ist duplicity schuld, bis ich die Fehlerursache gefunden habe. Das Problem mit dem broken Pipe was bei mir nur gelegentlich bis regelmäßig auftrat lag vermutlich daran dass die Verbindung zwischen meinem FTP-Server und duplicity aus irgendeinem Grund während des Backups getrennt wurde oder zusammenbrach, oft auch immer an der selben stelle. (Timeout?)
Duplicity versucht beim Auftreten dieses Fehlers allerdings keine Neuverbindung zum Backup-Server sondern zeigt diesen Broken-Pipe Fehler und bleibt deswegen auch bei dem STOR Befehl stehen.
Im Internet bin ich auf einen Patch für Version 0.4.1 gestoßen welcher zwar für dieses Problem gedacht war, bei mir so allerdings nicht in Version 0.4.2 funktionierte.
Deswegen habe ich die zugehörigen duplicity Python-Scripte mithilfe des Patches soweit modifiziert bis dieser Fehler weg war. Alles was zu tun war, war dafür zu sorgen das ftplicity bzw. duplicity bei jedem Verbindungsverlust mindestens einen Reconnect versucht. Ich bin jetzt nicht der Python-Experte deswegen könnten eventuell noch Fehler darin sein, allerdings läuft ftplicity/duplicity nun seit Anfang Februar bei mir wieder ohne Probleme.
Wenn noch Interesse besteht kann ich versuchen ein neues Patchfile zu erstellen.
Edit:
Der Original-Patch (duplicity-0.4.1-timeout.patch) stammte von hier
Damit dieser bei mir für Version 0.4.2 funktioniert habe ich ihn angepasst. Er behebt den broken-pipe Error bei Nutzung des FTP-Protokolls indem bei Verbindungsverlust 3 mal versucht wird die Verbindung wiederherzustellen: (Vielleicht kann sich ein Python-Programmierer das nochmal anschauen weil ich selbst bisher noch nie mit Python programmiert habe und nicht weiss ob das alles so richtig ist, also bitte noch aufpassen wenn ihr das benutzen wollt)
Code:
--- duplicity-0.4.2/src/backends.py 2006-02-03 04:44:31.000000000 +0100
+++ duplicity-0.4.2/src/backends.py.timeout2 2007-04-02 02:39:00.000000000 +0200
@@ -20,6 +20,7 @@
import os, types, ftplib, tempfile
import log, path, dup_temp, file_naming
+import time
class BackendException(Exception): pass
class ParsingException(Exception): pass
@@ -318,8 +319,11 @@
class ftpBackend(Backend):
"""Connect to remote store using File Transfer Protocol"""
+ SLEEP = 10 # time in seconds before we try to reconnect on temporary errors
+ RETRIES = 3 # max count of retries in case of error
def __init__(self, parsed_url):
"""Create a new ftp backend object, log in to host"""
+ self.parsed_url = parsed_url
self.ftp = ftplib.FTP()
if parsed_url.port is None: self.error_wrap('connect', parsed_url.host)
else: self.error_wrap('connect', parsed_url.host, parsed_url.port)
@@ -332,7 +336,20 @@
def error_wrap(self, command, *args):
"""Run self.ftp.command(*args), but raise BackendException on error"""
try: return ftplib.FTP.__dict__[command](self.ftp, *args)
- except ftplib.all_errors, e: raise BackendException(e)
+ except ftplib.all_errors, e:
+ #ftplib.error_temp, e:
+ self.RETRIES = self.RETRIES-1
+ if self.RETRIES > 0:
+ log.Log("Temporary error '%s'. Trying to reconnect in %d seconds." %
+ (str(e), self.SLEEP), 3)
+ time.sleep(self.SLEEP)
+ self.__init__(self.parsed_url)
+ self.error_wrap(command, *args)
+ self.RETRIES = 3
+ else:
+ self.RETRIES = 3
+ raise BackendException(e)
+ #except ftplib.all_errors, e: raise BackendException(e)
Last edited by a moderator:
Cheef-Daniel
New Member
Ach ja, schön wärs gewesen...
Seit ein paar Tagen habe ich den gleichen Fehler wie ovizii wieder.
ftplicity+duplicity wäre genial wenn der Fehler nicht wäre, was kann man da nur machen?
Was mir dabei aufgefallen ist: Ich habe versucht mehrmals "ftplicity backup" aufzurufen, jedesmal tritt der Fehler an exakt der selben stelle auf. Am nächten Tag lief es dann wieder ohne Probleme durch. Wieder ein paar Tage später fing dass Spiel von vorne an, allerdings blieb er dann woanders stehen (das muss dann bei /var/mail/userp10 gewesen sein). Auch hier war es wieder so das bei jedem erneuten starten der Fehler an der gleichen stelle auftauchte und ein Tag später ging es wieder. Nur jetzt versuche ich es schon 3 Tage erfolglos, so langsam sollte das mit den Backups wieder laufen bevor Murphy vorbeischaut.
Ich kann mich nach/vor jedem Auftreten des Fehlers ohne Probleme an meinen Backupserver per ftp anmelden, Verbindungsprobleme schließe ich daher fast aus, Speichermangel auf /tmp und ftp ebenfalls.
Wisst ihr was man da noch versuchen könnte, oder wo der Fehler liegt?
Was sind die Unterschiede auf den Servern bei denen das Problem auftritt, vielleicht kommt man so dahinter?
Hier (ist ein interner Server der nicht am Internet hängt deswegen ist nicht alles auf aktuellem Stand, vielleicht liegt es daran?):
Edit:
Fehler ist eingegrenzt und es scheint weder ein ftplicity noch duplicity Problem zu sein:
Das hört sich verdächtig nach kaputter Festplatte an, hoffentlich habe ich nicht recht. ls -alh geht nicht, nano zeigt eine php-Datei an die diese komischen Zeichen am Anfang hat: 
dabei taucht folgendes im Log auf:
Kann jemand damit etwas anfangen?
Seit ein paar Tagen habe ich den gleichen Fehler wie ovizii wieder.
ftplicity+duplicity wäre genial wenn der Fehler nicht wäre, was kann man da nur machen?
Code:
# ftplicity backup
...
Comparing ('srv', 'www', 'htdocs', 'web', 'html', 'user_center', '_notes', '***.LCK') and ('srv', 'www', 'htdocs', 'web', 'html', 'user_center', '_notes', '***.php.mno.LCK')
Selecting /srv/www/htdocs/web/html/***.php.mno
Comparing ('srv', 'www', 'htdocs', 'web', 'html', 'user_center', '_notes', '***.php.mno') and ('srv', 'www', 'htdocs', 'web', 'html', 'user_center', '_notes', '***.php.mno')
/usr/local/bin/ftplicity: line 219: 24769 Speicherzugriffsfehler FTP_PASSWORD="$ZIEL_PW" PASSPHRASE="$GPG_PW" TMPDIR="$TEMP_DIR" $DUPLICITY --encrypt-key $GPG_KEY --sign-key $GPG_KEY --verbosity $VERBOSITY "$@"
gpg: Error writing to `-': Datenübergabe unterbrochen (broken pipe)
gpg: handle plaintext failed: Dateischreibfehler
gpg: Error writing to `-': Datenübergabe unterbrochen (broken pipe)
gpg: handle plaintext failed: Dateischreibfehler
root@****:~/.ftplicity# gpg: Error writing to `-': Datenübergabe unterbrochen (broken pipe)
gpg: handle plaintext failed: Dateischreibfehler
gpg: Error writing to `-': Datenübergabe unterbrochen (broken pipe)
gpg: handle plaintext failed: Dateischreibfehler
gpg: Error writing to `-': Datenübergabe unterbrochen (broken pipe)
gpg: handle plaintext failed: Dateischreibfehler
...
*Die Dateinamen habe ich etwas gekürztWas mir dabei aufgefallen ist: Ich habe versucht mehrmals "ftplicity backup" aufzurufen, jedesmal tritt der Fehler an exakt der selben stelle auf. Am nächten Tag lief es dann wieder ohne Probleme durch. Wieder ein paar Tage später fing dass Spiel von vorne an, allerdings blieb er dann woanders stehen (das muss dann bei /var/mail/userp10 gewesen sein). Auch hier war es wieder so das bei jedem erneuten starten der Fehler an der gleichen stelle auftauchte und ein Tag später ging es wieder. Nur jetzt versuche ich es schon 3 Tage erfolglos, so langsam sollte das mit den Backups wieder laufen bevor Murphy vorbeischaut.
Ich kann mich nach/vor jedem Auftreten des Fehlers ohne Probleme an meinen Backupserver per ftp anmelden, Verbindungsprobleme schließe ich daher fast aus, Speichermangel auf /tmp und ftp ebenfalls.
Wisst ihr was man da noch versuchen könnte, oder wo der Fehler liegt?
Was sind die Unterschiede auf den Servern bei denen das Problem auftritt, vielleicht kommt man so dahinter?
Hier (ist ein interner Server der nicht am Internet hängt deswegen ist nicht alles auf aktuellem Stand, vielleicht liegt es daran?):
- SuSE Linux 9.0 (i586) (aber nicht mehr lange ^^)
- duplicity 0.4.2, backend: FTP, extern
- ftplicity 1.1.1
- gpg 1.2.2
- librsync 0.9.6
- perl 5.8.1
Edit:
Fehler ist eingegrenzt und es scheint weder ein ftplicity noch duplicity Problem zu sein:
Code:
root@***: cd /srv/www/htdocs/web/html/user_center/_notes
root@***:/srv/www/htdocs/web/html/user_center/_notes# ls -alh
Speicherzugriffsfehler
root@***: nano /srv/www/htdocs/web/html/user_center/_notes/note.php.mno
<?xml version="1.0" encoding="utf-8" ?>
<info>
<infoitem key=
...dabei taucht folgendes im Log auf:
Code:
root@***: dmesg
<1>Unable to handle kernel paging request at virtual address 04000000
printing eip:
c0153608
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c0153608>] Not tainted
EFLAGS: 00010206
eax: c9345c40 ebx: c9345c40 ecx: 00000000 edx: 04000000
esi: 00000000 edi: dfbd7014 ebp: c265ff40 esp: c265ff0c
ds: 0018 es: 0018 ss: 0018
Process ls (pid: 26654, stackpage=c265f000)
Stack: c0b403a0 c265ff40 dfbd7000 c0153ff3 c0b403a0 c265ff40 00000008 00000246
00000009 00000246 00000008 c265ff98 00000000 dfbd7000 00000014 a3e80a02
bfffeea0 c265ff98 dfbd7000 00000000 c265ff98 c0154879 dfbd7000 dfbd7000
Call Trace: [<c0153ff3>] [<c0154879>] [<c0154c39>] [<c01535b5>] [<c015026f>]
[<c0107403>]
Code: 8b 0a 85 c9 75 0a 89 d8 8b 5c 24 08 83 c4 0c c3 89 04 24 8bKann jemand damit etwas anfangen?
Last edited by a moderator:
Kramer-Wolf
New Member
Duplicity FTP timeout causing incomplete backup sets
Hi,
ich hatte bei längeren Backups regelmäßig das Problem, daß das Backup mit einem Timeout Error 421 abgebrochen wurde. Die Folge davon waren incomplete backup sets. Der Reconnect Patch hat bei mir nicht funktioniert, allerdings habe ich eine Variante mit zweistufigem Recovery daraus gemacht.
Zuerst wird der fehlerhafte Befehl wiederholt, später dann versucht die Verbindung neu aufzubauen. Ob die zweite Stufe funktioniert kann ich nicht sagen, da bei mir immer schon die erste zum Erfolg führt.
Außerdem habe ich eine Umschaltung auf FTP passive Mode eingebaut, da mein Server kein aktive Mode unterstützt. Ausgewählt wird es über eine Globale Variable. Mag sein, daß es ein anderes Setting gibt... habe es nur leider nicht gefunden. Wer zwischen den Modi wechselt muß also neu Binden.
backend.py
patch to in version 0-4-2
Bei mir funktioniert es seitdem.
Viel Spaß
Hi,
ich hatte bei längeren Backups regelmäßig das Problem, daß das Backup mit einem Timeout Error 421 abgebrochen wurde. Die Folge davon waren incomplete backup sets. Der Reconnect Patch hat bei mir nicht funktioniert, allerdings habe ich eine Variante mit zweistufigem Recovery daraus gemacht.
Zuerst wird der fehlerhafte Befehl wiederholt, später dann versucht die Verbindung neu aufzubauen. Ob die zweite Stufe funktioniert kann ich nicht sagen, da bei mir immer schon die erste zum Erfolg führt.
Außerdem habe ich eine Umschaltung auf FTP passive Mode eingebaut, da mein Server kein aktive Mode unterstützt. Ausgewählt wird es über eine Globale Variable. Mag sein, daß es ein anderes Setting gibt... habe es nur leider nicht gefunden. Wer zwischen den Modi wechselt muß also neu Binden.
backend.py
patch to in version 0-4-2
Code:
import os, types, ftplib, tempfile
import log, path, dup_temp, file_naming
+import time
class BackendException(Exception): pass
class ParsingException(Exception): pass
+FTPMODE = 0 # 0 for passive mode; 1 for active mode
.......
class ftpBackend(Backend):
"""Connect to remote store using File Transfer Protocol"""
+ SLEEP = 10 # time in seconds before we try to reconnect on temporary errors
+ RETRIES = 3 # max count of retries in case of FTP errors, like loss of connection
+ RETRIELEVEL = 1 # 1 = try to repeat command, 2 = try to reinit
def __init__(self, parsed_url):
"""Create a new ftp backend object, log in to host"""
self.parsed_url = parsed_url
self.ftp = ftplib.FTP()
+ self.error_wrap('set_pasv', FTPMODE)
if parsed_url.port is None: self.error_wrap('connect', parsed_url.host)
else: self.error_wrap('connect', parsed_url.host, parsed_url.port)
if parsed_url.user is not None:
self.error_wrap('login', parsed_url.user, self.get_password())
else: self.error_wrap('login')
self.ftp.cwd(parsed_url.path)
def error_wrap(self, command, *args):
"""Run self.ftp.command(*args), but raise BackendException on error"""
try: return ftplib.FTP.__dict__[command](self.ftp, *args)
+- except ftplib.all_errors, e:
+ #ftplib.error_temp, e:
+ self.RETRIES = self.RETRIES - 1
+ if self.RETRIELEVEL > 1:
+ if self.RETRIES > 0:
+ log.Log("Temporary error '%s'. Trying to reconnect in %d seconds." %
+ (str(e), self.SLEEP), 3)
+ time.sleep(self.SLEEP)
+ self.__init__(self.parsed_url)
+ self.error_wrap(command, *args)
+ else:
+ self.RETRIES = 3
+ self.RETRIELEVEL = 1
+ raise BackendException(e)
+ else:
+ if self.RETRIES > 0:
+ log.Log("Temporary error '%s'. Trying to repeat command in %d seconds." %
+ (str(e), self.SLEEP), 3)
+ time.sleep(self.SLEEP)
+ self.error_wrap(command, *args)
+ else:
+ self.RETRIES = 3
+ self.RETRIELEVEL = 2
+ #except ftplib.all_errors, e: raise BackendException(e)Bei mir funktioniert es seitdem.
Viel Spaß
noch ein Tip zu ftplicity ...
Hallo allerseits,
erstmal danke an alle, u.a. hab ich mir mit dem Patch von Kramer-Wolf ein
Debian-Paket von duplicity bauen können.
Das habe ich mit ff. Änderung im ftplicity-Script gelöst:
statt
verwende ich jetzt
Was dazu führt, dass als Konfig-Verzeichnis der Scriptname verwendet wird,
also z. B. .ftplicity, .ftplicity-mail usw. je nachdem wie ich die Kopie oder den Hardlink von ftplicity nenne.
Damit kann ich im obigen Beispiel einfach das .ftplicity-Verzeichnis nach .ftplicity-mail kopieren und "conf" sowie "exclude" ändern
Falko
Hallo allerseits,
erstmal danke an alle, u.a. hab ich mir mit dem Patch von Kramer-Wolf ein
Debian-Paket von duplicity bauen können.
Das habe ich mit ff. Änderung im ftplicity-Script gelöst:
statt
Code:
ME=$(basename "$0")
CONFDIR="$HOME/.ftplicity"
CONF="$CONFDIR/conf"verwende ich jetzt
Code:
ME=$(basename "$0")
CONFDIR="$HOME/.$ME"
CONF="$CONFDIR/conf"Was dazu führt, dass als Konfig-Verzeichnis der Scriptname verwendet wird,
also z. B. .ftplicity, .ftplicity-mail usw. je nachdem wie ich die Kopie oder den Hardlink von ftplicity nenne.
Damit kann ich im obigen Beispiel einfach das .ftplicity-Verzeichnis nach .ftplicity-mail kopieren und "conf" sowie "exclude" ändern
Falko
ovizii
New Member
hi leute,
die geschichte hat sich anscheinend weiterentwickelt, neuere duplicity versionen, gepatchte ftplicity versionen, etc.
Ich habe nun nach dieser anleitung: duplicity 0.4.6 released :: WE ARE ROOT manuell duplicity 0.4.6 installiert, da die aktuelle in debian stable hinterherhinkt. dort wird auch eine gepatchte ftplicity version angeboten, da anscheinend die alte version nicht mehr mit duplicity zurechtkam da sich dort wohl die befehlssyntax geändert hat.
all dies scheint mein broken pipe problem gelöst zu haben, allerdigns habe ich jetzt andere Probleme, siehe code weiter unten.
Hat hierzu jemand eine Idee? würde gerne mein Backup wieder zum laufen bringen.
die geschichte hat sich anscheinend weiterentwickelt, neuere duplicity versionen, gepatchte ftplicity versionen, etc.
Ich habe nun nach dieser anleitung: duplicity 0.4.6 released :: WE ARE ROOT manuell duplicity 0.4.6 installiert, da die aktuelle in debian stable hinterherhinkt. dort wird auch eine gepatchte ftplicity version angeboten, da anscheinend die alte version nicht mehr mit duplicity zurechtkam da sich dort wohl die befehlssyntax geändert hat.
all dies scheint mein broken pipe problem gelöst zu haben, allerdigns habe ich jetzt andere Probleme, siehe code weiter unten.
Hat hierzu jemand eine Idee? würde gerne mein Backup wieder zum laufen bringen.
lufthansen
New Member
Also ich habe das gleiche Problem.
Ein kleiner Tip:
/var/spool/postfix auslasen.
Zu meinen symptomen:
Das script läuft an, sichert etliche gigs und bricht an immer anderen stellen ab ..
Früher ist mir auch schon aufgefallen das es timeouts gab *grml*(backup.serverkompetenz.de)
Habe gerade den timeoutpatch laufen bzw. das fertig gemacht debian package.
Danke dafür
Weiß einer von euch ob das in der neusten duplicity verion behoben ist ?
duplicity - Summary [Savannah]
Habe da leider nicht finden können.
Und wenn das klappt könnte man ja teil der Open Source community werden und den patch zurück fließen lassen.
Code:
Getting delta of (('var', 'www', 'confixx', 'awstats', 'web29', 'awstats042007.web29.txt') /var/www/confixx/awstats/web29/awstats042007.web29.txt reg) and None
Generating delta - new file: var/www/confixx/awstats/web29/awstats042007.web29.txt
Saving duplicity-full.2008-04-14T19:57:59+02:00.vol1694.difftar.gpg on FTP server
Traceback (most recent call last):
File "/usr/bin/duplicity", line 373, in ?
if __name__ == "__main__": main()
File "/usr/bin/duplicity", line 363, in main
if action == "full": full_backup(col_stats)
File "/usr/bin/duplicity", line 142, in full_backup
bytes_written = write_multivol("full", tarblock_iter, globals.backend)
File "/usr/bin/duplicity", line 89, in write_multivol
backend.put(tdp, dest_filename)
[COLOR="Red"]File "/usr/lib/python2.4/site-packages/duplicity/backends.py", line 349, in put
self.error_wrap('storbinary', "STOR "+remote_filename, source_file)[/COLOR]
File "/usr/lib/python2.4/site-packages/duplicity/backends.py", line 335, in error_wrap
except ftplib.all_errors, e: raise BackendException(e)
duplicity.backends.BackendExceptionEin kleiner Tip:
Code:
/boot
/dev
/initrd
/lib
/media
/mnt
/proc
/src
/sys
/tmp
/var/tmp
/var/run
/var/lib/reoback
/usr
/bin
/sbin
/var/lib
/var/log
/var/cache
/var/spool/
/var/www/chrootZu meinen symptomen:
Das script läuft an, sichert etliche gigs und bricht an immer anderen stellen ab ..
Früher ist mir auch schon aufgefallen das es timeouts gab *grml*(backup.serverkompetenz.de)
Habe gerade den timeoutpatch laufen bzw. das fertig gemacht debian package.
Danke dafür
Weiß einer von euch ob das in der neusten duplicity verion behoben ist ?
duplicity - Summary [Savannah]
Habe da leider nicht finden können.
Und wenn das klappt könnte man ja teil der Open Source community werden und den patch zurück fließen lassen.