Wir setzen eine zweite 1513 als Backup Medium für eine Master 1513 ein. Schön wäre es wenn der Master die Slave 1513 automatisch hoch- und wieder runterfahren könnte. Ist das prinzipiell möglich und vor allem wie ?
Kann eine DS eine andere hoch- und runterfahren ?
- Ersteller Micha81
- Erstellt am
-
Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.
Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.
Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier
- Status
Ist mir so nicht bekannt.
Aber man könnte doch einen Zeitplan festlegen, so dass Sie z.B. Sonntags morgens startet, 10 Minuten später startet man automatisch den Backup Prozess, und abends fährt man Sie automatisch wieder runter.
Wäre das keine Lösung?
Aber man könnte doch einen Zeitplan festlegen, so dass Sie z.B. Sonntags morgens startet, 10 Minuten später startet man automatisch den Backup Prozess, und abends fährt man Sie automatisch wieder runter.
Wäre das keine Lösung?
Ja sicher wäre das ein Workaround. Das einzige Problem ist nur dass man nicht abschätzen kann wie lange das Backup läuft und man daher sehr großzügig das Runterfahren planen muss.
Es wäre daher wesentlich eleganter wenn die Master DS das triggern könnte.
Es wäre daher wesentlich eleganter wenn die Master DS das triggern könnte.
- Registriert
- 03. Feb. 2012
- Beiträge
- 18.991
- Reaktionspunkte
- 630
- Punkte
- 484
Man könnte die DS zum einen per WOL wecken. Dazu gibt es mindestens mal ein IPKG-Paket (wakelan !?), setzt natürlich IPKG voraus.
Herunterfahren ist auf einem ähnlichen Weg möglich. Die DS könnte der anderen DS per script und SSH ein poweroff senden.
Problematisch an der Geschichte ist das Erkennen des Endes des Backups.
So hatte ich mir das mal überlegt. Umgesetzt habe ich es aber nun so: Ziel-DS fährt nach Plan hoch. Die Backups starten nach Plan ein paar Minuten später. Auf der Ziel-DS gibt es zum einen einen Plan zum Herunterfahren (großzügig dimensioniert) und zum anderen das 3rd-Party-Package Advanced-Power-Manager (APM). Der APM ist in der Lage, den Shutdown solange zu verzögern, wie noch Netzwerktraffic in einstellbaren Schwellen erkannt wird.
Das funktioniert bisher ganz gut.
Herunterfahren ist auf einem ähnlichen Weg möglich. Die DS könnte der anderen DS per script und SSH ein poweroff senden.
Problematisch an der Geschichte ist das Erkennen des Endes des Backups.
So hatte ich mir das mal überlegt. Umgesetzt habe ich es aber nun so: Ziel-DS fährt nach Plan hoch. Die Backups starten nach Plan ein paar Minuten später. Auf der Ziel-DS gibt es zum einen einen Plan zum Herunterfahren (großzügig dimensioniert) und zum anderen das 3rd-Party-Package Advanced-Power-Manager (APM). Der APM ist in der Lage, den Shutdown solange zu verzögern, wie noch Netzwerktraffic in einstellbaren Schwellen erkannt wird.
Das funktioniert bisher ganz gut.
Das Starten ist gar nicht mal so das Problem. Ich weiss ja wann das Backup läuft und kann daher die DS nach Plan hochfahren. Beim Runterfahren sieht es dann halt völlig anders aus da der Zeitpunkt nicht bekannnt ist. Aber ich schaue mir das APM mal an. Wenn es bei dir funktioniert wäre es hier vielleicht auch eine Option.
Nach einigen Tagen fummeln und fragen habe ich das Backup nun vollautomatisiert am Laufen. Die Ziel-DS fährt per Timer hoch. Ein paar Minuten später wird auf der Quell-DS der Backup-Job gestartet. Am Ende wird die Ziel-DS wieder heruntergefahren.
Der eigentliche rsync Befehl lautet
rsync -av -e "ssh -i /root/.ssh/id_rsa -b x.x.x.x" /volume1 root@y.y.y.y:Ziel
Der Punkt ist, dass diese Methode extrem langsam ist. Die Datentransferraten brechen bei dieser Methode auf durchschnittlich 10MB/s ein. Das Backup über die Kommandozeile läuft somit ca. 40h (hochgerechnet!) während der Datensicherungsassistent nach 6h fertig ist und immer zwischen 60 und 120MB/s liegt. Das ist in der Praxis so nicht zu gebrauchen. Warum ist das so langsam ? Lässt sich das beschleunigen ? Mache ich etwas falsch ?
Der eigentliche rsync Befehl lautet
rsync -av -e "ssh -i /root/.ssh/id_rsa -b x.x.x.x" /volume1 root@y.y.y.y:Ziel
Der Punkt ist, dass diese Methode extrem langsam ist. Die Datentransferraten brechen bei dieser Methode auf durchschnittlich 10MB/s ein. Das Backup über die Kommandozeile läuft somit ca. 40h (hochgerechnet!) während der Datensicherungsassistent nach 6h fertig ist und immer zwischen 60 und 120MB/s liegt. Das ist in der Praxis so nicht zu gebrauchen. Warum ist das so langsam ? Lässt sich das beschleunigen ? Mache ich etwas falsch ?
- Registriert
- 03. Feb. 2012
- Beiträge
- 18.991
- Reaktionspunkte
- 630
- Punkte
- 484
Interessant! Ich bin mit rsync (also auch über die eingebaute Sicherung & Wiederherstellung, denn die benutzt auch rsync) noch nie signifikant über 20MB/s gekommen!
Meinst du evtl. 10MBit/s ?? Das wäre in der Tat langsam.
Ich meine schon MB/s.
Daher empfinde ich die Sicherung per Assistent auch als sehr schnell. An der Kommandozeile oder per Script sieht das völlig anders aus. Dann sind es wie bereits geschrieben nur noch maximal 10MB/s mit der Tendenz deutlich weniger. Dafür muss es ja einen Grund geben wenn beides auf rsync basiert.
Daher empfinde ich die Sicherung per Assistent auch als sehr schnell. An der Kommandozeile oder per Script sieht das völlig anders aus. Dann sind es wie bereits geschrieben nur noch maximal 10MB/s mit der Tendenz deutlich weniger. Dafür muss es ja einen Grund geben wenn beides auf rsync basiert.
- Registriert
- 03. Feb. 2012
- Beiträge
- 18.991
- Reaktionspunkte
- 630
- Punkte
- 484
Ich jetzt?
Ich bin einfach total verwundert ob dieser hohen Transferraten. Ich bekomme wie gesagt im Schnitt ca. 20MB/s (große Files) wenn ich über den DSM sichere. Dabei ist die Verschlüsselung ausgeschaltet.
Das wird der springende Punkt sein. Die Verschlüsselung macht den Unterschied. Im DSM läuft es unverschlüsselt und nicht komprimiert. Nur leider ist das ganze damit für mich so nicht mehr zu gebrauchen da die Datenmengen einfach zu groß sind und selbst die inkrementiellen Backups nicht fertig werden. Also doch Datensicherungsassistent.
Die Angelegenheit ist zumindest für mich doch etwas mysteriös. Ich habe jetzt die ssh Verschlüsselung entfernt. Der plain-rsync Befehl wird damit zu:
rsync -av --address=x.x.x.x quelle root@x.x.x.y:ziel
Die Datentransferraten sehen dann wie folgt aus:
Im Schnitt meldet rsync etwa 13MB/s. Das ist nur minimal höher als in der Version mit SSH-Verschlüsselung und kein Vergleich zu den Transferraten die der Assistent erreicht. Irgend etwas macht der Assistent noch anders.
rsync -av --address=x.x.x.x quelle root@x.x.x.y:ziel
Die Datentransferraten sehen dann wie folgt aus:
Im Schnitt meldet rsync etwa 13MB/s. Das ist nur minimal höher als in der Version mit SSH-Verschlüsselung und kein Vergleich zu den Transferraten die der Assistent erreicht. Irgend etwas macht der Assistent noch anders.
Hatte ich bisher nicht. So versiert bin ich da nicht. Allerdings führt der Befehl zu einer Fehlermeldung mt der ich ebenfalls nichts anfangen kann:
ps aux | grep rsync
ps: invalid option -- a
BusyBox v1.16.1 (2013-05-07 00:18:18 CST) multi-call binary.
Usage: ps
Report process status
Options:
w Wide output
ps aux | grep rsync
ps: invalid option -- a
BusyBox v1.16.1 (2013-05-07 00:18:18 CST) multi-call binary.
Usage: ps
Report process status
Options:
w Wide output
- Status
Kaffeautomat
Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.
Als Dankeschön schalten wir deinen Account werbefrei.
