Snapshots umziehen

[Elfenhorstm]

Hi Syno cracks

Ich hab ein kleines Problemchen und würde gerne mal eure Meinung wissen.

Auf meiner ersten Syno hab ich ein DATA Verzeichnis mit Snapshots ( ca. 700 ) und Replikation zu der zweiten Syno ( 200 Snaps ). Alles wunderbar und läuft wie geschmiert.

Jetzt hab ich eine neue Syno gekauft und möchte das Verzeichnis mitsamt aller snapshots umziehen. Laut Synology muss man nur ein neues Replikationsziel einstellen und das dann später als Master setzen.

Da gibt es nur ein Problem. Er kopiert nur die Daten aber nicht die snapshots. Anscheinend ist es für Synology ok wenn man 7 Jahre Backup verliert.

Eine Sicherung mit Hyper Backup hat das gleiche Ergebnis. Die aktuellen Daten werden gesichert, Die snapshots nicht.

So jetzt endlich meine Frage: Wie bekomme ich die Daten mitsamt aller snapshots auf die neue Syno?

Von mir aus auch auf der Shell. Ich hoffe jemand kann mir Helfen, da Dr. Google anscheinend das Wochenende frei hat.;-)

Viele Grüsse

Matze

 

[mb01]

Gute Frage, die ich mir auch schon mehrmals gestellt habe und für die ich keine richtige Lösung gefunden habe. Der Workaround ist bei mir das versionierte Hyperbackup parallel zu den Snapshots auf der Syno selbst bzw. in letzter Zeit die Snapshot-Replikation einiger Ordner auf eine andere Syno. Wobei letzteres auch nicht mehr funktionieren dürfte, wenn man was an den Ausgangsdaten verändert. Aber zumindest könnte man dann das alte Replikationsziel stilllegen/beihalten und ein neues Replikationsziel (=Ordner) nutzen.

Im klassischen Sinne darf man Snapshots wohl nicht als Backup sehen, zumal hier ja auch beides - Live-Daten und Snapshots-Backups - auf dem gleichen "Datenträger" liegen. Volumen/Platten putt, Snapshots auch putt.

Eigentlich nicht ganz unlogisch: Snapshots werden ja dadurch erzeugt, dass "alte Daten/-segmente" nicht überschrieben werden und das Dateisystem den Überblick behält, wann welche Daten wie aktuell waren und zusammenhängen. Dieses mit der Zeit gewachsene System mit "versteckten Daten" noch dazu lässt sich wohl nicht so einfach auf ein anderes System transplantieren. Snapshots dienen halt nur dazu, mal eben schnell Veränderungen rückgängig zu machen.

Was bleiben dir für Optionen ... du kannst deine alte Syno oder zumindest den Festplattensatz als Archiv in den Schrank legen, falls du in der Zukunft mal etwas aus den letzten sieben Jahren brauchst. Eine Migration der alten Festplatten in die neue Syno sollte auch die Snapshots erhalten, allerdings musst du die dann auch so weiterverwenden, denn z.B. ein Verschieben eines Volumens auf einen anderen Storagepool killt auch alle Snapshots. Wenn man ganz abenteuerlustig ist, könnte man noch - nach einem Vollbackup der jetzigen Daten - noch verschiedene Wiederherstellungspunkte der Snapshots wiederherstellen und dann jeweils ein Backup von machen ... funktioniert vielleicht(!!!) auch.

 

[Elfenhorstm]

Ich hatte befürchtet das jemand sowas sagt ;-)

Aber deine Argumente sind nicht ganz stimmig glaube ich.

Synology schafft es mit dem Snapshot replication Tool einen Snapshot zu machen und den dann auf die Andere Syno zu kopieren. Warum zum Henker kann ich hier keinen intitial Sync oder sowas machen und alle Snapshots kopieren??

Aus meiner Sicht sind Snapshots in Verbindung mit Snapshot replication besser als jedes Backup. Hyper Backup rennt 4 Stunden für diesen Data Ordner. Snapshot replication nur Sekunden und die Datenmenge die auf die zweite Syno übertragen wird ist lächerlich.

Na ja. Ich hatte halt gehofft das ich einfach zu doof bin und was übersehen hab.

Ich danke dir aber auf jeden Fall schon mal für die Antwort. Falls irgendwer von euch noch Ideen hat oder einen Syno Mitarbeiter in die Finger bekommt um ihm das um die Ohren zu hauen lasst es mich wissen.

