Snapshot Replikation (Aufgaben aufsetzen auf bestehenden Zielordner)

[TB-UB]

Hallo!

Nach dem Reparieren eines Volumes sind Aufgaben aus Snapshot-Replikation, die dieses lokale Volume als Ziel hatten, verschwunden.

Eine Sicherungsaufgabe mit dem Wizzard anzulegen wäre ja einfach, nur leider legt das dann automatisch einen neuen Zielodner an.
D.h. die zu sichernden Daten werden quasi verdoppelt (Um genau das zu vermeiden liegt imho die Stärke von Snapshot Replikation).

Ich würde gerne die vorhandenen Sicherungsordner wiederverwenden, um die Historie meiner Snapshots nicht zu verlieren, ohne(!) dass ich eine neue Aufgabe anlege, die einen neuen Zielordner anlegt und somit die Sicherungsdaten verdoppelt.

Kann man das über das Terminal hinbekommen, oder sogar mit Board-Mitteln (die ich noch nicht gefunden habe)?

 

[TB-UB]

Update: Laut des freundlichen Synology-Supports, ist ein neue Aufgabe nicht mit einem bestehenden Zielordner verknüpfbar (Datenbankeinträge...)

 

[Simon88]

Danke für die Info, gut, dass ich nach meinem "-1" Erlebnis (vorhandenes Ziel wird trotz Auswahl nicht angenommen, sondern duch neues mit -1 ersetzt) und dem Umstand, dass alte Snapshots nicht repliziert werden (auch mit Hyper Backup nicht) ... mich aufgrund aller Widrigkeiten nicht weiter mit der "Snapshot Replikation > Replikation" beschäftigt habe - es wäre für den Arsch gewesen, reinste Zeitverschwendung.
Es kann doch nicht wahr sein, was ich hier lese - eine völlig sinnlose Software.
Also in Punkto Snapshots läuft es bei Synology noch sehr rudimentär, die Liste wird immer länger.

Angefangen hatte alles einmal damit, dass ein "Defrag" die Snapshot-Verlinkungen bricht und mit jedem Defrag-Vorgang mehr Speicherplatz verbraucht wird - also selbst wenn man es mehrmals bei unveränderten Daten hintereinander macht !
Siehe z.B. https://unix.stackexchange.com/ques...agment-subvolume-which-has-readonly-snapshots

So, und jetzt kommt täglich neuer Mist hinzu. Das kann ja heiter werden - alles sehr dilettantisch ... für eine ach so hoch gelobte Software.
Je tiefer man einsteigt, umso mehr Brechreiz bekommt man, was alles NICHT geht.

 

[TB-UB]

Ja, das mit ""Snapshot Replikation > Replikation" finde ich schon auch grenzwertig. Ich verwende das nur weil ich es selber mit rsync noch nicht hinbekomen habe (über DS-Grenzen hinweg).
Aktuell warte ich auf eine "die erste" Replikation eines Ordners, der eigentlich nur 1TB hat, schon seit ca. einer Woche und ich vermute es dauert noch ein paar Tage. Ich glaube das liegt daran, weil sich in dem Ordner ca 110 Versionsordner liegen, die ich mit cp -al angelegt habe...
Von diesen Ordnern weiß ich auch noch nicht, ob ich die überhaupt mit rsync übertragen kann, ohne die Links aufzubrechen... werde ich aber mal versuchen, um von Replication weg zu kommen.

Dass die Links bei "Defrag" aufgebrochen werden, ergibt sich vermutlich aus der Art und Weise, wie die Daten bei BtrFS gespeichert werden. Die einzelnen Datenblöcke (oder wie die auch heißen) wissen glaube ich nur, wie oft sie irgendwo verwendet werden, kennen aber diese Verwender nicht. Wenn nun ein Defrag diesen Datenblock woanders hinschieben will, kann es nur den Zähler des Blocks um 1 reduzieren und einen neuen Block anlegen, aber eben nur für die Datei, die es gerade bearbeitet, die anderen Dateien können nicht identifiziert werden. ... meine laienhafte Vermutung.

 

[Simon88]

Ohje, noch einmal Danke für die Info.
ca. 1 Woche für 1 TB und noch nicht fertig, da brauche ich dann ja gar nicht erst anfangen. Auch wenn ggf. nur der erste Durchgang so langsam ist.
Aber die Wiederherstellung, schrieben andere, dauert auch immens lange und bricht tlw. sogar mit Skript-Fehler an (scheinbar Laufzeitüberschreitung) - deshalb will ich unbedingt Programme die nicht mit Datenbanken arbeiten, sondern direkt am Filesystem.

