Network backup failed [23]

Status
Für weitere Antworten geschlossen.

Gorgsenegger

Benutzer
Mitglied seit
12. Apr 2011
Beiträge
22
Punkte für Reaktionen
2
Punkte
3
Hallo zusammen,

ich erhalte beim Backup per rsync immer nach einiger Zeit den Fehler

Rich (BBCode):
"Network backup failed to backup task [BackupName] to [rsync.hidrive.strato.com]. ([23] Some files could not be transferred. Possible reasons 1) backup user has no permissions to read the files 2) files are deleted 3) illegal file name 4) too many folders.)"

Ich besitze ein Synology DiskStation DS111, mit der aktuellsten Firmware. Prinzipiell funktioniert das Backup mittels rsync (mittlerweile...), und ich habe auch knapp 150GB bereits auf dem HiDrive. Leider ist die Fehlermeldung im Backup Log aber sehr wenig aussagekräftig, hat man irgendeine Möglichkeit, das ganze weiter einzugrenzen? Der Fehler tritt auf, seit ich auch mein Fotos sichere, der Großteil bzw. soweit ich es sehen kann sogar alle sind mittlerweile auf dem HiDrive, komische Dateinamen sehe ich nicht, Zugriffsrechte sollten entweder ganz oder gar nicht passen, von daher denke ich auch nicht, dass hier der Fehler liegt. Leider läuft das Backup aber nicht mehr bis zum Ende durch, hat jemand eine Idee?

Danke und viele Grüße

G.
 

amarthius

Super-Moderator
Teammitglied
Mitglied seit
03. Jun 2009
Beiträge
6.812
Punkte für Reaktionen
33
Punkte
174
Kann es sein das die Gesamtgröße der zu sichernden Daten sehr groß ist und dein Upload sehr gering ist? Daher kommt es während des laufenden Jobs zu einer Zwangstrennung von deinem Provider (Standard nach 24Std.) und rsync bringt einen Fehler, da die Verbindung abbricht und du eine neue externe IP zugewiesen bekommst.
 

Gorgsenegger

Benutzer
Mitglied seit
12. Apr 2011
Beiträge
22
Punkte für Reaktionen
2
Punkte
3
Kann es sein das die Gesamtgröße der zu sichernden Daten sehr groß ist und dein Upload sehr gering ist? Daher kommt es während des laufenden Jobs zu einer Zwangstrennung von deinem Provider (Standard nach 24Std.) und rsync bringt einen Fehler, da die Verbindung abbricht und du eine neue externe IP zugewiesen bekommst.

Guten Morgen,

nein, das ist nicht der Grund. Im Falle der Zwangstrennung vom Provider gibt es eine andere Fehlermeldung (siehe auch http://www.synology-forum.de/showthread.html?20069-rsync-Backup-f%E4ngt-immer-wieder-von-vorne-an&highlight=vorne). Es scheint irgendeine Datei / Verzeichnis zu sein, wo im Namen evtl. ein falsches / "kaputtes" Zeichen ist oder etwas ähnliches, leider sagt die Fehlermeldung aber gar nichts weiter aus - wie bekomme ich die Diskstation oder rsync dazu, bei der Fehlermeldung mal etwas konkreter zu werden?

Gruß

G.
 

clako

Benutzer
Mitglied seit
26. Mai 2011
Beiträge
81
Punkte für Reaktionen
0
Punkte
6
Hallo,
bei mir ist es genau das gleiche Problem. Die Meldung tritt beim sichern mit rsync auch auf dem lokalen Backuprechner auf. Alle Dateien werden fehlerfrei übertragen habe ich getestest mit Files bis 150GB Größe. Diese Meldung erscheint bei mir immer beim sichern der Fotos (ganz normale jpg), anzahl ist auch egal. Die Fotos werden aber scheinbar richtig übertragen! Kann es evtl. mit den Metadateien zusammenhängen?

Clako
 

Paddy666

Benutzer
Mitglied seit
01. Jul 2011
Beiträge
24
Punkte für Reaktionen
0
Punkte
1
Hallo,
bei mir tritt jetzt der gleiche Fehler [23] auf. Ich suche mir einen Wolf, welche Datei das Problem machen könnte. Hat einer hier schon eine Lösung für dieses Problem gefunden. Ich habe die 211J mit aktueller DSM drauf.
Paddy
 

Ap0phis

Benutzer
Mitglied seit
16. Dez 2010
Beiträge
6.731
Punkte für Reaktionen
3
Punkte
158
Versucht mal "@eaDir" bei rsync auszuschliessen.
Irgendwas habe ich noch in Erinnerung ... gerade, weil oben als erster Zeitpunkt des Fehlers die zusätzliche Sicherung der Fotos erwähnt wurde. ;)
 

Paddy666