Gruss

Matze

 

[Simon88]

Ja so eine Seuche, jetzt habe ich ein zweites NAS um die Daten doppelt zu haben und kann die jahrelangen Snapshots wieder nicht spiegeln.
Welches Genie hat sich das ausgedacht ?

Ich lasse doch nicht beide NAS ständig laufen, damit es nach einem Snapshot diesen auch auf NAS 2 repliziert.
Ich wollte das alle paar Wochen / Monate mal machen.
Geht aber jetzt nur z.B. mit robocopy und den Daten, aber alle Snapshots - ob die Jahre alten oder die künftigen hinzukommenden - kann ich jeweils in die Tonne klopfen. Mein ganzes Archiv für die Katz !

Ich hab gerade echt nen Hals, dass das Profi Hardware / Software sein soll ...
Da hätte ich auch bei der ebenso unfähigen Software HardLinkBackup bleiben können, die sowas nicht schafft.

Was auch dämlich ist, da wählt man per Snapshot Replikation Quelle und Ziel aus und es erstellt im Ziel dann einen neuen gemeinsamen Ordner mit "-1" am Ende und verwendet nicht das was ich ausgewählt hatte.
Ich will aber die Struktur exakt identisch. Alles andere ist doch vollkommen idiotisch.

Fällt NAS 1 aus, will ich doch auf NAS 2 die Daten haben (zumindest Privat vom letzten Monat oder wann halt der letzte sync der NAS war) mit der gesamten Historie aller Snapshots.
Dieses Backup-NAS soll auch bei einem HDD-Ausfall in NAS 1 noch einmal schnell aktualisiert werden mit den geänderten Daten der letzte Tage / Wochen, was ja auf max. ne Stunde (zumindest per Robocopy) erledigt ist.
Dann ist es auch kein Problem wenn mehrere HDDs beim RAID Rebuild ausfallen, weil das mal wieder 2-3 Wochen dauert.

 

[synfor]

Workaround: Mit Robocopy Snapshot für Snapshot auf das neue NAS synchronisieren und vor dem Synchronisieren eines neuen Snapshots einen Snapshot am Ziel erstellen.

Was auch dämlich ist, da wählt man per Snapshot Replikation Quelle und Ziel aus und es erstellt im Ziel dann einen neuen gemeinsamen Ordner mit "-1" am Ende und verwendet nicht das was ich ausgewählt hatte.

Passiert das nicht nur, wenn das Ziel bereits existiert?

 

[Simon88]

Wenn ich mit Robocopy die Snapshots synchronisiere brauche ich ein Vielfaches an Speicherplatz, da das mit den Symlinks dann nicht mehr funktioniert. Oder es funktioniert maximal auf dem gleichen Gerät, ansonsten bricht es die Symlinks. Einen dieser Haken gabs dabei, deswegen kann das auch HardlinkBackup nicht.

Wegen "-1" deine Vermutung war auch meine, kann das aber nicht testweise bestätigen. Dazu müsste ich den gemeinsamen Ordner auflösen und erneut die Snapshot Replikation laufen lassen, wenn es die Snapshots aber nicht kopiert bringt mir der Test nix, außer das es wieder Tage umsonst Daten kopiert.
Hatte jetzt alles identisch angelegt und es per robocopy übertragen, da ich dem vertraue - es überträgt sogar abgebrochene Dateien im zweiten Anlauf komplett inkl. richtigem Datum usw.
Es würde maximal alle künftigen Snapshots auf beiden Geräten anlegen, aber auch nur wenn beide Geräte ständig laufen - was nicht der Plan war - auch aus Sicherheitsgründen. Zudem ist das Backup-NAS auch das alte NAS, läuft das ständig, wirds wohl bald die Grätsche machen und nicht noch einmal 5 Jahre halten.
Möchte nicht noch mehr Stress für die Platten, xx TB kopieren sich nicht so schnell.

 

[synfor]

Wenn der Symlink auf einem anderen Gerät bricht, tut es das auch mit der Snapshotreplikation. So weit ich weiß, kann man in Harslinkbackup einstellen, wie es sich bei Symlinks verhalten soll. Wenn da nicht das passende dabei ist -> Featurerequest an den Autor.

Den Test kann man auch mit einem extra zum Test angelegten gemeinsamen Order machen.