Selbst mit Robocopy und Multithreads, um die Datenrate auszureizen, kopiere ich bei mittleren xx TB wahrscheinlich 1-2 Wochen wenns so weitergeht.
Blöd ist halt, dass der Windows-PC dann ebenso lange durchlaufen muss.
Aber robocopy ist echt toll, weil man bei 50% eine Datei abbrechen kann (wegen Reboot oder sonstigem) und beim nächsten Anlauf macht er dort weiter - ohne das etwas Schrott ist. Das ganze dauert auch nur Sekunden bis wenige Minuten bis es weiß wo es weitergeht.
Das Problem ist ja immer, dass die Programme eine volle Datei anlegen (also kompletter Speicherplatz) und diese dann "füllen". Bricht man ab, ist oft die scheinbar komplette Datei vorhanden und man überspringt diese beim nächsten Kopier-Anlauf, nur der Inhalt ist Schrott / unvollständig.
Andere Programme löschen unvollständige Dateien wenigstens, was zwar Zeitverlust ist, aber keine fehlerhaften Dateien.
Daher beruhigt robocopy, denn ein binärer Vergleich mit z.B. Beyond Compare würde ebenso Wochen dauern, ob Quelle und Ziel am Ende 100% identisch ist.
Rsync hatte ich schon mal im Einsatz, aber nicht so die Erfahrung damit.
Jetzt ist guter Rat zu Alternativen teuer - wenn ich was finde, behalte ich den Thread im Auge.

Wenn die Defrag wenigstens im DSM sperren würde, sobald btrfs oder Snapshots vorliegen, damit mans nicht starten kann.
Habe da auch etwas in Erinnerung, dass es mit einem neuen Kernel behoben wäre, aber da soll Synology sehr weit hinterher hinken.
Aber so merkte ich das erst, als ich Erklärungen für den immensen Mehrverbrauch von mehrere hunderten GB suchte.
Mir blieb dann als es zeitlich passte nur übrig, die Snapshots zu löschen und dann war der Speicherplatz auch wieder großteils (aber warum auch immer nicht komplett) wieder freigegeben.

Beim Aufbau des neuen NAS rühre ich Defrag nun gar nicht mehr an.

 

[TB-UB]

Kommt darauf an, was du machen möchtest.

Defrag ist genau das was ich momentan auf meiner DS einzusetzen versuche, weil ich mir etwas Geschwindigkeit verspreche. Deshalb verschiebe ich gerade meine Produktivordner auf ein anderes Volume, wo es dann halt keine snapshots gibt, die aufgebrochen werden können.
Sicherungen dieser Produktivordner mach ich mit rsync und cp -al und mache ein diff. Diese schiebe ich mit Replication auf eine 2te DS. Mehr oder weniger ausführlich habe ich das hier beschrieben: meine Startegie

Zu robocopy: Damit das so schnell ist, arbeitet das mit Hashes glaube ich. Ich meine gelesen zu haben, dass dies dazu führt, dass die übertragenen/geschriebenen Daten nicht unbedingt 100%ig richtig sein müssen. Für mich wäre ein Binärvergleich auch da unerläßlich.

Bei meinen Ansprüchen glaube ich werde ich weiter mit rsync+diff mein Glück versuchen. Damit ich nur im absolut ungünstigsten Fall auf ein Backup zurückgreifen müsste, sind alle Volumes RAID1 mit tlw 3 oder 4 Platten.

Wenns ums schnelle Wiederherstellen geht, ist Snapshot-Replication glaube ich ganz gut, weil man da scheinbar den replizierten Ordner als Ersatz für einen verlorenen Quellordner bereitstellen können soll (wie das geht, erschloss sich für mich bisher nicht).

Evtl. auch interessant, sharesync oder BackupPC irgendwo hier:
https://www.synology-forum.de/threa...nisierung-zwischen-2-nas-zeitgesteuert.112179
oder
https://www.synology-forum.de/threa...schneller-als-hyper-backup-gibt-es-das.112368

 

[TB-UB]

Was mir eben noch einfällt: Wenns nur drum geht auf die Schnelle ein Backup zu machen... da gibt es eine rabiate Methode...
DS auschalten, eine der Platten des RAID1 entfernen, hochfahren, neu Platte rein und reparieren lassen.
Das würde ich aber nur machen, bei einem BtrFS-RAID1 mit mindestens 3 Platten (weil beim Reparieren eine weitere Platte sterben kann; mir selbst passiert!).
Und sollten die Daten der Platte mal benötigt werden diese nur einzeln (und irgendwo steht, nicht in Slot1) in einer DS starten, oder eben mit einem Ubuntu-Rechner auslesen.
Durch diverse Vergrößerungen meiner RAID1 mit neuen größeren Platten, habe ich auf diese Weise bereits mehrere Platten voll mit dem alten Zeug ; o )

Das Reparieren dauert zwar ein wenig, aber nicht so lange wie ander Backup-Methoden; und es läuft auf der NAS nebenher während man ungestört weiterarbeiten kann.

 

[Simon88]

Ich will deinen Thread nicht zu sehr in verschiedene Richtungen abdriften lassen, aber meine Problemstellung ist, habe:

