Frage zu Remote-Replication & Energieplan

    Hallo Forum-Gemeinde,


    ich habe da eine Frage zum Sicherungsjob von einer QNAP zur anderen.
    Zum Istzustand:
    Habe eine Haupt-NAS (Qnap TS-459 Pro II) und eine Backup-NAS (Qnap 419). Gleicher Plattenspeicher.


    Im Sicherungsmanager der 459 habe ich einen Job eingerichtet unter Remote-Replication "NAS to NAS".
    Dieser Job läuft wöchentlich und es wird hier quasi die ganze NAS 459 auf die 419 gesichert bzw. die bis dato geänderten und hinzugekommenen Dateien überspielt.
    Das funzt problemlos.


    Da ich aber nicht möchte, daß die Backup-NAS 419 die ganze Zeit läuft, habe ich an der 419 im Energiezeitplan eingestellt, daß diese für dieses Backup, das freitags um 9:15 Uhr von der 459 startet, jeden Freitag um 9 Uhr hochfährt und um 12 Uhr wieder runterfährt.
    Bei der 419 kann ich in diesem Energiezeitplan das Häkchen setzen bei "Neustart/Herunterfahren verschieben wenn die Remote-Replication läuft" setzen, aber das hat keine Auswirkung auf die Sicherung, die von der 459 auf die 419 läuft, ergo wenn das Backup länger braucht, dann fährt die 419 um 12 Uhr trotzdem runter.
    Den Job so ändern (bzw. von der 459 auf die 419 verlagern), daß auf der QNAP 419 als Quelle die 459 gewählt wird, ist nicht möglich; hier ist nur die Auswahl eines lokalen Pfads möglich. Ergo muß der Backup-Job auf der 459 eingerichtet sein und dort als Ziel die 419 ausgewählt.


    Ich weiß, ich könnte hier die Laufzeit der 419 verlängern, aber es würde mich interessieren, ob es bei der 419 eine Möglichkeit gäbe, dieser zu sagen, fahre erst dann runter, wenn das Backup von der 459 fertig ist.


    Vielleicht kennt das "Problem" einer von euch und hätte vielleicht einen Rat?


    Vielen Dank

    Zitat von "cobra123"

    (...) Bei der 419 kann ich in diesem Energiezeitplan das Häkchen setzen bei "Neustart/Herunterfahren verschieben wenn die Remote-Replication läuft" setzen, aber das hat keine Auswirkung auf die Sicherung, die von der 459 auf die 419 läuft, ergo wenn das Backup länger braucht, dann fährt die 419 um 12 Uhr trotzdem runter (...) Vielleicht kennt das "Problem" einer von euch (...)


    Ja, das Problem kenne ich auch. Ich mache ebenfalls täglich ein inkrementelles Backup meiner Daten von einem zum anderen QNAP.
    Das Setzen des angesprochenen Hakens nützt leider gar nichts. Wozu gibt es den dann eigentlich?
    Nach meiner Meinung sollte QNAP diesen "Mini-Bug" doch in den Griff bekommen, bevor ich mir große Mühe mit irgendwelchen Workarounds mache...

    bladekiller: Danke für den Tipp, ich werde mich mal einlesen.


    TheRooster2000: Schön zu hören, daß ich nicht der einzige bin mit diesem "Problem" :D
    Ich vermute (getestet habe ich aber noch nicht), daß dieses Häkchen nur relevant sein könnte für die NAS, die das Backup startet, damit diese beim Backup nicht runterfährt. Aber die Sinnhaftigkeit bleibt hier aus meiner Sicht ein wenig auf der Strecke. Ich gebe Dir Recht, QNAP könnte hier nachbessern. Wäre was für den Support. Mal schauen, vielleicht schreibe ich denen. Aber erfahrungsgemäß sich die Antworten/Lösungsansätze von denen wenig hilfreich.

    Zitat von "cobra123"

    Ich vermute (getestet habe ich aber noch nicht), daß dieses Häkchen nur relevant sein könnte für die NAS, die das Backup startet, damit diese beim Backup nicht runterfährt.


    So ist es. Diese Herunterfahrverzögerung läuft nur auf der NAS, die den Backupjob ausführt.


    Finde ich auch durchaus sinnhaftig, weil üblicherweise laufen die Produktiv-NASse meist eh länger (bis 24/7), während die Backup-NASse nur online sein müssen, um eben das Backup zu fahren. Läuft bei mir daheim so nun jahrein, jahraus auch reibunglos. Die Backup-NAS fährt hoch, "saugt" das Backup von der Quell-NAS und fährt sich nach Abschluss des Jobs wieder automatisch herunter.


    Die Erweiterung der Herunterfahrfunktion auch auf die "Gegen-NAS" hatten wir hier bereits erwünscht:
    --> http://forum.qnapclub.de/viewtopic.php?f=405&t=21544


    GLG GBD

    Zitat von "GorillaBD"

    (...) Die Backup-NAS fährt hoch, "saugt" das Backup von der Quell-NAS und fährt sich nach Abschluss des Jobs wieder automatisch herunter (...)


    Hmm, bei mir ist es etwas anders:
    Das Backup-NAS fährt hoch (RRTR Server läuft dort), das Haupt-NAS schiebt per RRTR-Job die Daten auf das Backp-NAS, Backup-NAS fährt wieder herunter.
    Wenn das Herunterfahren dann zu früh erfolgt, ist's schade. Daher wäre es prima, wenn der Haken auch beim Backup-NAS Wirkung hätte.

    Cool, das geht? :?:
    Wie muss man das denn für RRTR konfigurieren? Das muss ich direkt mal ausprobieren...

    Na, erstmal auf der Quell-NAS den RTRR-Server aktivieren.


    Dann auf der Ziel-NAS einfach den RTRR-Job einrichten und starten, anstelle dies auf der Quell-NAS zu tun.


    Dann die Backup-NAS per Zeitplan starten (bei mir: täglich nachts 1:00h) und den RTRR-Job periodisch (bei mir: alle 23h) einstellen.
    Dann im Zeitplan das Herunterfahren auf 1:15h täglich einstellen und den Haken für die Verzögerung bei laufender Replikation setzen.


    Nun startet meine Backup-NAS um 01:00h, wenn sie hochgefahren ist, startet der RTRR.
    Ist der Backupjob nach weniger als 10-15min durch, fährt die Backup-NAS automatisch um 01:15h wieder runter. Dauert der Job länger, fährt sie herunter, wenn der Job fertig ist.


    GLG GBD

    Zitat von "GorillaBD"

    Na, erstmal auf der Quell-NAS den RTRR-Server aktivieren.
    Dann auf der Ziel-NAS einfach den RTRR-Job einrichten und starten, anstelle dies auf der Quell-NAS zu tun (...)


    Supercool, funktioniert :thumb:


    Genau anders herum als ich es konfiguriert hatte.
    Da hätte ich auch gleich drauf kommen können, dann klappt's auch mit dem verzögerten Herunterfahren! ;)


    Besten Dank, vielleicht hilft diese Erkenntnis ja auch dem Thread-Ersteller!


    Evtl. wirkt sich das auch auf mein anderes Problem mit RRTR aus. Hoffentlch wird das dadurch nicht schlimmer!

    @ GorillaBD:
    Danke für die detaillieren Tipps und Hilfestellungen! :thumb:


    Die Idee den Backup-Job von der Ziel-NAS aus zu starten hatte ich ja getestet, aber diese sagte mir, daß die Quelle lokal liegen muß; also war diese Idee für mich dann eine Sackgasse gewesen.
    (Hier mit dem Mounten rumtricksen wollte ich nicht, sollte schon sauer sein)
    Hier habe ich auf der Quell-NAS aber nur die Option Sicherungsmanager / Remotereplikation / NAS to NAS eingerichtet gehabt.
    Du schreibst "RTRR"; ist das dann quasi nix anderes wie meine jetzige Option "NAS to NAS", nur mit dem Unterschied, daß die Quelle nicht lokal liegen muß?
    Oder gäbe es zwischen RRTR und NAS to NAS nennenswerte Unterschiede?
    Danke vorab :D

    Wieder was dazu gelernt,.... interessant


    dachte immer RTRR lief nur im Realtime Modus und nicht im Schedule,... Asche auf mein Haupt

    Nee, der RTRR ist das Schweizer Taschenmesser für alle erdenklichen Replikations- oder Kopieraufgaben von und zu allen Speichermedien und im Netz, und insbesondere durch die FTP-Fähigkeit mit nahezu allen anderen Gegengeräten nutzbar, die einen FTP-Server unterstützen.


    Dieses Tools ist ein Alleinstellungsmerkmal von QNAP, dem hat z.B. Synology nichts vergleichbares entgegenzusetzen. Und schnell ist er obendrauf.


    GLG GBD

    bin halt bisher mit meinem RSYNC gut klargekommen

    RRTR ist wirklich ein flexibles und vor allem schnelles Backup-Tool, mit dem man vieles machen kann.


    Ein Feature würde ich mir noch zusätzlich wünschen:
    Ein Backup-Job kann derzeit ja "überflüssige Dateien löschen", wenn man dies aktiviert. D.h. dass nach Ausführung des Jobs alle Dateien, die auf dem Quell-NAS gelöscht wurden, auch auf dem Ziel-NAS weg sind. Lässt man einen solchen RRTR-Job nun täglich laufen, sind anschließend leider "versehentlich" auf dem Quell-NAS gelöschte Dateien auch auf dem Ziel-NAS verloren.


    Cool wäre daher eine RRTR-Option, die Dateien auf dem Ziel-NAS erst dann löscht, wenn sie auf dem Quell-NAS schon vor länger als eine zu definierende Zeit gelöscht wurden. Z.B. Dateien älter als 1 Woche.
    Man hätte dann eben noch diese Zeit zur Verfügung, um versehentlich gelöschte Dateien vom Backup zurückzuholen. Neue Dateien würden aber trotzdem täglich gesichert.
    So könnte man sich z.B. ein weiteres wöchentliches Backup auf ein drittes NAS sparen.

    @ GorillaBD: Nur mal zwischendurch gefragt: Ist das normal, daß RRTR beim erstmaligem Starten "ewig" braucht?
    D.h.: ich habe nichts anderes gemacht, als den NAS to NAS Job in RRTR "umgewandelt" bzw. so angepaßt, daß RRTR das gleiche macht wie vorher NAS to NAS (Pfade etc. identisch). Es geht sich hier um ca. 8TB. Seit Freitag ist der RRTR-Job dran, ist mittlerweile bei 60% - mich wundert, daß es so lange dauert, da auf dem Ziel die Daten durch den vorherigen NAS to NAS Job bereits vorhanden sind. NAS to NAS hatte die 8 TB damals innerhalb von ein bis zwei Stunden abgeglichen und die paar geänderten Datein kopiert. ... macht RRTR hier alles neu?

    Definiere bitte mal "ewig braucht".


    Ich habe beim RTRR bereits beide Fälle erlebt: Manchmal erkennt er bestehende Datenbestände in Quelle und Ziel bereits beim ersten Lauf, manchmal erzeugt er in jedem Fall ein neues, "eigenes" Vollbackup. Ein System dahinter konnte ich noch nicht identifizieren.


    Die Option "Dateiinhalte prüfen" hast Du aber bei der Jobdefinition abgeschaltet, oder ?


    GLG GBD

    @ GorillaBD:
    Also der Job hatte jetzt etwas mehr als drei Tage benötigt. Jetzt habe ich es testweise noch mal angestoßen, viertel Stunde hat es gedauert, fertig. Schien so, also ob der einmal alles draufgeschmissen hat bzw. alles überschrieben. Egal, Hauptsache es funzt jetzt in einem wünschenswertem Zeitrahmen. Danke nochmals für den Tip mit RTRR! :thumb:


    Das Häkchen war nicht gesetzt. Aber im Prinzip wäre dieses auch nicht notwenig, da RTRR auch so die verschieden großen Dateien (Quelle->Ziel) bzw. die älteren überschreibt , oder?
    Vermute, daß hier dieses Häkchen nur bewirkt, daß er die Dateien in Quelle und Ziel bit für bit überprüft werden statt nur ältere zu überschreiben, richtig?