Mit meinem Vorschlag kann man nicht nur zukünftige Snapshots übertragen, sondern auch die alten. Man muss jedoch mit dem ältesten anfangen. Das Ziel muss dazu nicht ständig laufen.

 

[Simon88]

Danke dir, synfor.

Der Autor hat schon seit Mitte 2019 keine Updates mehr veröffentlicht (wenn auch schon seit langem ein neues Release angekündigt) - das warten rentiert sich nicht.
Hardlinkbackup ist zudem sehr viel langsamer als robocopy und das schon bei einem Bruchteil der heutigen Daten. Deswegen wechselte ich dann auf Synology und Snapshots. PC muss dazu auch nicht laufen.
Bei Hardlinkbackup kann schon das Löschen alter Snapshots (außerhalb der Aufbewahrungsregeln) Stunden dauern. Bei Synology nur Sekunden bzw. die Festplatte rödelt dann noch ein paar Minuten hinterher, jedenfalls nicht Stunden.

Ich google gerade zu Robocopy und Symlinks (Parameter usw.), aber soweit ich mich erinnere, gabs da auch einen Haken mit Symlinks.
Das "schöne" ist, man kopiert erst einmal 1-2 Tage und sieht dann eventuell am freien Speicherplatz frühzeitig, ob er nur kopiert oder wirklich Symlinks erstellt.
Ist nicht so einfach, da das Archiv aus Snapshots ja irgendwo das 8-fach der eigentlichen Daten ausmacht. Es änderte sich ja ständig etwas und nur für den gleichen Rest wurden Symlinks erstellt.

Zum Test, hast Recht - aber wenn eben durch die Vorposter schon fix ist, dass es sowieso keine alten Snapshots kopiert, von der Snapshot Replikation nicht vorgesehen - kann ich mir die Zeit sparen, löst dann nicht mein Problem.

Ja, das wäre wichtig, nicht nur künftige, sondern auch die alten Snapshots - da sonst die Daten auf dem Backup-NAS nie synchron wären.
Hab zwar die aktuellen Daten, aber nie die Historie. Hier und da braucht man ja doch mal eine alte Datei.
Wäre nur der Fall, wenn beide ständig laufen und dann wären nur die künftigen Snapshots synchron.
Es erstellt erst auf der Quelle einen Snapshot und repliziert diesen dann "zeitgleich" auf das Ziel.
Geht aber nur, wenn mans zusammen macht.
Wenn immer beide NAS laufen sollen, kann man auch "Synology High Availability" verwenden.

 

[synfor]

Hardlinkbackup ist aus 2 Gründen langsam:

1. Benutzung von Checksummen, lässt sich abschalten
2. Windows wird mit zunehmender Anzahl von Hardlinks pro Datei quälende langsam. Das wirlk nicht nur beim Verlinken, sondern auch beim Löschen alter Backups. Ist das Ziel ein NAS, ist das aber kein Problem.

Du scheinst meinen Workaround immer noch nicht vollständig verstanden zu haben. Du sollst komplett auf die Snapshotreplikation verzichten und die durch eine Synchronisation mit robocopy o. a. ersetzen. Dazu musst auf dem Ziel-NAS komplett von vorne anfangen, wenn du auf die alten Snapshots Wert legst. Du synchronisierst dann vom ältesten existierenden Snapshot an deren Inhalt ins Ziel und erstellst dann im Ziel einen Snapshot und benennst die passend (wichtig besonders für alte Snapshots, da im Ziel das Datum nicht stimmt). Anschließend ist der nächste Snapshot mit der Synchronisation dran. Bei der Vorgehensweise ist man auch nicht darauf angewiesen, das 2. NAS ständig laufen zu lassen.

 

[Simon88]

Habe ich schon verstanden, war evtl. missverständlich, weil ich Absatz für Absatz auf deine Aussagen einging und eben auch Gedankenspiele schreibe, die anderen helfen könnten. Die Snapshot-Replikation hat sich für mich erst einmal erledigt, da mir eine halbe Lösung nichts bringt, weil eben (bis auf Sync-Zeit) immer nur 1 NAS gleichzeitig läuft.