Benutzer
Mitglied seit
01. Jul 2011
Beiträge
24
Punkte für Reaktionen
0
Punkte
1
Da ich die GUI verwende um den Backup Job zu ertellen kann ich keine Ausschlüsse als Filter einstellen.
Ich habe den Übeltäter aber jetzt gefunden. Es sind einfache Textdateien mit kurzen einfachen Dateinamen, in Verzeichnissen die aus 8 Zahlen (Datum) bestehen. Diese Verzeichnisse werden von einem GPS Logger erzeugt. Sobald ich dieses Verzeichnis ausschließe läuft der Backup ohne Problem durch.
Keine Ahnung was an diesen Dateien falsch sein könnte!?
 

Gorgsenegger

Benutzer
Mitglied seit
12. Apr 2011
Beiträge
22
Punkte für Reaktionen
2
Punkte
3
Da ich die GUI verwende um den Backup Job zu ertellen kann ich keine Ausschlüsse als Filter einstellen.
Ich habe den Übeltäter aber jetzt gefunden. Es sind einfache Textdateien mit kurzen einfachen Dateinamen, in Verzeichnissen die aus 8 Zahlen (Datum) bestehen. Diese Verzeichnisse werden von einem GPS Logger erzeugt. Sobald ich dieses Verzeichnis ausschließe läuft der Backup ohne Problem durch.
Keine Ahnung was an diesen Dateien falsch sein könnte!?

Guten Morgen,

wie bist Du denn auf diese Dateien gekommen? Bei mir ist immer noch alles wie gehabt, es wird (soweit ich das einigermaßen manuell feststellen kann) wohl alles gesichert, den Fehler erhalte ich aber trotzdem jede Nacht. Ggf. müsste der Synology-Support mal auf die Diskstation drauf und sich das angucken, mangels detaillierterer Rückmeldung stehe ich immer noch im Wald, welche Datei(en) hier den Probleme verursachen könnten...

Gruß

G.
 

Paddy666

Benutzer
Mitglied seit
01. Jul 2011
Beiträge
24
Punkte für Reaktionen
0
Punkte
1
Hallo,
ich versuche es mal aus dem Kopf zu erklären. Du musst per SSH auf die Diskstation. Unter var/log wird nur eine große Log Datei geschrieben. Die heißt Messages.log oder so. Du erkennst an Datei Datum/Zeit das es die zuletzt geschriebenen Log Datei ist (die anderen Log Datein die da liegen werden scheinbar nicht neu geschrieben sind leer oder haben den Stand der Auslieferung). Die kannst du mit vi öffnen und da stehen dann die Dateinamen drin, bei denen der Backup nicht funktioniert hat.
Warum er mit den Dateien Probleme hat weis ich aber auch nicht.
Beste Grüße
Paddy
 

Gorgsenegger

Benutzer
Mitglied seit
12. Apr 2011
Beiträge
22
Punkte für Reaktionen
2
Punkte
3
Hallo,
ich versuche es mal aus dem Kopf zu erklären. Du musst per SSH auf die Diskstation. Unter var/log wird nur eine große Log Datei geschrieben. Die heißt Messages.log oder so. Du erkennst an Datei Datum/Zeit das es die zuletzt geschriebenen Log Datei ist (die anderen Log Datein die da liegen werden scheinbar nicht neu geschrieben sind leer oder haben den Stand der Auslieferung). Die kannst du mit vi öffnen und da stehen dann die Dateinamen drin, bei denen der Backup nicht funktioniert hat.
Warum er mit den Dateien Probleme hat weis ich aber auch nicht.
Beste Grüße
Paddy

Hallo,

das stimmt leider nicht. Ich habe auch schon versucht, im syslog fündig zu werden, aber da gibt es keine weitergehenden Informationen die einem helfen würden, die Datei(en) oder Verzeichnisse einzugrenzen. Danke trotzdem für den Vorschlag und

viele Grüße

G.
 

ueffchen

Benutzer
Mitglied seit
11. Jan 2011
Beiträge
144
Punkte für Reaktionen
0
Punkte
16
Hallo

ich hatte auch mit DSM3.1 (sowohl mit dem Standard Backup/Restore tool aber auch der Hidrive App) den Fehler 23.

Vorweg das Resultat: nach Update auf DSM 3.2 ist das Problem bei mir verschwunden.

Zur Fehlersuche (die ich angefangen hatte, die dann aber plötzlich endete)

Meine initiale Vermutung war, dass das Problem mit den Thumbnails zusammenhing, die für jedes Foto generiert werden. Die Thumbnails (in den @eaDirs) haben Dateinamen mit ':' drin, also dachte ich, das wäre eventuell das Problem. Ich hatte dann alle eaDirs auf der DS und auf dem Hidrive mittels Skript gelöscht, die Konfigdatei für die Thumbnails auf der DS geändert (':' mit '_' ersetzt) und die Generierung von Thumbnails auf der DS wieder gestartet.
Während die Thumbnails mit neuen Dateinamen generiert wurden, habe ich erstmal ein Backup laufen lassen, das nur auf Ordner mit MP3s beschränkt war. Dieses Backup lief durch, obwohl die DS auch aus den MP3 Album Arts in @eaDirs Thumbnails mit ':' erzeugt. Das war auch nicht zu ändern, da diese Einstellung nicht in einer Konfigdatei sondern direkt in einer Binärdatei liegt. Aber somit war mein Schluss: an den ':' in den Thumbnail Dateinamen liegt es nicht.

