Beiträge von TheRooster2000

Besten Dank für die Info!
Da in der WD80EFZX, wie in allen WD Reds, die NASware 3.0 läuft, hatte ich das so auch erhofft

Tja, im Review macht das Ding einen guten Eindruck!
Bleibt nur die Frage: Läuft die Platte auch als Raid in 869er QNAPs? Wäre wichtig für meine beiden Kisten.
In den Kompatibilitätslisten von QNAP oder WD taucht sie noch nicht auf. Die WD-Liste bescheinigt max. der 6TB-Platte WD60EFRX die Kompatibilität zur 869er Reihe.

Zur Info gibt's hier ein erstes Review der WD80EFZX

Moin zusammen,

seit kurzem ist die 8TB WD Red von Western Digital erhältlich => WD80EFZX
Testberichte im Netz habe ich noch nicht gefunden. Falls jemand Erfahrungen mit dem Speichermonster haben sollte, würde ich gern hier davon lesen.

Gruß,
Christian

Bitte denkt daran, dass die Übertragungsgeschwindigkeit stark von der Größe der zu kopierenden Dateien abhängt.
Wird eine große Datei übertragen, werden höhere Übertragungsgeschwindigkeiten erreicht, als wenn viele kleine Dateien kopiert werden müssen.

Zwischen meinen beiden 869er QNAPs hat sich die RRTR-Geschwindigkeit mit QTS 4.2.x im Vergleich zu älteren Versionen jedenfalls nicht negativ geändert.

Moin,

dieses Problem habe ich bei meinem 869 Pro mit QTS 4.2.0 b20160119 auch, wenn ich Dateien dieser Größe vom Win7Pro 64bit PC auf das QNAP kopieren/verschieben will! Ist aber auch schon bei früheren QTS 4.1.x Versionen aufgetreten. In QTS 3.x.x Versionen hatte ich das nie.

Bei mir hilft dann meistens, SMB im QNAP-Menü aus- und wieder einzuschalten oder die max. SMB-Version einmal hin- und herzuschalten.
Ich hätte aber auch gern Tipps, ob's dafür eine Lösung zur dauerhaften Beseitigung gibt!

Koubi:
Ohne die Angabe zum Modell Deines QNAP und dem installierten QTS wird Dir kaum jemand weiterhelfen können...

Zitat von "Hilfesuchender"

[...] 2. der Hauptserver, das Original, fährt der denn auch erst runter wenn der Remotejob durch ist oder auch einfach mitten drin bzw muss der länger online bleiben ?? [...]

Mein Haupt-NAS mit den Original-Daten fährt nachts ohnehin erst um 02:30 herunter. Das ist auch für das tägliche Backup ausreichend. Daher musste ich das verzögerte Herunterfahren bei laufendem RRTR-Job dort noch nicht aktivieren.
Ich vermute aber, dass beim NAS mit den Original-Daten, auf dem der RRTR-Job nicht läuft, das verzögerte Herunterfahren nicht funktioniert. Daher muss es wohl länger laufen.

Falls jemand andere Erfahrungen hat und das doch funktioniert, dann bitte hier posten. Interessiert mich auch!
Immerhin taucht die Nachricht vom Start und Ende eines RRTR-Jobs ja mittlerweile auch im Quell-NAS auf, auch wenn dort der Job nicht läuft. Das NAS müsste also die notwendige Info schon haben.

Okay, danke für die Info. Dann brauche ich es nicht nochmal auszuprobieren.

Aus dem selben Grund habe ich übrigens das RRTR-Backup seinerzeit auch umgedreht. Funktioniert problemlos. Abschließend lasse ich mir vom Backup-NAS, auf dem der RRTR-Job läuft, noch eine Statusmal schicken. Dann fährt es herunter. Und zwar wirklich erst dann, wenn das Backup fertig ist. :thumb:

Zitat von "dr_mike"

[...] Job auf dem Backup-NAS mit der Option "entferntes NAS ---> lokal", dann sollte die Zeitplansteuerung funktionieren.

Genau so ist es. Funktioniert bei mir seit über einem Jahr perfekt

Dazu habe ich eine Anmerkung und auch gleich eine Frage:
Seit ich QTS 4.2.0 b0101 auf meinen beiden 869ern installiert habe, erscheinen auch auf dem entfernten NAS im System-Log die Meldungen, dass der RRTR-Job gestartet und erfolgreich abgeschlossen wurde. Hier wurde anscheinend die Signalisierung zum entfernten NAS erweitert. Soweit cool.

Hat damit schon jemand getestet, ob jetzt die Zeitplansteuerung bzw. das verzögerte Herunterfahren nun auch funktioniert, wenn RRTR in der anderen Richtung konfiguriert wurde?
Also RRTR-Job auf dem Haupt-NAS, die Daten per RRTR auf das Backup-NAS schieben und beim Backup-NAS die Option aktivieren "verzögertes Herunterfahren, wenn ein RRTR-Job läuft"? Könnte ja sein, dass das durch die neue Signalisierung jetzt auch so herum funktioniert! Oder fährt das Backup-NAS dann trotz des laufenden RRTR-Jobs herunter?

Gruß,
Christian

Alles klaro. Ich werde mal mein Backup-NAS updaten, das Haupt-NAS auf 4.1.4 weiterlaufen lassen und einen RRTR-Durchlauf starten.

Edit 1:
Blöd! RRTR vom NAS mit QTS 4.1.4 zum NAS mit QTS 4.2.0 funktioniert schonmal nicht
Eingerichtet ist es so, dass das Backup-NAS mit 4.2.0 die Daten vom Haupt-NAS mit 4.1.4 abholt.

Fehlermeldung ist die folgende, was auch immer mir diese sagen will:

[RTRR Job] (Sync) Job Datensicherung failed: Server is terminated by a request!Please check Network Access Protection in server setting page, or Incoming List page.

Edit 2:
Okay, ich musste meinen RRTR-Job neu erstellen. Dann funktionierte er auch wieder. Ich habe den neuen RRTR-Job mit exakt den selben Einstellungen wie beim alten erstellt. Jetzt läuft RRTR wieder wie vorher, obwohl ja nichts anders ist, als beim alten RRTR-Job. Verstehe zwar nicht warum, aber sei's drum. :?

Okay, danke für die vielversprechende Info!

Ist ein RRTR-Job von einem NAS mit QTS 4.1.4 zum anderen NAS mit QTS 4.2.0 möglich?
Ich würde nämlich für ein paar Tage erstmal nur auf einem meiner beiden Kisten die aktuelle 4.2.0 b0101 testen. Das tägliche RRTR-Backup soll natürlich trotzdem laufen...

Hallo zusammen,

sind mit QTS 4.2.0 build 20160101 bei einem RRTR-Job von NAS zu NAS im selben Netzwerk die Geschwindigkeitsprobleme nun auch behoben?
Hat das schon jemand von Euch getestet?

Ich frage lieber nochmal nach, bevor ich von QTS 4.1.4 auf 4.2.0 update... :?

Ja, ist eine offizielle Version.
Steht auch über die deutsche Support-Seite zum Download bereit.

Ist eine neue Final und keine Beta.

Zitat von "nooep"

Gibt es offiziell bei Qnap [...]

...und übrigens nicht nur für die x51er Modelle wie im o.g. Link

Moin,

hat Euch die neue QTS 4.2.0 Build 20160101 bei dem bekannten Problem weitergeholfen?
Hier die Release-Notes zum neuen Release aus dem englischen Forum >>klick<<

Gruß,
Christian

Zitat von "e1l52"

[...] Den Unterschied macht die Option "Replicate ACL and extended attributes" [...]

Genau so ist es.
Wie ich schon in meinem Post oben in Screenshot 2 >>klick<< gezeigt habe, sollte diese Option deaktiviert sein. Diese nennt sich dort "ACL und erweiterte Attribute replizieren".
Dann muss nämlich nicht jedes File angefasst werden und das Backup ist deutlich schneller.

Gruß,
Christian

Hi Reinhold,

also bei gleichem Inhalt der zu sichernden Verzeichnisse auf dem Haupt- und dem Backup-NAS muss ja nichts kopiert werden. Dann ist der Backup-Job nach dem reinen Vergleich der Dateien schon erledigt. Es gibt ja dann quasi nix zu tun. Das dauert bei mir bei ca. 15TB Daten dann gerade mal ein paar Sekunden mit den oben geposteten Einstellungen.

Da muss bei Dir wohl irgendetwas anderes nicht passen. Auch die von Dir genannte Meldung kenne ich nicht.
Ggf. gibt es in QTS 4.2.0 noch ein Problem mit RRTR? Zu QTS 4.2.0 kann ich allerdings nichts sagen, da ich dies nicht installiert habe. Da müsste jemand anderes aus dem Forum weiterhelfen.

Meine Kisten laufen weiterhin mit QTS 4.1.4. Bei Firmware-Versionssprüngen warte ich aus gutem Grund immer erst ein paar Releases ab, bevor ich dann update. Erst muss mit einer neuen Version alles wieder stabil laufen.

Sind das in Deinem Screenshot wirklich die RRTR-Einstellungen? Ich erinnere mich gar nicht mehr daran...
Habe das Backup-NAS gerade wieder heruntergefahren. Vielleicht schaue ich morgen nochmal nach. Aber evtl. kann das ein anderer RRTR-Nutzer ja schon vorher beantworten.

Zitat von "e1l52"

[...] Du schreibst dass Du nur die geänderten Dateien abholen lässt. Müsste dann nicht bei "Filter" "zuletzt geändert x Tage" eingetragen sein ? [...]

Ist bei mir so eingestellt, wie im Screenshot zu sehen. Klappt prima, da hier "0" der Standardwert ist. D.h. dass alle geänderten Dateien beim nächsten Durchlauf kopiert werden, ohne X Tage Verzögerung.

Zitat von "e1l52"

[...] Wie machst Du das runterfahren wenn der Job beendet ist ? [...]

Ich mache das per Zeitplan. Eingestellt ist es so, dass standardmäßig um 00:30 Uhr heruntergefahren wird. Ich habe aber den Haken gesetzt, dass das Herunterfahren verzögert wird, wenn ein RRTR-Job noch nicht abgeschlossen ist.

Edit:
Der Assistent scheint in meinem NAS mit QTS 4.1.4 noch etwas anders auszusehen. Bei mir habe ich es so eingestellt, wie es im Screenshot unten zu sehen ist. In Deinem Screenshot ist noch "Restore" ausgewählt. Ich nehme an, hier wäre stattdessen "Backup" die richtige Wahl.

Zitat von "e1l52"

[...] Was meinst Du mit "inkrementelles Backup" ? Kannst Du mir mal Deine Einstellungen schicken ? [...]

Hallo Reinhold,

inkrementelles Backup heißt nichts weiter als dass nur neue oder geänderte Dateien bei jedem Backup-Durchlauf kopiert werden. Das spart ungemein Zeit
Bei mir fährt das Backup-NAS täglich um 00:00 Uhr hoch, holt sich um 00:10 Uhr per RRTR-Job die Datein vom Haupt-NAS ab, schickt mir anschließend eine Status-Email und fährt automatisch wieder herunter, wenn das Backup abgeschlossen ist.
Die RRTR-Einstellungen findest Du unten.

Gruß,
Christian

Zitat von "e1l52"

[...] NAS2NAS und RTRR mit zeitlich gesteuertem Backup fällt praktisch flach. Ich komme bei der Datenmenge auf eine Laufzeit von 2-3 Tage für den Durchlauf. Damit wäre nur ein wöchentlicher Backup machbar.

Eine Idee wäre jetzt noch die Option RTRR "Real-time" [...] nur noch geänderte Daten übertragen werden. [...]

Moin,

RRTR ist doch auch ohne "Real Time" als inkrementelles Backup konfigurierbar. Dann werden damit auch nur die neuen oder geänderten Dateien kopiert.
So nutze ich es bei ähnlichen Datenmengen ebenfalls als tägliche Backup-Strategie und das funktioniert ganz prima! Die Datenrate beim Backup liegt bei entsprechend großen Dateien bei ca. 110-120 MByte/s. Also so gut wie Vollgas im Gbit-Netzwerk.

Gruß,
Christian