NAS 1 (fürs produktive)
NAS 2 (das alte NAS in Teilzeit-Rente, als eigentlich 100% Spiegel zu NAS 1) geplant: Die Daten dort müssen nicht top aktuell sein, aber wenn ich alle paar Wochen oder 1x im Monat von NAS 1 spiegele soll es halt schon komplett sein. Wenn u.a. alle Snapshots verloren gehen, dann hilft mir das für den Worstcase nur wenig. Gibt ja eine Liste, was Snapshot Replikation bzw. Hyper Backup alles nicht sichert in den Synology Hilfeseiten und das ist erstaunlich viel.
Das ganze Archiv der letzten Jahre ist dann weg, vermisse ich eine Datei von früher, da aus Versehen gelöscht, dann mit den Snapshots weg.
Wenn so ein Sync 1-2 Wochen dauert, kann mans natürlich auch vergessen - dann kann ich gleiche beide NAS immer laufen lassen.
Auch hier der Vorteil von robocopy, dass es alles löscht was zu viel ist und den Rest ergänzt und ohne Datenbankenstände zu vergleichen und nur Verzeichnisse abzugleichen, so viel schneller. Es entfällt einfach viel Ballast.
Ich prüfe das halt immer anfangs mit Beyond Compare, aber nicht immer im Binärvergleich, weils einfach utopisch lange dauert. Macht man das 10x sind die Festplatten hin. Vergleiche mal xx GB große Dateien, was das an Leistung braucht und reichen Stunden nicht.
Mit diff kenne ich mich nicht so gut aus und bequem ist halt etwas anderes, wie bei Beyond Compare - da es im Endeffekt auch wie ein Dateimanager arbeitet und man fehlende Dateien hin und her schieben kann.

Bisher wüsste ich mir nur mit robocopy zu behelfen, aber ohne subvolumes oder wie auch immer nun die Snapshots funktionieren, wird das ein Vielfaches an Speicherplatz brauchen, die Snapshots mit robocopy zu spiegeln.
Es ist ja schon jetzt so, dass die Snapshots bei 2 TB Daten ca. 10 TB an Speicherplatz belegen. Sicherlich, ich könnte die Snapshots reduzieren (dürften so ca. 150 in etwa 3 Jahren sein), aber solange ich den Platz nicht brauche - will ich das nicht.
Meine Aufbewahrungsregeln bei den wichtigsten Daten ist:
60 tägliche, 52 wöchentliche, 12 monatliche und 3 jährliche

Momentan kopiere ich die Daten vom alten NAS auf das Neue, sobald beim Neuen alles verlässlich läuft, das ganze umgekehrt.
Also das alte NAS platt machen, da ich das SHR-2 auflösen möchte / muss (Speicherplatz) und nur noch SHR-1 - alles an Platten rein, was übrig ist und anschließend die Daten vom neuen NAS aus backupen. Die Snapshots kann ich mir bis dato aber abschminken.
Wenn überhaupt kann ich sowas wie ein #snapshot-archiv kopieren, was dann nicht zusammen mit #snapshot läuft, also nicht systemtechnisch verwaltet und auch nicht automatisch nach Regeln gelöscht wird. Erst nach 3 Jahren oder so, könnte ich das Archiv dann löschen. Löst dann aber nur das Altbestand-Problem, nicht aber was mit den künftigen erstellten Snapshots wird.
Alles ziemlich nervig und wegem dem x-fachen Speicherplatzbedarf ohne Symlinks oder dergleichen auch nicht umsetzbar.
Die reinen Daten (ohne Snapshots) kopiere ich entweder wieder mit robocopy oder wenn ich bis dahin etwas anderes finde.
Aber es müsste etwas ohne verwaltenden Datenbank sein, da es sonst - wie bei dir - immens lange dauert.

Festplatte ziehen geht hier nicht, habe kein RAID 1.
Sind 8 Festplatten als SHR-1, auch hier die einzige Möglichkeiten um nicht massenhaft Speicherplatz zu verschwenden und diverse Speicherpools je nach Festplattengröße zu brauchen.


Zu Defrag, mir gehts ja auch so - es lief monatelang ohne Defrag und nach dem Defrag war es gefühlt leiser - als müsste die Festplatte nicht so viel hin und her.
Was mir missfällt ist, dass die Empfehlung hier wieder widersprüchlich sind.
Einerseits muss es einen Grund geben, warum NUR bei btrfs überhaupt ein Defrag möglich ist - also muss es ja wirklich fragmentieren.

Aber immerhin haben die jetzt einen Warnhinweis in Verbindung mit Snapshots unter:
https://www.synology.com/de-de/know...rageManager/volume_filesystem_defragmentation
Hier aber wiederum sagt man, es wäre kein Defrag nötig:
https://www.synology.com/de-de/know...e_internal_hard_drive_of_the_Synology_Product
Entweder bezieht sich das nur auf ext4 - oder der Artikel ist so alt, dass es da noch kein btrfs (bei Synology) gab.