Als nächste Fehlerquelle habe ich dann meine etwas ungünstigen Verzeichnisnamen für die Fotos vermutet. Die Verzeichnisnamen enthalten '[' und ']', die ein Datum umschliessen, zB [2011-01-12]. Leider nicht die beste Idee, da die eckigen Klammern von vielen Linux Skripten als Steuerzeichen gebraucht werden...
Was mich immer noch wunderte, war dass unter DSM3.0 alles lief. Aber es half ja nichts, der Fehler war nun mal da...
Ich habe dann einige Zeit gebraucht ein Skript zu bauen, um automatisch alle eckigen Klammern vom PC, NAS und Hidrive aus den Verzeichnissen zu entfernen (ich hatte keine Lust alle Verzeichnisse neu hochzuladen, zu viele GByte).

Als ich das Skript testen wollte, wurde DSM 3.2 verfügbar. Das habe ich dann installiert...Fehler 23 verschwunden.

Beim derzeitigen Backup via Hidrive App habe ich das Backup von Thumbnails im Moment abgewählt. Aber ich denke nicht dass das Grund dafür ist, dass alles wieder durchläuft, weil (wie oben beschrieben) die MP3 Thumbnails schon bei 3.1 das Problem nicht machten - also bleibt wohl das Sonderzeichen im Dateinamen der Foto Ordner.
Hier http://www.synology-wiki.de/index.php/Dateien_im_/volume1-Verzeichnis wird auch auf einige nicht erlaubte Zeichen hingewiesen, aber ob das auch mein Problem bei 3.1 erklärt und warum es bei 3.0 und 3.2 kein Problem ist, das ist mir nicht klar.

Gruss, ueffchen
 

Gorgsenegger

Benutzer
Mitglied seit
12. Apr 2011
Beiträge
22
Punkte für Reaktionen
2
Punkte
3
Danke für Dein Posting, aber leider hatte ich nicht das Glück, dass sich bei mir mit DSM 3.2 etwas geändert hätte. Problem ist wie die ganze Zeit über das gleiche, ggf. muss ich auch mal mit diesen Thumbnailordnern / -bildern etc. gucken, wobei das Problem ja dann bei unzähligen Leuten auftreten müsste.

Viele Grüße

G.
 

ueffchen

Benutzer
Mitglied seit
11. Jan 2011
Beiträge
144
Punkte für Reaktionen
0
Punkte
16
Ja, ich denke auch nicht dass es an den Thumbnails i.A liegt, dann wären zuviele Leute betroffen.
Ich vermute auch eher ein Problem mit Sonderzeichnen in den Datei- oder Verzeichnisnamen.
Vielleicht musst Du mal ein rysnc auf Kommandoebene absetzen und die Fehlermeldungen in eine Datei umleiten

Gruss, ueffchen
 

Gorgsenegger

Benutzer
Mitglied seit
12. Apr 2011
Beiträge
22
Punkte für Reaktionen
2
Punkte
3
Das hatte ich schon probiert, aber wie es bei solchen Sachen so ist, gab es da dann keine hilfreichen Fehlermeldungen bzw. es gab gar nicht erst irgendwelche Probleme. Momentan bin ich mit meiner Zeit leider auch recht knapp bemessen, aber ich werde mich ab Mitte Oktober dann nochmals genauer mit der Thematik "vergnügen" ;-)

Viele Grüße

G.
 

Greenhorn76

Benutzer
Mitglied seit
15. Jul 2010
Beiträge
25
Punkte für Reaktionen
0
Punkte
1
Hallo zusammen,

bei mir erscheint auch bei allen Sync-Tests diese Meldung:

Error,Netzwerksicherung,2014/04/XX XX:19:25,SYSTEM,"Network Backup failed to backup task [SicherungXXXXXXX] to [rsync.hidrive.strato.com]. ([23] Some files could not be transferred. Possible reasons: 1) backup user has no permission to access the files, 2) files are deleted, 3) illegal file name.)"

Ich habe schon alles probiert. Leider lässt sich das Problem nicht lokalisieren.

Ich lade meine Bilder übrigens über Picasa vom Fotoapperat runter, damit Picasa diese dann gleich in die Ordner sortiert.

Wer kann helfen ? Hat mal jmd bei Synology direkt angefragt ? Oder bei Strato ?

VG

Greenhorn
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat