Servus Gemeinde,

ich suche eine (Script) Lösung für meine Backup Lösung die Möglichkeit nach einem automatischen Backup den Mover zu starten und, wenn der Mover durchgelaufen ist, den Server runterzufahren.

Der Backup Server wird von meinem Produktiv Server per WOL über ein cron job gestartet und startet ein cron job Backup Script. Nachdem das Backup durchgelaufen ist fährt der Backup Server scriptgesteuert wieder runter.

Aktuell habe ich noch kein Cache Laufwerk in dem Backup Server verbaut, da beide aktuell nur mit 1000Mbit verbunden sind und bei einer Schreibgeschwindigkeit des Array mit ca. 80MB/s eine schnellere Verbindung nichts bringen würde.

Wunsch wäre das Backup über 2,5 GBit übers Netzwerk laufen zu lassen und die Daten auf dem Backup Server zu cashen. Allerding möchte ich die Daten nicht auf dem Cashlaufwerk lassen, sondern direkt anschließend auf das Array verschieben.

Das Produktiv System könnte dann nach der Übertragung der Daten wieder die Festplatten runterfahren und muss nicht auf das langsame Array des Backup Servers warten.

Hat jemand von Euch eine Lösung/Idee dazu?

Grüße,

Markus

4 hours ago, volleybecker said:

Allerding möchte ich die Daten nicht auf dem Cashlaufwerk lassen, sondern direkt anschließend auf das Array verschieben.

dann füge in deinem BackupSkript am Ende einfach den Mover-Aufruf vor dem Runterfahren ein, also in etwa:

rsync <Optionen> <Profuktiv-Server-Share(s)> <Backup-Server-Share(s)> 	## als Beispiel für dein Backup-"Skript"
mover start																## Mover manuell starten
halt								  									## Herunterfahren

Bedenke beim Cachen der Shares auf dem Backup-Server, wie viel Daten Du da hin sichern möchtest und ob der Cache dafür ausreichend groß ist.

Wen du z.B. eine 1TB SSD als Cache verbaust, aber regelmäßig z.B. 6TB sichern möchtest, macht das wenig Sinn, weil Dir dann der Cache überläuft.

Daher hab ich z.B. keinen Cache im BackupServer, trotz 2,5G 😉

P.S.: laut rsync schreibt mein Array ohne Parity(!) im BackupServer immerhin mit >130MB/s statt nur 80M/s

Edited December 11, 2025Dec 11 by _alo_

18 hours ago, volleybecker said:

Das Produktiv System könnte dann nach der Übertragung der Daten wieder die Festplatten runterfahren und muss nicht auf das langsame Array des Backup Servers warten.

ja, aber ob das sinnig ist wenn man gegenüber stellt

>> write auf cache (Produktiv > Backup)

>> read cache (Backup)

>> write array (Backup)

in Summe "energetisch" ... ich nenn es mal "fragwürdig".

noch ne Alternative, am Backupserver umstellen auf reconstruct (Turbo), damit schreibst du ziemlich mit nativer HDD Geschwindigkeit, da es nur um den Backupserver geht könnte dies eher eine Option sein anstelle 2x die Daten komplett zu kopieren.

15 hours ago, _alo_ said:

dann füge in deinem BackupSkript am Ende einfach den Mover-Aufruf vor dem Runterfahren ein, also in etwa:

rsync <Optionen> <Profuktiv-Server-Share(s)> <Backup-Server-Share(s)> 	## als Beispiel für dein Backup-"Skript"
mover start																## Mover manuell starten
halt								  									## Herunterfahren

Bedenke beim Cachen der Shares auf dem Backup-Server, wie viel Daten Du da hin sichern möchtest und ob der Cache dafür ausreichend groß ist.

Wen du z.B. eine 1TB SSD als Cache verbaust, aber regelmäßig z.B. 6TB sichern möchtest, macht das wenig Sinn, weil Dir dann der Cache überläuft.

Daher hab ich z.B. keinen Cache im BackupServer, trotz 2,5G 😉

P.S.: laut rsync schreibt mein Array ohne Parity(!) im BackupServer immerhin mit >130MB/s statt nur 80M/s

Moin alo,

bist Du sicher, dass der Mover erst komplett durchläuft, bevor der nächste Scriptbefehl ausgeführt wird? Das heißt ich muss das Verschieben der Daten nicht abwarten?

Mit Parity Laufwerk auf dem Backup Server bin ich leider nicht so schnell beim Schreiben der Daten.

Gruß,

Markus

Edited December 12, 2025Dec 12 by volleybecker

1 hour ago, alturismo said:

ja, aber ob das sinnig ist wenn man gegenüber stellt

>> write auf cache (Produktiv > Backup)

>> read cache (Backup)

>> write array (Backup)

in Summe "energetisch" ... ich nenn es mal "fragwürdig".

noch ne Alternative, am Backupserver umstellen auf reconstruct (Turbo), damit schreibst du ziemlich mit nativer HDD Geschwindigkeit, da es nur um den Backupserver geht könnte dies eher eine Option sein anstelle 2x die Daten komplett zu kopieren.

Moin alturismo,

danke für die Anregung. Ich habe mich mit "reconstruct" noch nicht auseinander gesetzt. Gibt es Nachteile neben dem Vorteil des schnelleren Schreibens?

Gruß,

Markus

29 minutes ago, volleybecker said:

bist Du sicher, dass der Mover erst komplett durchläuft, bevor der nächste Scriptbefehl ausgeführt wird?

jein....

schau Dir das Mover-Skript (/usr/local/sbin/mover) ruhig im Detail an...

25 minutes ago, _alo_ said:

jein....

schau Dir das Mover-Skript (/usr/local/sbin/mover) ruhig im Detail an...

..... sorry, bin zu blöd den Pfad zu finden. Bis /usr/local/sbin/ komme ich, aber eine Datei/ein Pfad mover ist da nicht.

kannst Du mir auf die Sprünge helfen?

32 minutes ago, volleybecker said:

..... sorry, bin zu blöd den Pfad zu finden. Bis /usr/local/sbin/ komme ich, aber eine Datei/ein Pfad mover ist da nicht.

kannst Du mir auf die Sprünge helfen?

🤷‍♂️bei meinen beiden unraid Servern (6.12.15 und 7.2.2) finde ich das Skript hier:

root@unraid:~# whereis mover

mover: /usr/local/sbin/mover

root@unraid:~#

3 hours ago, volleybecker said:

Gibt es Nachteile neben dem Vorteil des schnelleren Schreibens?

Das alle HDD laufen und nicht nur 2 (Daten und Parity).

4 hours ago, alturismo said:

ja, aber ob das sinnig ist wenn man gegenüber stellt

>> write auf cache (Produktiv > Backup)

>> read cache (Backup)

>> write array (Backup)

in Summe "energetisch" ... ich nenn es mal "fragwürdig".

Fragwürdig vielleicht, aber je nach Netzwerk-/SSD-Cache-Geschwindigkeit und Backup-Skript kann es doch schon einen signifikanten Unterschied machen.

Vorausgesetzt vom Array lesen ist einiges schneller als das Schreiben auf's neue Array und die Cache-SSD ist viel Stromsparender als das Array.

Generell ist das doch der Hauptgrund für einen Schreibcache: Stromsparen durch schnellere Datenübertragung, oder nicht?

Ich werde es jetzt erst mal mit dem Tip von alturismo probieren und schauen, auf was für Übertragungsraten ich bis zum Array auf den Backup Server komme.

Besten Dank an Euch für Eure Unterstützung 🙂!

Gruß,

Markus

5 hours ago, _alo_ said:

Generell ist das doch der Hauptgrund für einen Schreibcache: Stromsparen durch schnellere Datenübertragung, oder nicht?

ich sag mal eher persönliche Präferenz, mehr Speed ist für mich relevant, ebenso keine spinups und ruhende Platten bei Daten wo ich persönlich länger auf dem Cache vorhalte, aber der usecase hier ...

was spar ich denn effektiv, ja, am Produktiv können die lesenden Platten schneller wieder in den sleep, im Gegenzug beschreibe ich einen cache und danach lese / schreibe ich vom cache auf hdd im Backup System bevor das wieder in den sleep geht, also selbst rein energetisch gerechnet wage ich zu bezweifeln dass das aufgeht.

Aber das Schöne ist ja, jeder wie er mag, und ja, dein Ansatz oben passt ja, kann man mit ner Prüfschleife noch abfangen usw und der gewollte workflow wäre auch umsetzbar, ich wollte nur eine Alternative aufzeigen.

meine Backups laufen auch direkt ins Array bei Server 2, sind ja nicht sooo viele GB wenn ich Medien wöchentlich kopiere, mit 2.5G geht das auch recht flott.

Ich wollte noch kurz Rückmeldung geben, wie ich es aktuell gelöst habe.

Den Backup Server habe ich auf reconstruct write umgestellt.

Backup und Produktiv Server sind über 2,5GBit Switch verbunden (sind noch die beiden einzigen Devices die das beherrschen im Netzwerk).

Die Netzwerk Geschwindigkeit vom Produktiv Server ist standard mäßig auf 1GBit gedrosselt (spart ca. 1 Watt).

Im WOL Script für den Backup Server schaltet der Produktiv Server zusätzlich seine Netzwerkverbindung auf 2,5GBit um => beide Server sind nun über 2,5GBit miteinander verbunden.

Backup Server zieht sich jetzt die zu sichernden Daten vom Produktiv System und erreicht dabei ~ 180 - 200 MB/s Schreibgeschwindigkeit.

Nach dem Job legt sich der Backup Server wieder schlafen und das Produktiv System schaltet 2 Stunden nach Start des Scripes wieder auf 1GBit Verbindung um.

Für mich eine brauchbare Lösung 😊

@alturismo und @ alo besten Dank noch mal für Eure Anregungen 👍