Backup bricht ab - Dateien nicht kopierbar

[octopus]

Ich habe nun endlich das Update auf 3.2 1944 gewagt. Läuft soweit alles gut.
Jetzt kann ich auch endlich einzelne Ordner backuppen und damit meine zwei 2TB-Platten nutzen, die ich über USB mit meiner DS1010 angebunden habe.

Alle Backups bis auf ein größeres (schätze 1,5TB in 2 Ordnern) klappen.

Das was nicht klappt ist heute Nacht nach 2h55min abgebrochen.

Systemmeldung:Local Backup failed

Im Datensicherungsprotokoll stehen viele Dateien hintereinander, die nicht kopiert werden konnten:
Failed to copy file (...)

Leider kann ich damit nichts anfangen. Warum konnte das NAS diese Dateien nicht sichern. Berechtigungen sollten passen, da diese Dateien in der gleichen Verzeichnisstruktur liegen wie die anderen Dateien, die ich kopieren kann?

Freue mich über Hilfe.

 

[schimi007]

Welches Format haben die Dateien? Sind Sonderzeichen in den Dateinamen?

 

[octopus]

Es handelt sih um *.xmp und *.cr2 Dateien, also die Änderungsdateien von Photoshop Lightroom und Canon-RAW-Files.

Die Dateien heißen:
Der Pfad lautet:
volume1/Fotos/Fotos/2010/2010.05.22 Feld- und Sprungbilder Name und Name/HG6W6034.cr2

 

[JudgeDredd]

Nur um sicher zu gehen ... Dateien haben eigene Berechtigungen und nicht zwangsläufig die des übergeordneten Verzeichnisses.
Vermutlich hast Du das aber schon geprüft.

 

[jahlives]

mhm du hast scheinbar Leerzeichen in den Dateinamen/Pfadangaben. Gut möglich, dass dies das Problem sein könnte

 

[Struppix]

Hi,

sorry das ich wiederspreche, aber Leerzeichen sollten im Normalfall kein Problem darstellen. Einige Sonderzeichen schon eher, wobei die meisten nicht beeindrucken.

Die Berechtigungen könnten ein Problem sein, bzw. die Gruppenzugehörigkeit der Dateien ? Machmal murrt er, wenn keine Guppe drin steht.

Wie sicherst Du denn. Ersetzt Du die Daten in der aktuellen oder schreibst Du neu ? Falls die schon existierenden nicht überschrieben werden können, geht es auch nicht.

Also Rechte Prüfen und Testweise mal ein File umbenennen. Die gesicherten Daten sollten im Nomalfall keine User und Gruppenrechte haben. Liege ich hier falsch ?

Gruß
Struppix

 

[octopus]

Eigentlich habe ich die Berechtigungen nur auf dem kompletten Ordner. DIeser ist in Jahresordner 1982, 1983,..2011 aufgeteilt.
Da die Ordner 2010 und 2011 an die Festplattenbeschränkung stossen, habe ich für die beiden eine eigene Sicherung angelegt. 1983-2009 sichert gerade. Mal sehen, ob das klappt.

Ich erstelle eine neue (initiale) Sicherung. Diese soll auch bei Löschung die Dateien beibehalten.

 

[jahlives]

sorry das ich wiederspreche, aber Leerzeichen sollten im Normalfall kein Problem darstellen.

Definiere Normalfall
Normalerweise sind Leerzeichen bei Linux nicht erlaubt resp sollten nicht verwendet werden, weil nicht alle Programme damit sauber umgehen können. Wenn z.B. das Programm ein vorhandenes Leerzeichen nicht sauber escaped, dann wird das Leerzeichen als Ende der Pfadangabe angeschaut und der Pfad bricht in zwei Teile, die beide nicht existieren

 

[Struppix]

War mir klar ....

Sicherlich sind Leerzeichen bei Linux nicht erlaubt. Jedoch kannst Du gerade bei allen anderen Usern ( andere Systeme ) nicht davon ausgehen, diese nicht zu verwenden. Sie tun es dennoch. Und dennoch sichert er diese bei mir ohne Probleme.
Jedoch gibt es ab und zu mal Aussetzer, wo im Namen ein Leerzeichen zu sehen ist, aber in wirklichkeit ein Sonderzeichen steht, das im verwendeten Zeichensatz aber keinen Pedanten hat, wenn ich das mal so laienhaft ausdrücken darf. Dann wurde durch eine ungewollte Tastenkombination oder ein Sonderzeichen eines beliebigen MS Programms ein "nicht zu sehendes" Sonderzeichen eingebaut. Und da ja alle faul sind, wie ich auch, wird diese Benennung dann immer wieder kopiert. Superfies.

Aber wie gesagt, ich gebe Dir ja recht

Struppix

 

[octopus]

