Sicherung auf externe USB-Platte funktioniert nicht (Snow Leopard)

[necarter]

Liebes Forum,

nachdem ich dieses Problem bereits ins offizielle Supportforum gepostet habe, dort aber keine Antwort bekomme habe, versuche ich's also hier ...

Ich verwende eine DS207+ mit der 2.2er Firmware (das Problem trat allerdings auch schon mit der 2.1 auf) und Snow Leopard als OS. Einige der Shares (die per AFP gemountet sind) werden jeden Abend auf eine externe USB-Platte gesichert. Soweit so gut, das funktioniert prinzipiell auch. Allerdings habe ich gleich Problem wie hier schonmal beschrieben:
http://www.synology-forum.de/showthread.html?t=2117

Manchmal bricht das Backup mit der Fehlermeldung
Failed to get status of [/volumeUSB1/usbshare/LocalBackup/Archiv/Mac OS X/._Opera-10.01.dmg].

gefolgt von

Failed to remove file [/volumeUSB1/usbshare/LocalBackup/Archiv/Mac OS X/@eaDir/._Opera-10.01.dmg].

ab. Opera-10.01.dmg ist in diesem Falle nur ein Beispiel. Anscheinend passiert das immer dann, wenn die Original-Datei auf der DS gelöscht wurde, das inkrementelle Backup die Datei auf der USB-Platte also auch löschen müßte - es aber nicht tut und stattdessen mit obiger Fehlermeldung abbricht. Entsprechend zieht das dann immer eine vollständige Sicherung nach sich, die dann mehrere Stunden dauert, was natürlich gewaltig nervt.

Hat irgendjemand eine Idee, was hier das Problem sein könnte? Ein Bug im Zusammenspiel mit Mac OS X (Leopard oder Snow Leopard macht übrigens keine Unterschied)?

Viele Grüße,

Nathan

 

[itari]

Wende dich mit dem Problem doch mal per E-Mail an Synology-Support.

Itari

 

[necarter]

Hm, werd ich wohl machen müssen. Mich wundert's ein wenig, daß ich der einzige mit so einem Problem bin. Der Fall, daß man Mac OS X nutzt und Backups von der DS auf eine externe Festplatte macht, ist doch eigentlich nicht so ungewöhnlich.

Ich habe mal ein wenig Nachforschung betrieben. Offensichtlich liegt das Problem an den Extended File Attributes von HFS+. Mit OS X kann man diverse Attribute von Files setzen, wie z.B. ein farbiges Etikett. Das wird dann in besagten Attributes gespeichert. Wenn man nun eine solche Datei auf eine Filesystem kopiert, was derartige Attribute nicht unterstützt, wird eine zusätzlich Datei mit dem Präfix ._ angelegt. In obigem Beispiel bekommt man zusätzlich zu Opera-10.01.dmg auch noch eine zweite Datei namens ._Opera-10.01.dmg. Wichtig scheint an dieser Stelle zu sein, daß die zweite Datei optional ist. Wenn es keine Attribute für eine Datei gibt, wird beim Kopieren auch kein ._Datei angelegt. Eine kurze Erläuterung dieses Mechanismus gibt es hier: http://support.apple.com/kb/TA20578. Apple Double heißt das ganze, leider gibt es für die Präfix-Dateien wohl keinen gescheiten Namen.

Prinzipiell sollte das dem Backup ja egal sein, ich kann das Problem jedoch reproduzieren (Vielleicht kann das jemand hier im Forum mit dem gleichen Setup ja mal ausprobieren ...?).

Mein Setup ist wie folgt: DS207+ mit letzter Firmwareversion. Interne HD mit ext3 formatiert. Externe Festplatte über USB drangehängt, ebenfalls mit ext3 formatiert.

Schritt 1: ein Verzeichnis <Source> auf der DS anlegen und sharen. Backup Job für dieses Verzeichnis anlegen, mit einem Verzeichnis <Target> auf der externen Platte als Ziel.

Schritt 2: Ein paar beliebige Dateien vom Mac aus nach <Source> kopieren, am besten einige DMGs und zusätzlich einige JPGs.

Schritt 3: Per SSH auf der DS einloggen und sich mit ls -la <Source> angucken. Die Wahrscheinlichkeit, daß für die DMGs beschriebene Präfix-Dateien existieren ist relativ hoch (vermutlich weil z.B. dort drin gespeichert wurde, wann das DMG aus dem Internet heruntergeladen wurde). Die JPGs haben (hoffentlich!) keine Präfix-Dateien.

Schritt 4: Backup-Job anwerfen. Das es das erste ist, wird ein vollständiges Backup gezogen. Das sollte funktionieren.

Schritt 5: Vom Mac aus einige der Dateien auf dem Share aus <Source> löschen, die KEINE Präfix-Datei besitzen (hoffentlich die JPGs).

Schritt 6: Backup machen. Das funktioniert bei mir, wie es soll. Die gelöschten Dateien aus dem Share verschwinden auch aus <Target> auf der Backup-Platte.

Schritt 7: Vom Mac aus eine der Dateien löschen, die eine Präfix-Datei besitzen.

Schritt 8: Backup machen. Dieser Schritt schlägt dann bei mir reproduzierbar fehl, mit der Fehlermeldung wie im original Post beschrieben.

Leider gibt es scheinbar keine Möglichkeit, die Erstellung der Präfix-Dateien zu unterbinden. Parallel zu diesem Post werde ich mal dem Support schreiben, mal sehen was die dazu meinen.

 

[jahlives]

Wird diese zusätzliche Datei nur erstellt wenn du die Dateien via afp auf die DS schiebst? Schonmal probiert die Dateien via Samba zu schieben? Läuft das Backup durch wenn du in den Backup Einstellungen den Hacken für inkrementelles Backup entfernst (die in Source gelöschten Dateien also in Target nicht gelöscht werden)? Wie sehen denn die Rechte dieser zusätzlichen Dateien aus? Irgendwelche Unterschiede zur "richtigen" Datei?