Backup von DS211j per USB 2 auf ext. Platte extrem langsam

[madrix]

Es läuft gerade (seit 1h) ein Voll-Backup von meiner DS211j auf eine extern WD Elements 4TB per USB 2.

Das Backup läuft mit etwa 5,8MB/s.

Bei der Geschwindigkeit und 2,35GB zu archivierenden Daten... dauert das etwa 5 Tage.

Ist das normal?

 

[Frogman]

Ja - insbesondere, wenn die DS sich gerade mit vielen kleinen Dateien herumschlägt, wie Du auch in zahlreichen Threads zu dem Thema nachlesen kannst.
Die Zeitschätzung wird dann schnell besser, wenn größere Dateien 'dran sind.

 

[madrix]

 

[dil88]

Wie ist die CPU-Auslastung der 211j?

 

[madrix]

schwankt zwischen 80% und 95%

 

[dil88]

Dann ist aus der 211j nicht mehr Performance für diesen ziemlich CPU-belastenden Job herauszukitzeln.

 

[madrix]

zum Glück hat die DS215j dann USB 3

 

[dil88]

... und deutlich mehr Saft.

 

[madrix]

sichert die DS (über den Datensicherungsjob) nach den ersten Vollbackup inkrementell?

 

[dil88]

Die verwendete rsync-Software sichert immer das, was neu ist oder sich geändert hat. Ggfs. - das ist konfigurierbar - löscht sie im Backup das, was auf der Quelle gelöscht wurde.

 

[madrix]

was passiert z.b. mit Datei A (10GB), wenn ich sie intern auf der DS verschirbe (also von Ordner X in Ordner Y)?

Wird sie dann komplett neu gesichert? Oder nur die Änderung des Pfades?

 

[dil88]

Sie wird neu gesichert.

 

[madrix]

elegant ist anders

aber danke für die Info

 

[Frogman]

Unelegant mag sein - doch die Ursache dafür liegt nicht bei Synology, sondern in rsync, was hier verwendet wird, das gleiche Verhalten hast Du also unter allen Anwendungen, die darauf aufbauen.

 

[dil88]

elegant ist anders

Ja und nein. Rsync ist ein tolles Tool, da lass ich nichts drauf kommen. Überleg Dir in einer ruhigen Minute einmal, was nötig wäre, um Deinen - selbstverständlich eleganten und wünschenswerten - Ansatz zu programmieren.

 

[madrix]

md5 hash auf die Datei und einfach prüfen, ob sie noch da liegt, wo sie lag. Wenn der Hash an einer anderen Stelle vorkommt, einfach den Pfad ändern. Ist der Hash neu, einfach neu speichern

 

[dil88]

Sehr schön, dann bau das einmal und schau Dir die Laufzeit an. Man kann rsync auch mit Prüfsummentesting statt Timestamp-/Größenprüfung laufen lassen. Probier das einmal aus. Ich habe es als unbrauchbar langsam in Erinnerung, aber vielleicht täusche ich mich auch. Teste nicht auf einem PC sondern bitte auf einer DS-CPU.

 

[Frogman]

Das Thema ist allerdings etwas komplexer. Auch die blockweise Erkennung einer Änderung (die ja auch genutzt wird) nutzt Checksummen - und da ist schon die Frage, ob die Checksumme hinreichend ist (ist sie nämlich nicht unbedingt, eine Checksumme kann auch für unterschiedliche Blöcke differieren, wie man hier zB. erläutert findet).
Es es gibt offenbar auch noch andere Fallstricke (vgl. hier).

 

[madrix]

ich wollte nur pöbeln

ich hab viel zu wenig entwickler know-how um hier konstruktiv was vorzuschlagen.

 

[dil88]

Ich habe ja selbst noch eine andere Idee - möglicherweise macht es Dropbox ja so: Man klinkt sich ins Betriebssystem ein und fängt die Calls ab, die Daten speichern. Dann könnte man für die Calls, die die eigenen Daten betreffen, eine "Änderungsliste" führen - so ähnlich, wie Du es oben auch formuliert hast. Das wäre sehr intelligent und für das Thema Cloudsync fast schon essentiell, aber erfordert schon eine Menge Know-How.