Problem beim Sichern verschlüsselter Ordner auf dem Hidrive

sf034149 · 17. Jul 2011

Hallo zusammen,
ich habe ein Problem beim Sichern von verschlüsselten Ordnern auf das Strato Hidrive Laufwerk. Ich habe schon im Forum alles durchgesucht und auch die Strato FAQ gelesen, auch schon den Strato Support angeschrieben (aber keine Antwort erhalten) und das ganze in diversen Tests und Variationen durchprobiert - kein Erfolg. Ich bin mit meinem Latein am Ende.

Ich sichere meine Daten von meiner DS211+ (Software Version: DSM 3.1-1.748) regelmässig auf mein Hidrive Lauftwerk mit Hilfe der Hidrive Backup App bzw. direkt über den "Datensicherung und Wiederherstellung"-Dialog. *Als Backup Modul habe ich "/users/myuser/test" eingetragen. Metadaten werden nicht gesichert, Verschlüsselung ist aktivert. Dies klappt auch sehr zuverlässig nur die Sicherung von auf dem NAS verschlüsselten Ordnern will nicht gelingen.

Die Sicherung der unverschlüsselten Daten läuft problemlos durch. Weiterhin kann ich z.B. auf meinen eigenen rsync Server im LAN problemlos auch verschlüsselte Ordner sichern. Daher *bin ich mir recht sicher, dass kein Problem mit Zugangsdaten, Internetverbindung oder Berechtigungen auf NAS oder Hidrive besteht. Dennoch bricht die Sicherung auf das Hidrive Laufwerk grundsätzlich ab, wenn die verschlüsselten Daten an der Reihe sind. Die verschlüsselten Ordner selber werden noch kopiert, aber es werden keine Dateien in den Ordnern gesichert.

In der HiDrive Backup App erscheint dann die Fehlermeldung:
"Fehlgeschlagen. Bitte sehen sie hierzu in das [Netzwerksicherungsprotokoll]"

Im Netzwerksicherungsprotokoll findet sich die Information:

"2011/07/09 12:26:04 SYSTEM
Network Backup failed to backup task [Crypted_6] to [rsync.hidrive.strato.com]. ([43] Fehler bei der Verbindung zum Zielserver. Bitte stellen Sie sicher, dass: 1. Der Servername oder die IP korrekt ist. 2. Der Netzwerk-Sicherungsdienst auf dem Zielserver aktiviert wurde. 3. Der Zielserver mit einem aktiven Netzwerk verbunden ist.)"

Weiterhin findet sich in der /var/logs/messages noch folgender Hinweis:

Jul *9 12:26:04 synohidrivebkp: backup_rsync_execv.c:387 Failed to execute rsync command. source=[/volume2/@crypted@/ECRYPTFS_FNEK_ENCRYPTED.FWYRurFhP2LOYkaYtOcbaeIY3-.3tU1HRFESpRsDis5kudppuSoxXrg59k--], target=[myuser@85.214.3.28:/users/@myuser@/
Jul *9 12:26:04 synohidrivebkp: synohidrivebkp.c:546 Failed to execute rsync command. source=[/volume2/@crypted@/ECRYPTFS_FNEK_ENCRYPTED.FWYRurFhP2LOYkaYtOcbaeIY3-.3tU1HRFESpRsDis5kudppuSoxXrg59k--], target=[(null)], ret=43

Hat jemand eine Idee was der Fehler sein könnte?

Anzeige · 17. Jul 2011

Hallo sf034149,

Bücher und Hardware zum Thema gibt es bei Amazon: Problem beim Sichern verschlüsselter Ordner auf dem Hidrive

artvandelay · 03. Aug 2011

Ich habe das gleiche Problem. In diesem http://www.synology-forum.de/showthread.html?22351-DS-211-Festplatten-Empfehlung-2-TB-Anforderungen]Thread sind wir auf das gleiche Thema gestoßen (etwas weiter unten).

In meinem ersten Posting hatte ich den verschlüsselten Backup noch nicht getestet. Im Moment tippe ich darauf, dass Strato mit der Hardware-Verschlüsselung nicht zurechtkommt. Aber vielleicht gibt es hier oder in dem anderen Posting noch einen Experten-Rat.

Herbert_Testmann · 03. Aug 2011

Ich kann nur mal soviel dazu sagen, dass ein Backup auf den Amazon Onlinespeicher auch mit verschlüsselten Ordnern funktioniert. Das läuft bei mir 2x wöchentlich durch. Deshalb würde ich das Problem erst einmal bei Strato sehen.

glowaq · 07. Sep 2011

Wie sichert ihr die daten genau? Werden die verschlüsselten ordner/dateien gesichert, oder unverschlüsselt?
Ich möchte keinen meine unverschlüsselten daten anvertrauen.

ag_bg · 07. Sep 2011

Herbert_Testmann schrieb:
Ich kann nur mal soviel dazu sagen, dass ein Backup auf den Amazon Onlinespeicher auch mit verschlüsselten Ordnern funktioniert. Das läuft bei mir 2x wöchentlich durch. Deshalb würde ich das Problem erst einmal bei Strato sehen.

Hast du auch schon mal wieder hergestellt, da bricht er bei mir nämlich immer nach der Erstellung der Ordner ab, egal, ob ich schon angehängt habe oder nicht.

best regards

glowaq · 08. Sep 2011

So, da ich einen HiDrive account habe, hatte ich gestern meine DS409+ auf die DSM3.2 upgedated. Schnell das hidrive packet vom synology installiert (aus dem DSM).

Wenn ich ein verschlüsselted share angebe, dann kann ich in klartext die dateien auswählen, sichern tut er die verschlüsselten datein (oder er verschlüsselt neu?).
Leier bricht er mit dem oben beschriebenen fehler ab "([43] Fehler bei der Verbindung zum Zielserver. Bitte stellen Sie sicher, dass: 1. Der Servername oder die IP korrekt ist. 2. Der Netzwerk-Sicherungsdienst auf dem Zielserver aktiviert wurde. 3. Der Zielserver mit einem aktiven Netzwerk verbunden ist.)"

Was kann das sein?

franky1080 · 08. Sep 2011

Das ist ein bekanntes Problem auf den Strato Servern. Verschlüsselte Ordner in Kombination mit Strato HiDrive führen zum besagten Fehler.
Der Synology Support hat mir geschrieben, dass es hier ein Problem auf den Strato Servern gibt. Synology arbeitet momentan mit Strato hieran. Einen Zeithorizont konnte man mir bisher nicht nennen....

amarthius · 08. Sep 2011

Seit der CeBit dieses Jahr lief es recht gut. Ab Anfang August wurde meine Sicherung auf das HiDrive auch nicht mehr durchgeführt.

Werbung machen kann Strato gut, von etwas reibungslos lauffähigem konnten sie mich bisher noch nicht überzeugen.

Schön, dass zumindest beide Firmen Bescheid wissen.

glowaq · 14. Sep 2011

Gibt es schon einen zeitrahmen für strato, wann die das problem gefixt haben?

franky1080 · 24. Sep 2011

Angeblich ist das Problem im DSM 3.2 zusammen mit der neuen HiDrive App gelöst. Bei mir funktioniert es aber immer noch nicht. Strato untersucht den Fall erneut.

glowaq · 24. Sep 2011

Ich hab's nochmal ausprobiert, es geht nicht. Super :-(

franky1080 · 12. Dez 2011

Nachdem weder Synology noch Strato das Problem lösen konnten, habe ich nach einiger Forschungsarbeit das Problem selbst gelöst

Ausgang war die Hypothese von mir, dass die langen Pfadnnamen, die durch die Verschlüsselung der Datei- und Ordnernamen entstehen, die Ursache des Problems sein könnten. Strato und Synology wollten hiervon zunächst nichts wissen. Trotzdem hat mir das keine Ruhe gelassen und ich habe einen Versuch gemacht: ich habe einen neuen (unverschlüsselten) shared Folder auf meinem NAS angelegt und hiermit einen Test zum Strato HiDrive gemacht => Läuft. Danach habe ich sukzessive neue Unterordner à 50 Zeichen angelegt. Sobald man eine Zeichenlänge größer 1024 erreicht, brach das Backup mit der gleichen Fehlermeldung ab.
Die Ursache des Problems schien also gefunden. Nachdem ich Strato dies gemeldet hatte, wurde mir dieses Problem auch bestätigt. Eine Lösung dieses Problem ist laut Stato technisch bedingt allerdings nicht machbar (ich selbst vermute eine Limitierung im Rsync Protokoll).

Soweit so gut. Als nächstes musste ich also rausfinden, welche Pfade die Abbrüche verursachen. Da man von den verschlüsselten Datei- und Ordnernamen nur sehr schwer auf den unterverschlüsselten Pfad schließen kann, musste ein anderes Verfahren her. Ich habe daher Stichproben entnommen, wie lang die verschlüsselten Datei- und Ordnernamen sind. Es zeigte sich, dass diese in einer Range von 84 bis 104 Zeichen je Datei- bzw. Ordnername lagen. Daraus folgt, dass ein Pfad max. aus 8 Ordner + Dateiname bestehen darf.

Um diese Pfade zu identifizieren, habe ich folgedes gemacht:

Öffnen der Windows Eingabeaufforderung
Zum betroffenen Shared Folder wechseln, indem man den Laufwerksbuchstaben angibt (kein cd o.Ä.), z.B. "Y:"
Danach folgendes Kommando eingeben: "cd /"
Dann folgenden Befehl eingeben: "dir /a/s/b > list.txt". Das erzeugt auf dem entsprechenden Laufwerk eine Textdatei list.txt, die alle Pfade des entsprechenden Laufwerks enthält
Wenn der Befehl abgearbeitet ist, die list.txt Datei öffnen und den gesammten Inhalt in ein Excel Sheet in Spalte A kopieren
Danach in Spalte B folgende Formel für alle Einträge nutzen: =LÄNGE(A1)-LÄNGE(WECHSELN(KLEIN(A1);"\")
Die Daten mit Hilfe von Excel nach Spalte B sortieren
Alle Zeilen, bei denen der Eintrag in Spalte B größer 9 ist, versuchen den Fehler [43]. Diese müssen eliminiert werden (z.B. durch ein Neuorganisieren oder indem man die betroffenen Ordner in ein ZIP File packt)

Danach ist der Fehler nicht mehr bei mir aufgetreten.

ueffchen · 13. Dez 2011

Hi franky1080

das ist mal eine Leistung!

Leider finden sich die Gründe für die meisten Fehler nur durch langes rumprobieren und verifizieren. Das musste ich auch leidvoll bei Problemen mit geänderten Truecrypt Ordnern und fehlendem Backup von Root-Verzeichnissen feststellen.... hat ewig gedauert, bis ich den Fehler gefunden hatte....

Nochmals: Alle Achtung!

Gruss, ueffchen

jahlives · 13. Dez 2011

1024 Zeichen Grenze klingt mir auch nach einer Beschränkung im Anwendungsprotokoll. Weiss jemand ob bei Strato da im Hintergrund ein Webserver seine Finger im Spiel haben kann? 1024 Zeichen klingt mir irgendwue bekannt im Zusammenhang mit Websevern. Meinte dass sei die Grenze für GET Parameter. Bricht denn auch ein lokales Backup mit rsync bei denselben Ordnern ab?

hohony · 25. Mrz 2013

Mittlerweile sind 15 Monate vergangen und wir sind mittlerweile bei DSM 4.2.....

Das Problem ist (wie ich schmerzlich feststellen durfte) nach wie vor das Gleiche...:-((

Ich halte es (zumindest bei uns) weder für praktikabel noch durchführbar, die Ordnerstruktur
Strato anzupassen. Strato selbst scheint nicht interessiert, das Problem zu lösen.
Mein Ticket dahingehend ist eine Woche alt und unbeantwortet. Telefonisch hat man mir
jedoch das Wissen um diese Begrenzung bestätigt.

Wie auch immer...gibt es denn mittlerweile Workarounds (ggf. mit anderen Anbietern)?

Pacecar3 · 17. Jun 2013

Hi,

Auch ich habe dieses Problem, daher würde es mich interessieren ob es zu diesem Thema mittlerweile was neues gibt?

andres_ffm · 23. Jul 2013

..das Gleiche hier: gleicher Fehler, seit über einer Woche keinerlei Reaktionen seitens Strato.

Wie witzig eigentlich.., verschlüsselte Dateien lassen sich nicht sichern - in Anbetracht der aktuellen Diskussionen könnte man ja noch auf andere Gedanken kommen. Dann doch lieber die USB-Platte bei Muttern im Keller verstecken.

DS213+ · 23. Jun 2014

franky1080 schrieb:
Nachdem weder Synology noch Strato das Problem lösen konnten, habe ich nach einiger Forschungsarbeit das Problem selbst gelöst

Ausgang war die Hypothese von mir, dass die langen Pfadnnamen, die durch die Verschlüsselung der Datei- und Ordnernamen entstehen, die Ursache des Problems sein könnten. Strato und Synology wollten hiervon zunächst nichts wissen. Trotzdem hat mir das keine Ruhe gelassen und ich habe einen Versuch gemacht: ich habe einen neuen (unverschlüsselten) shared Folder auf meinem NAS angelegt und hiermit einen Test zum Strato HiDrive gemacht => Läuft. Danach habe ich sukzessive neue Unterordner à 50 Zeichen angelegt. Sobald man eine Zeichenlänge größer 1024 erreicht, brach das Backup mit der gleichen Fehlermeldung ab.
Die Ursache des Problems schien also gefunden. Nachdem ich Strato dies gemeldet hatte, wurde mir dieses Problem auch bestätigt. Eine Lösung dieses Problem ist laut Stato technisch bedingt allerdings nicht machbar (ich selbst vermute eine Limitierung im Rsync Protokoll).

Soweit so gut. Als nächstes musste ich also rausfinden, welche Pfade die Abbrüche verursachen. Da man von den verschlüsselten Datei- und Ordnernamen nur sehr schwer auf den unterverschlüsselten Pfad schließen kann, musste ein anderes Verfahren her. Ich habe daher Stichproben entnommen, wie lang die verschlüsselten Datei- und Ordnernamen sind. Es zeigte sich, dass diese in einer Range von 84 bis 104 Zeichen je Datei- bzw. Ordnername lagen. Daraus folgt, dass ein Pfad max. aus 8 Ordner + Dateiname bestehen darf.

Um diese Pfade zu identifizieren, habe ich folgedes gemacht:

Öffnen der Windows Eingabeaufforderung

Zum betroffenen Shared Folder wechseln, indem man den Laufwerksbuchstaben angibt (kein cd o.Ä.), z.B. "Y:"

Danach folgendes Kommando eingeben: "cd /"

Dann folgenden Befehl eingeben: "dir /a/s/b > list.txt". Das erzeugt auf dem entsprechenden Laufwerk eine Textdatei list.txt, die alle Pfade des entsprechenden Laufwerks enthält

Wenn der Befehl abgearbeitet ist, die list.txt Datei öffnen und den gesammten Inhalt in ein Excel Sheet in Spalte A kopieren

Danach in Spalte B folgende Formel für alle Einträge nutzen: =LÄNGE(A1)-LÄNGE(WECHSELN(KLEIN(A1);"\")

Die Daten mit Hilfe von Excel nach Spalte B sortieren

Alle Zeilen, bei denen der Eintrag in Spalte B größer 9 ist, versuchen den Fehler [43]. Diese müssen eliminiert werden (z.B. durch ein Neuorganisieren oder indem man die betroffenen Ordner in ein ZIP File packt)

Danach ist der Fehler nicht mehr bei mir aufgetreten.

Vielen Dank für die ausführliche, sogar für mich nachvollziehbare Anleitung. Hat mein Problem gelöst. Interessant war, das die größte Verschachtelungstiefe bei den Metadaten (bis 14) auftrat. Das Kreuz habe ich jetzt in der Backuptask entfernt, ein paar Ordner umorganisiert und siehe da, das Backup läuft durch. Komisch ist nur, das es immer die Gesamtgröße des Backups anzeigt, um dann aber doch nur die Differenz zu sichern. Somit hat man keinen Anhaltspunkt, wie lange es laufen wird.

franky1080 · 24. Jun 2014

Tja, die Anzeige ist in der Tat schon ein wenig irritierend. Eine Vorhersage, wann ein inkrementelles Backup zu Ende ist, kann man leider nicht erstellen. Da hilft nur warten....