Allerdings wäre eine Mischung aus Robocopy (für das alte) und Snapshot-Replikation (fürs künftige) eine Übergangslösung für alle, die Ihre zwei NAS immer laufen lassen. Wobei es für die eben auch Synology High Availability" gäbe, k.A. ob das was taugt.
Das Alte holt man mit Robocopy zurück und sichert künftig nur noch per Snapshot-Replikation auf das Backup-NAS.
Zumindest der Beschreibung nach, erstellt es zuerst auf der Quelle und dann auf dem Ziel einen Snapshot, sofern man es richtig auswählte.
Steht aber beim Erstellen schon dort, dass das nur für künftige Snapshots gilt.
Bis die alten Snapshots unwichtig sind und gelöscht werden können, könnte manch einer sich damit behelfen. Wahrscheinlich müsste man das aber auch manuell löschen, die Aufbewahrungsregeln werden die alten Snapshots nicht erkennen / berücksichtigten.

Problem an der Sache ist aber, dass soweit ich aus früheren Erlebnissen von vor Jahren weiß, die Symlinks von Robocopy gebrochen würden. Ich weiß nur nicht mehr genau unter welchen Umständen das passierte. Manches geht, manches nicht.
Alleine bei den wichtigen Snapshots ist das aber nicht mal schnell getestet, man sieht das erst nach Tagen (ggf. vergeblichem) Kopieren, ob es genau so viel Speicherplatz verbraucht wie früher oder x-Mal so viel. Bei xx TB Daten eben schwierig, man sieht es den Dateien ja nicht an ob es ein Symlink ist.
Unter Linux wohl schon, aber da müsste ich dann auch erst einmal ein Beispiel finden, um die Bestätigung zu haben.
Ich würde ja die Snapshots nicht einzeln "robocopen" - sondern das ganze Verzeichnis samt aller Unterverzeichnisse, sonst bin ich ja Ende das Jahres noch beschäftigt.

Ich suche wie gesagt noch mit Google wie die Parameter waren und ob ich die Einschränkungen wieder finde, was genau nicht mit robocopy bzgl. Symlinks (=Snapshots) geht.
Damit ich nicht testen muss, um dann nach nem Tag festzustellen, dass alles x-fachen Speicherplatz braucht.
Allerdings, habe ich auf "#snapshot" per Freigabe keine Schreibrechte. K.a. momentan obs per SSH ginge - aber dort habe ich dann ja kein Robocopy.
Klar könnte ich die alten Snapshots sonst wie benennen, Archiv o.ä. - will aber nicht zweigleisig fahren, bis die dann mal nach 3-5 Jahren unwichtig ist.

Aber von vorne beginnen muss ich am Ziel-NAS nicht, was dort noch ist, sind nur per Robocopy kopierte Daten. Die Snapshot-Replikationsversuche habe ich wieder gelöscht. Das schöne an robocopy ist ja, dass es vorhandene Daten übernimmt und ergänzt / bereinigt.
Diese Daten sind ja quasi die Basis für die Snapshot-Verzeichnisse. Alles Unveränderte wird nur von den Snapshots aus verlinkt.
Das Snapshot Verzeichnis ist aber noch nicht übertragen, nur die Daten von denen die Snapshots erzeugt wurden, befinden sich aktuell am Ziel NAS.
Robocopy kann per Parameter das alte Datum für Dateien + Verzeichnisse übernehmen und die Snapshots sind ja auch alle zusätzlich nach Datum benannt, z.B. "GMT-2021.01.28-19.00.03" - das Erstellungsdatum (Attribute) wäre sogar verzichtbar, aber überträgt er eh.

 

[synfor]

Insbesondere die letzten beiden Absätze zeigen mir, dass du den Workaround wohl immer noch nicht vollständig verstanden hast. Es braucht überhaupt keine Schreibrechte auf den Snapshot, geht das eh nicht, weil das dem Sinn der Snapshots widersprechen würde.

Ziel bei der Syncronisation mit robocopy ist immer der gleiche gemeinsame Ordner. Die Quelle jedoch ändert sich ständig. Die Quelle ist immer ein Snapshot und zwar immer nur dessen Inhalt. Daher nützt dir es überhaupt nicht, dass das Verzeichnis den passenden Namen hat, weil das nicht mit synchronisiert wird. Nach jeder Synchronisation mit robocopy wird am Ziel vom als Ziel genutzten gemeinsamen Ordner ein Snapshot angelegt. Dieser muss dann passend benannt werden, damit du den später zeitlich richtig zu ordnen kannst. Das ist insbesondere bei den alten Snapshots wichtig. Wichtig ist dabei auch, die Snapshots mit robocopy in der richtigen Zeitlichen Reihenfolge durchzuführen.

Mit robocopy brauchst/musst du die Snapshots auch nicht sofort zu synchronisieren. Das Ziel muss also nicht ununterbrochen laufen.

 

[Simon88]

Meinst du ...
Es gibt übrigens "Snapshot Replikation, womit die meisten nur Schnappschüsse meinen" und "Snapshot Replikation > Replikation" von dem ich gesprochen habe. Letzteres könnte man zusammen mit Robocopy für den alten Bestand an Snapshots, das "Snapshot Replikation > Replikation" nicht kopiert, in Kombination nutzen. "Snapshot Replikation > Replikation" dann für die neuen Snapshots, "zeitgleich" in einem Prozess erstellt auf Quelle und Ziel.
Worauf ich aus Sicherheitsgründen nie verzichten werde, egal ob Quelle oder Ziel ist, "Snapshot Replikation > Schnappschüsse".

Quelle (Produktiv-NAS) ist das Verzeichnis #snapshot auf NAS 1. Das Verzeichnis ändert sich auch nicht, sondern ist immer das selbe.
Ziel (Backup-NAS) ist natürlich ebenfalls das Verzeichnis #snapshot aber auf NAS 2. Auch dieses Zielverzeichnis ist immer das selbe.
(alle #snapshot sind nur Leserecht)
Will ich Quelle nach Ziel kopieren, mittels robocopy oder was auch immer, brauche ich im Ziel Schreibrechte. In der Quelle natürlich nicht, aber die interessiert mich ja auch nicht.
Alles was innerhalb von Verzeichnis #snapshot ist (mehrere hundert Verzeichnisse à la GMT-2021.01.28-19.00.03) kopiert ein Robocopy-Befehl - ich bin doch nicht irre und lege hunderte Verzeichnisse im Ziel manuell an und starte dann den Robocopy-Befehl in mehreren hundert Varianten (anderen Zielverzeichnissen) erneut. Was im Ziel nicht existiert, legt robocopy selbst an.
Ein Robocopy-Befehl reicht, um hunderte Snapshots zu spiegeln - wären da nicht die Symlinks, die dabei brechen und jeder Snapshot belegt dann 100% Speicherplatz, anstatt nur das zusätzlich an Speicherplatzbedarf was sich zwischen den Snapshots wirklich änderte.

Wie gesagt, habe keine Lust auf ein weiteres Verzeichnis in dem ich wühlen darf, wenn ich alte Dateien von vor x Monaten / Jahren zurück will - z.B. namens #snaphot-archiv zusätzlich zu #snapshot von den Schnappschüssen - vom mehrfachen Speicherplatzbedarf ganz abgesehen.
Sollte ich wider Willen doch etwas wie "#snapshop-archiv" einführen müssen und die von Snapshot erstellten Verzeichnissen-Namen würden mir nicht gefallen, dann würde ich diese auch nicht ein paar hundert Mal manuell erstellen / umbenennen - es soll ja keine Lebensaufgabe werden.
Wenn dann würde ich das im Bulk systematisch mit Total Commander (Mehrfach-Umbenenn-Tool) lösen.

Mir ist klar, dass bei robocopy das Ziel nicht ständig laufen muss.
Da hast du jedoch meinen Ansatz nicht verstanden, alter Kram mit robocopy und Neues wäre als weitere Variante mit zusätzlich der Snapshot-Replikation > Replikation möglich.

Was an allem aber nicht geht ist alles (alte und neue Snapshots zusammen) wie bisher im Verzeichnis #snapshots - da ich darauf Schreibrechte im Ziel bräuchte. Aber nur das wäre eine A-Lösung für mich.

Deine Lösung geht NUR, wenn ich im Ziel KEINE Snapshots (konkret Schnappschüsse) verwende würde, dann gibt es kein vom System angelegtes und gesperrtes Verzeichnis #snapshots
Selbstverständlich müsste ich bei der Variante erst auf dem Quell-NAS nen Snapshot erstellen (lassen) und darf erst dann per robocopy aufs Ziel kopieren. Ansonsten fehlt halt zumindest der aktuellste.
Ich könnte dann sogar ein gleichnamiges Verzeichnis anlegen, das auch beschreibbar wäre, wenn ich KEINE Snapshots im Ziel-NAS verwende.
ABER, ich werde nicht auf Snapshots im Ziel-NAS verzichten, ob manuell oder von Zeit zu Zeit automatisch - da mir sonst irgendein Mist die gesamte Festplatte räumen könnte und ich fange erneut an xx TB übers Netzwerk (also effektiv nur halbe Geschwindigkeit) zu kopieren.
Voll-Duplex läuft ja scheinbar nicht - sonst hätte ich auf Quelle und Ziel nicht jeweils nur bis zu 60 MB Lese bzw. Schreibrate.
Gut der Speicherpool wird aktuell noch erstellt, aber das wird keine 60 MB / Sek. kosten. Bisher hatte ich übers LAN immer vollen Durchsatz, ca. 120 MB / s.

Aber zuletzt dauert das mit robocopy einfach viel zu lange, gerade dann wenn ich das z.B. nur 1x im Monat mache und er dutzende Snapshots zu durchlaufen hat.
Ein von Synology erstellter Snapshot braucht nur Sekunden.
Was nützt es, wenn Synology nicht dazu zu bewegen ist, die alten Snapshots zu übernehmen und nicht anders zu behandeln als die seit der NAS-Neuinstallation erstellten Snapshots - also inkl. Einbeziehung in Löschregeln, nur 1x Speicherplatz usw.


Meine Erinnerungen zu robocopy waren übrigens korrekt:
https://community.spiceworks.com/topic/2241126-robocopy-can-t-copy-symlinks-to-network-paths
Lokal von HDD auf HDD kein Problem, ins LAN aber schon.
Ja, man kann unter Dateidienste > SMB > Erweiterte Einstellungen noch etwas zu Symlinks aktivieren - ob das aber für robocopy reicht, weiß ich nicht.

 

[synfor]

Es gibt übrigens "Snapshot Replikation, womit die meisten nur Schnappschüsse meinen" und "Snapshot Replikation > Replikation" von dem ich gesprochen habe.

Beschwere dich bei Synology für die dämliche Benennung von Programm/Paket.

Quelle (Produktiv-NAS) ist das Verzeichnis #snapshot auf NAS 1. Das Verzeichnis ändert sich auch nicht, sondern ist immer das selbe.
Ziel (Backup-NAS) ist natürlich ebenfalls das Verzeichnis #snapshot aber auf NAS 2. Auch dieses Zielverzeichnis ist immer das selbe.
(alle #snapshot sind nur Leserecht)
Will ich Quelle nach Ziel kopieren, mittels robocopy oder was auch immer, brauche ich im Ziel Schreibrechte. In der Quelle natürlich nicht, aber die interessiert mich ja auch nicht.
Alles was innerhalb von Verzeichnis #snapshot ist (mehrere hundert Verzeichnisse à la GMT-2021.01.28-19.00.03) kopiert ein Robocopy-Befehl - ich bin doch nicht irre und lege hunderte Verzeichnisse im Ziel manuell an und starte dann den Robocopy-Befehl in mehreren hundert Varianten (anderen Zielverzeichnissen) erneut. Was im Ziel nicht existiert, legt robocopy selbst an.
Ein Robocopy-Befehl reicht, um hunderte Snapshots zu spiegeln - wären da nicht die Symlinks, die dabei brechen und jeder Snapshot belegt dann 100% Speicherplatz, anstatt nur das zusätzlich an Speicherplatzbedarf was sich zwischen den Snapshots wirklich änderte.

Der von mir vorgeschlagene Workaround funktioniert ja auch ganz anders. Dein gewünschtes Vorgehen wird eh nicht funktionieren, weil du Snapshots so nicht kopieren kannst. Wenn die Symlinks brechen ist entweder robocopy das falsche Werkzeug oder die Brechen eh weil die Verweise auf anderem NAS nicht mehr gültig sind. Ach ja, die Snapshots verwenden keine Symlinks.

 

[Simon88]

Naja, wie im Link halt beschrieben hat es mit SMB zu tun. Könnte ich das alte NAS direkt lokal einhängen, wie z.B. per USB und gäbe es bei Linux auch etwas wie robocopy (glaube rsync, k.A. ob es Symlinks kann), dann wäre das ein alternativer Weg, der funktionieren müsste und zugleich schneller als halbe LAN-Geschwindigkeit.
An den Verweisen (Symlinks) liegt es nicht, denn von Festplatte zu Festplatte sind es ja auch andere Verweise, solange diese "relativ" adressiert sind und nicht "absolut" oder solange das Programm so schlau ist, diese umzuschreiben ist das auch vollkommen Wurst.

Wie bereits mehrfach gesagt, robocopy und Symlinks (Snapshots sind ja nichts anderes) funktioniert - aber nicht immer bei jeder Umgebung.
Kopiert man > 10 TB checkt man das nicht einmal schnell nach 1 Stunden kopieren ob er kopiert oder verlinkt.
Deshalb informiere ich mich vorher was geht und hocke hier nicht schau 2-3 Tage zu, um dann zu sehen, dass der Speicherplatz 10x so viel ist wie vorher und kann dann auch erst wieder Stunden oder Tage löschen.

Ohne Snapshot wäre es Harakiri, ein Programmfehler oder sonstiges und ein Verzeichnis ist leer und ich fange an xx TB tage- oder wochenlang neu zu kopieren. Sollte daher nachvollziehbar sein, dass es ohne nicht geht. Das ist so wichtig wie ein RAID selbst.

Nervig sind die pauschalen Antworten oft, das ist alles kein Problem geht mit Programm X und testet man es dann steht man da und nichts funktioniert, weil Hyper Backup, Snapshot Replikation > Replikation alles keine alten Snapshots kopiert. Lachhaft diese Funktionalität.
Das sind dann keine 1:1 Kopien. Unter Replikation verstehe ich etwas anderes ...

Jede Beschwerde an Synology ist Zeitverschwendung, weil die hier in Deutschland nicht die Entscheider sind und die selbst kriechen in Taiwan nicht zu Kreuze, damit eine User-Idee umgesetzt wird. Jetzt mit halber Besetzung oder was wegen Corona schon gar nicht.

 

[Simon88]

Workaround: Mit Robocopy Snapshot für Snapshot auf das neue NAS synchronisieren und vor dem Synchronisieren eines neuen Snapshots einen Snapshot am Ziel erstellen.

Das Problem an der Sache ist übrigens noch, auch wenn ich so theoretisch die Snapshot-Struktur fast 1:1 nachbauen könnte (bis auf Benennung der Verzeichnisse unter #snapshots), kennt sich keiner mehr aus, weil alle Snapshots auf dem Backup-NAS dann ein aktuelles Datum hätten. Wie weiß ich also, welcher Snapshot jener von Januar 2019 ist ?
Du schreibst zwar von "umbenennen" - aber man kann nur eine Beschreibung hinzufügen, ändert aber nichts am Verzeichnisnamen unter #snapshots
Wenn ich Dateien rücksichere, dann nie per DiskStation, sondern per #snapshots Verzeichnis.

Wenn überhaupt möglich, müsste man also auch mit dem Datum auf der NAS ebenfalls von vor ca. 3 Jahren nach vorne arbeiten - nicht nur mit robocopy und den einzelnen Snapshots.
Also das Arbeitsdatum der DiskStation in die Vergangenheit ändern und dann nach jedem "robocopy mit anschließendem Snapshot" vor Abarbeitung des nächsten jüngeren Snapshots mit dem Datum in die Zukunft wandern.
Zumindest bei den Dateien / Verzeichnissen selbst hätte man mit dem Datum kein Problem, da Robocopy das jeweilige (alte) Datum automatisch mitkopiert - also normalerweise auch in die Vergangenheit mitmaschiert, nicht nur in die Zukunft.

Ich habe jetzt "nur" 116 Snapshots - doch das wäre trotzdem eine Aufgabe bis zur Rente.
Die etwa 8-10 TB zu kopieren alleine dauert ja schon Tage, wenn man nicht wie bei Robocopy Multithreads laufen lassen kann.
Mit den unzähligen kleinen Dateien, bricht sonst die Übertragsrate zu oft auf wenige MB zusammen.
Bis ich mit allem fertig bin, sind die Snapshots bereits wieder planmäßig zu löschen.
Also wenn dann muss es die Snapshots automatisch spiegeln, aber dann braucht es eben 116-fachen Speicherplatz - ist daher unmöglich.
Ich bleibe dabei, dass Synology da etwas nicht zu Ende gedacht hat ...

Trotzdem das noch als Ergänzung zum Verständnis, falls jemand weniger Daten hat und weniger Snapshots, dass sich das spielen mit Datum rückstellen usw. lohnt ...
Muss zugeben, dass ich hier und da auf die Schnelle zu ungenau gelesen hatte.