Problem beim Sichern verschlüsselter Ordner auf dem Hidrive

sf034149

Benutzer
Mitglied seit
17. Juli 2011
Beiträge
1
Punkte für Reaktionen
0
Punkte
0
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?
 

artvandelay

Benutzer
Mitglied seit
04. März 2011
Beiträge
7
Punkte für Reaktionen
0
Punkte
0

Herbert_Testmann

Benutzer
Mitglied seit
27. Juli 2009
Beiträge
1.105
Punkte für Reaktionen
0
Punkte
62
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

Benutzer
Mitglied seit
22. November 2009
Beiträge
234
Punkte für Reaktionen
0
Punkte
0
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

Benutzer
Mitglied seit
19. Januar 2008
Beiträge
1.736
Punkte für Reaktionen
0
Punkte
0
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

Benutzer
Mitglied seit
22. November 2009
Beiträge
234
Punkte für Reaktionen
0
Punkte
0
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

Benutzer
Mitglied seit
08. September 2011
Beiträge
7
Punkte für Reaktionen
0
Punkte
0
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

Super-Moderator
Teammitglied
Mitglied seit
03. Juni 2009
Beiträge
6.765
Punkte für Reaktionen
10
Punkte
164
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

Benutzer
Mitglied seit
22. November 2009
Beiträge
234
Punkte für Reaktionen
0
Punkte
0
Gibt es schon einen zeitrahmen für strato, wann die das problem gefixt haben?
 

franky1080

Benutzer
Mitglied seit
08. September 2011
Beiträge
7
Punkte für Reaktionen
0
Punkte
0
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

Benutzer
Mitglied seit
22. November 2009
Beiträge
234
Punkte für Reaktionen
0
Punkte
0
Ich hab's nochmal ausprobiert, es geht nicht. Super :-(
 

franky1080

Benutzer
Mitglied seit
08. September 2011
Beiträge
7
Punkte für Reaktionen
0
Punkte
0
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:
  1. Öffnen der Windows Eingabeaufforderung
  2. Zum betroffenen Shared Folder wechseln, indem man den Laufwerksbuchstaben angibt (kein cd o.Ä.), z.B. "Y:"
  3. Danach folgendes Kommando eingeben: "cd /"
  4. 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
  5. Wenn der Befehl abgearbeitet ist, die list.txt Datei öffnen und den gesammten Inhalt in ein Excel Sheet in Spalte A kopieren
  6. Danach in Spalte B folgende Formel für alle Einträge nutzen: =LÄNGE(A1)-LÄNGE(WECHSELN(KLEIN(A1);"\";))
  7. Die Daten mit Hilfe von Excel nach Spalte B sortieren
  8. 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

Benutzer
Mitglied seit
11. Januar 2011
Beiträge
140
Punkte für Reaktionen
0
Punkte
16
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

Moderator
Mitglied seit
19. August 2008
Beiträge
18.275
Punkte für Reaktionen
0
Punkte
0
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

Benutzer
Mitglied seit
21. Februar 2013
Beiträge
36
Punkte für Reaktionen
0
Punkte
0
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

Benutzer
Mitglied seit
29. März 2008
Beiträge
15
Punkte für Reaktionen
0
Punkte
0
Hi,

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

andres_ffm

Benutzer
Mitglied seit
14. Juli 2012
Beiträge
8
Punkte für Reaktionen
0
Punkte
0
..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+

Benutzer
Mitglied seit
27. Juni 2013
Beiträge
53
Punkte für Reaktionen
0
Punkte
0
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:
  1. Öffnen der Windows Eingabeaufforderung
  2. Zum betroffenen Shared Folder wechseln, indem man den Laufwerksbuchstaben angibt (kein cd o.Ä.), z.B. "Y:"
  3. Danach folgendes Kommando eingeben: "cd /"
  4. 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
  5. Wenn der Befehl abgearbeitet ist, die list.txt Datei öffnen und den gesammten Inhalt in ein Excel Sheet in Spalte A kopieren
  6. Danach in Spalte B folgende Formel für alle Einträge nutzen: =LÄNGE(A1)-LÄNGE(WECHSELN(KLEIN(A1);"\";))
  7. Die Daten mit Hilfe von Excel nach Spalte B sortieren
  8. 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

Benutzer
Mitglied seit
08. September 2011
Beiträge
7
Punkte für Reaktionen
0
Punkte
0
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....
 

DS213+

Benutzer
Mitglied seit
27. Juni 2013
Beiträge
53
Punkte für Reaktionen
0
Punkte
0
Das interne D & R (was man ja auch fürs HiDrive nehmen kann) kann es und zeigt brav nur die Differenz an.
 
  AdBlocker gefunden!

Du bist nicht hier, um Support für Adblocker zu erhalten, denn dein Adblocker funktioniert bereits ;-)

Klar machen Adblocker einen guten Job, aber sie blockieren auch nützliche Funktionen.

Das Forum wird mit einem hohen technischen, zeitlichen und finanziellen Aufwand kostenfrei zur Verfügung gestellt. Wir zeigen keine offensive oder Themen fremde Werbung. Bitte unterstütze dieses Forum, in dem du deinen Adblocker für diese Seite deaktivierst.