ich kann jaetzt aber nicht 500 Ordnernamen ändern... ? :-(
Das Problem ist, dass ich das nicht automatisiert machen könnte, da ich das aus Lightroom heraus machen muss (sonst erkennt mein Katalog die Pfade nicht).
Kann ich irgendwo detailierter sehen, wodurch der Abbruch verursacht wurde, bzw. warum das kopieren nicht möglich war?

 

[octopus]

irgendwie ist mein letzter Post verschluckt worden.
Als: Die Sicherung von den Ordnern 1983-2009 lief sauber durch. Dort seind die Dateien benannt wie in denen wo es abbricht.

Mittlerweile bin ich überzeugt, dass es an der 2. USB-Platte liegt. Sie zeigt mir nun auch folgendes an:
Dateisystemtyp: nicht unterstützt
Wenn ich versuche zu formatieren, bekomme ich die Meldung: Formatierung fehlgeschlagen.

Kann es mit der HD-Dockingstation dieser Platte zusammenhängen? Ist die gleiche wie die der anderen USB-Platte, allerdings hat diese hier zusätzliche Kartenleser-Slots.

Die Platte war aber schon sauber formatiert. Keine Ahnung, warum dieser Status weg ist... Vielleicht könnt Ihr mir ja an dieser Stelle weiterhelfen?

 

[MichaVZ]

Kommt mir irgendwie bekannt vor. Habe 4 externe Platte von WD (WD Elements). Mit keiner kann ich eine Datensicherung machen. Hab noch eine externe Iomega 1TB, mit der Platte läuft es super. Es liegt an dem SATA Controller der verbaut ist. Nachfrage bei Synology bestätigte damals meine Annahme. Nicht alle SATA Controller in externen Gehäusen werden vom BackUp unterstützt. Normale Datenhaltung funktioniert. BackUP bricht nach ein paar Minuten ,bzw. gute halbe Stunde, ab. Vielleicht reicht es gerade für deine genannten Verzeichnisse. Schaumal, ob du einen Unterschied bei beiden Platten vom Controller her findest. Vielleicht kannst du auch mal die Platten tauschen, dann weiß man, ob es der Controller ist.

 

[octopus]

So erstmal vorweg: Meine Sicherung ist heute Nacht erfolgreich durchgelaufen - und mir gehts nun besser.

Was habe ich gemacht: Nachdem der Dateisystemtyp nicht mehr erkannt wurde habe ich die Platte erstmal an meinem Mac auf Fat formatiert. Dann habe ich das extrem dünne USB-Kabel ausgetauscht und die Platte wieder am NAS angehängt und mit EXT4 formatiert.
Ob ich jetzt einfach Glück hatte oder das dünne Kabel Schuld hatte, kann ich nicht wirklich beurteilen - das wäre nur Mutmaßung.

 

[Struppix]

Klingt alles recht ungewöhlich. Aber prima das es jetzt klappt.

Du solltest Sie aber im Auge behalten

 

[LarsTC]

moin moin,

ich habe gerade ein ähnliches Problem und hole daher den Threat noch mal hoch

Hardware:
411+II
DS209

Die Sicherung von der 411 auf die 209 klappte mit Syno Netzwerkbackup bei der ersten Sicherung reibungslos.
Nun wollte ich nach einer Woche den gleichen Task wieder starten.
Es wurden an den Systemeinstellungen nichts verändert, auf beiden DS.
Task gestartet und nach 5min mit Fehler "permission" abgebrochen.
Auch bei mir handelt es sich bei den Ordnern um Fotos nach Jahr und Monat (2011.01 , 2011.02 etc.).
Testweise nur einen Ordner für die Sicherung an gehackt, 2011.01. Wieder der gleiche Fehler
Zweiter versuch... Ordner auf 2011-01 umbenannt und wieder nur den einen Ordner zum Sichern an gehackt.
Nun lief die Sicherung.
Ich würde bei meinem Fehler also ein Formatierungsproblem ausschließen.
Jedoch gibt es ein Problem mit einem Punkt im Ordnernamen.

Das ganze hatte ich gestern getestet. Das Vollbackup mit allen Ordnern, nachdem ich sie noch umbenannt habe, ist aber trotzdem heutenacht abgebrochen.
Leider konnte ich noch nicht schauen was er diesmal meckert.
Das mit den Berechtigungen wäre natürlich auch noch mal zu prüfen.

Ich geb dann noch mal ein update, wenn ich denn mal eine komplette update-sicherung hinbekommen habe.



Gruß
Lars

 

[octopus]

Hallo Lars,

ich vermute mal Berechtigungsprobleme. Hast Du Änderungen an den Berechtigungen vorgenommen, neue User angelegt und denen etwas zugeordnet, bzw. Ordnern Berechtigungen vergeben, die sich vielleicht in die Quere kommen? Versuche doch mal die Berechtigungen so zu checken, dass auf beiden NAS-Systemen kein Problem vorliegt.

 

[LarsTC]

Hallo Lars,

ich vermute mal Berechtigungsprobleme. Hast Du Änderungen an den Berechtigungen vorgenommen, neue User angelegt und denen etwas zugeordnet, bzw. Ordnern Berechtigungen vergeben, die sich vielleicht in die Quere kommen? Versuche doch mal die Berechtigungen so zu checken, dass auf beiden NAS-Systemen kein Problem vorliegt.

Hi octopus,

nein, wie geschrieben, es wurde an beiden DS nichts verändert.
Das komische ist ja auch, ich hab nicht mal neue Dateien innerhab einer Woche hinzugefügt.
Das Backup hab ich nur mal zum testen angeworfen, was ja wohl auch gut war um den Fehler rechtzeitig zu erkennen

Gruß
Lars

 

[LarsTC]

update

Nachdem ich die Ordner von 2011.01 auf 2011-01 etc umbeannt habe, gab es trotzdem noch ein Fehler.
Diesmal lag es aber wirklich an 2 fehlenden Berechtigungen für die Unterordner, warum auch immer.
Fazit, Berechtigungen + "." im Ordnernamnen = Syno-Backup abbruch.

Nun laufen aber alle Tasks einwandfrei durch.

Gruß
Lars

 

[andlsbuch]

Hallo!

Seit dem ich auf den DSM 3.2-1944 geupdatet habe, läuft mein Backup auch nicht mehr durch.
Ständig bekomme ich die Meldung, dass das Backup abgebrochen wurde. Zuerst brach es nach zirka 9 Stunden ab, danach schon innerhalb einer halben Stunde.

- Local Backup failed
- External Disk [USB Disk blablabla] is ejected

in \var\log\messages finden sich folgende Meldungen:


Nov 8 16:41:58 synnas kernel: [249771.080000] end_request: I/O error, dev sdq, sector 1074816
Nov 8 16:41:58 synnas kernel: [249771.090000] Buffer I/O error on device sdq1, logical block 134320
Nov 8 16:41:58 synnas kernel: [249771.100000] Buffer I/O error on device sdq1, logical block 134321
Nov 8 16:41:58 synnas kernel: [249771.110000] Buffer I/O error on device sdq1, logical block 134322
Nov 8 16:41:58 synnas kernel: [249771.120000] Buffer I/O error on device sdq1, logical block 134323
Nov 8 16:41:58 synnas kernel: [249771.130000] Buffer I/O error on device sdq1, logical block 134324
Nov 8 16:41:58 synnas kernel: [249771.150000] Buffer I/O error on device sdq1, logical block 134325
Nov 8 16:41:58 synnas kernel: [249771.160000] Buffer I/O error on device sdq1, logical block 134326
Nov 8 16:41:58 synnas synolocalbkp: synocopyfile.c:155 Fail to write file /volumeUSB2/usbshare/LocalBackup/Backup/Laptop/Music/iTunes/iTunes Media/Mobile Applications/eBay 2.3.0.ipa!! errno=[30/Read-only file system]
Nov 8 16:41:58 synnas synolocalbkp: synocopyfile.c:99 Failed to open file [/volumeUSB2/usbshare/LocalBackup/Backup/Laptop/Music/iTunes/iTunes Media/Mobile Applications/The Sims 3.ipa], errno=[2/No such file or directory]
Nov 8 16:41:58 synnas kernel: [249771.170000] Buffer I/O error on device sdq1, logical block 134327
Nov 8 16:41:58 synnas kernel: [249771.180000] Buffer I/O error on device sdq1, logical block 134328
Nov 8 16:41:58 synnas kernel: [249771.190000] Buffer I/O error on device sdq1, logical block 134329
Nov 8 16:41:58 synnas kernel: [249771.230000] end_request: I/O error, dev sdq, sector 1075056
Nov 8 16:41:58 synnas kernel: [249771.270000] end_request: I/O error, dev sdq, sector 986056
Nov 8 16:41:58 synnas kernel: [249771.300000] Aborting journal on device sdq1-8.
Nov 8 16:41:58 synnas kernel: [249771.300000] JBD2: I/O error detected when updating journal superblock for sdq1-8.
Nov 8 16:41:58 synnas kernel: [249771.310000] EXT4-fs error (device sdq1): ext4_journal_start_sb_sync: Detected aborted journal
Nov 8 16:41:58 synnas kernel: [249771.320000] EXT4-fs (sdq1): Remounting filesystem read-only
Nov 8 16:41:58 synnas kernel: [249771.320000] EXT4-fs (sdq1): ext4_da_writepages: jbd2_start: 8192 pages, ino 875; err -30
Nov 8 16:41:58 synnas kernel: [249771.350000] EXT4-fs error (device sdq1) in ext4_reserve_inode_write: Journal has aborted
Nov 8 16:41:58 synnas kernel: [249771.360000] EXT4-fs error (device sdq1) in ext4_dirty_inode: Journal has aborted
Nov 8 16:41:58 synnas kernel: [249771.670000] EXT4-fs error (device sdq1): ext4_find_entry: reading directory #2 offset 0


Kann damit jemand was anfangen?
Bei den vorigen Firmwareversionen ging der Backupvorgang immer tadellos!

Für Hilfe wär ich echt dankbar!

 

[Ap0phis]

Häng die externe Platte mal an einen PC und check mal die S.M.A.R.T.-Daten,
oder noch besser: benutze das Testtool des Plattenherstellers.

Das sieht mir nach defekten und/oder schwebenden Sektoren aus.