HyperBackup vs. Shared Folder Sync zwischen OnSite und OffSite Diskstation

[sugarDaddy]

Hallo,

eine primäre produktiv-Diskstation wird einmal die Nacht per HyperBackup komplett gesichert. D.h. einmal auf eine angeschlossene externe Festplatte. Und einmal auf eine baugleiche sekundär-Diskstation die off-site ist und per VPN zugeschaltet. Es werden alle Anwendungseinstellungen gesichert. Aber auch sämtliche shared-folders (bis auf eine Ausnahme, dazu später mehr).

Ich gehe so davon aus, bei einem Totalausfall der primären Diskstation, diese durch die sekundäre ersetzen zu können, welche ich aus dem auf ihr liegenden Backup wiederherstelle (plus Nacharbeit). Bei ca. 500 GB wiederherzustellenden Daten dauert das vielleicht 1-2 Stunden, aber ist dann nahezu ready to go. Der einzige Zweck der sekundären Diskstation sind Backup und Notfall-Ersatz der primären.

Nun verfügt die primäre Diskstation anders als die sekundäre über einen weiteren Pool aus 2x4TB HDDs auf denen vor allem Fotos liegen. Der Plan ist nun, auch die sekundäre Diskstation mit ebenfalls 2x4TB auszustatten und auch diese Daten zu backupen.

Nun müsste ich sicher einen zweiten HyperBackup-Task anlegen, welcher nur die 2x4TB sichert, und zwar auf die 2x4TB der sekundären DS. Alleine weil die Größe des Backups den Platz des primären Pools sprengen würde. Aber irgendwie gefällt mir das nicht. Nicht zuletzt weil das Entpacken das Backups doch ziemlich dauert.


Nun bin ich auf Shared Folder Sync gestoßen: https://kb.synology.com/en-sg/DSM/h...ication_backupserv_sharedfoldersync?version=7

Ich könnte das doch dafür nutzen die 2x4TB damit nächtlich zu synchronisieren? Mit dem Vorteil im Ernstfall auf der sekundären Diskstation nicht erst entpacken zu müssen. Und um mich vor Ransomware oder dem Kapern der primären Diskstation zu schützen, könnte ich beiderseits tägliche Snapshots für die 2x4TB anlegen.


Wenn ich es weiter spinne, könnte ich aus dem HyperBackup auch sämtliche shared-folders heraus nehmen und es auf die Anwendungen und deren Settings beschränken. Die shared-folders dann per Shared Folder Sync synchronisieren. Dann könnte ich auch dort auf der sekundären Diskstation tägliche Snapshots machen.


Vorteile:

• Snapshots auf sekundärer Diskstation möglich (je nach Retention Policy auch im .hbk, jedoch wären die Snapshots ausserhalb der Reichtweite eines ggf. maliziösen HyperBackups/Zugriffs von der primären Diskstation)
• keine Entpack-Zeiten
• ...
• habt ihr noch mehr?

Nachteile:

• Statt einer .hbk in der alles liegt, besteht die Sicherung des Gesamtsystems aus einer kleineren .hbk und synchronen shared-folders
• ...
• habt ihr noch mehr?

Meine Frage ist letzlich, habe ich Nachteile übersehen? Ratet ihr mir dazu, bzw. davon ab?

Vielen Dank

 

[sugarDaddy]

Ok, ich habe mir das mal angeschaut. Shared Folder Sync setzt voraus, dass der User auf der Ziel-DS der "administrators"-Gruppe angehört. Das gefällt mir nicht wirklich. Immerhin sind die credentials auf der Quell-DS ja hinterlegt. Ob irgendwie "auslesbar" weiß ich nicht.

 

[sugarDaddy]

Aber ich kann Snapshots von dem replizierten folder auf dem Ziel-NAS machen.

Und ich gehe davon aus, dass ich das folder auf dem Ziel-NAS von der Synchronisation trennen, und dann mit den Daten arbeiten kann. Das setzt voraus die "Enable advanced share permissions" vom Folder wieder wegzunehmen. Das test ich nochmal.

Soweit sorge ich mich eigentlich nur noch darum, dass der User auf dem Ziel-NAS ein administrator sein muss.

 

[sugarDaddy]

Auch hier nochmal ein Update: Ich habe mittlerweile rausgefunden, wie bei SnapshotReplication ein Switchover bzw. ein Failover funktioniert. Ich kann also einfach mein local folder per SnapshotReplication replizieren, und jederzeit das destination-folder per Failover aus dem Verbund ausklinken und writable machen.

Insofern hat sich der Nachbau (folder+snapshots < rsync > folder+snapshots) per Shared Folder Sync erledigt.

Ferner umgehe ich die Speicher- und Entpack-Problematik die eine .hbk mit sich brächte.

 

[wace]

Die Replikation nutze ich jetzt auch. Der User der sich der sich an meiner 2. DS einloggt muss jedoch Admin sein. Daher habe ich diesem User auf der 2. DS alle Rechte auf die Shared Folders entzogenund auch auf alle Anwendungen. Natürlich auch SSH disabled.

Dann habe ich mal ein Replikation auf der 1. DS gelöscht und soehe da, der Shared Folder auf der 2. DS bleibt bestehen. Das ist was ich gewollt habe. So kann jemand der die 1. DS kapert nicht die Daten auf der 2. DS löschen.

Habe ich da noch etwas übersehen?

 

[Thonav]

Einfacher Reset und der admin wird wieder aktiviert - er kann sich dann ohne PW auf Deine 1. DS einloggen und einen neuen Administrator anlegen... Was ist dann?

 

[sugarDaddy]

Du hast auf der DS 1. einen SnapShot gelöscht, den Replication Task oder das ganze shared-folder?

Wenn Du den Task selbst löscht, entkoppelt er ja die "Kopie" des shared-folders auf der DS 2 vom Original der DS 1. so dass erstere schreibbar wird. Wäre ich bösartig würde ich versuchen in den Replication Task Einstellungen der DS 1. die Retention auf "1 Snapshot vorhalten" umstellen, und dann einen Snapshot mit korrumpierten Daten machen. In der Hoffnung auf Deiner DS 2. würde nun nur noch 1 SnapShot liegen, mit Müll drin.

 

[wace]

Einfacher Reset und der admin wird wieder aktiviert - er kann sich dann ohne PW auf Deine 1. DS einloggen und einen neuen Administrator anlegen... Was ist dann?

Dafür muss der Angreifer aber physikalischen Zugriff auf die 1. DS haben.
Auf die 2. kommt er dann aber immer nicht.

 

[Thonav]

Irgendwie verstehe ich es nicht - diese Sicherheit habe ich schon wenn ich die Geräte räumlich trenne.

 

[sugarDaddy]

@Thonav wenn ich @wace richtig verstanden habe, wäre die DS 1 natürlich gekapert (Knopf oder sonstwie). Aber auf der DS 2. liegt noch eine Replication auf die man, selbst wenn man die credentials des dort dafür angelegten administrators hat, nur lesend (nicht löschend/überschreibend? @wace) oder SnapShots hinzufügend Zugriff hat.

 

[wace]

Du hast auf der DS 1. einen SnapShot gelöscht, den Replication Task oder das ganze shared-folder?

Wenn Du den Task selbst löscht, entkoppelt er ja die "Kopie" des shared-folders auf der DS 2 vom Original der DS 1. so dass erstere schreibbar wird. Wäre ich bösartig würde ich versuchen in den Replication Task Einstellungen der DS 1. die Retention auf "1 Snapshot vorhalten" umstellen, und dann einen Snapshot mit korrumpierten Daten machen. In der Hoffnung auf Deiner DS 2. würde nun nur noch 1 SnapShot liegen, mit Müll drin.

Ja ich habe die Replikation auf der 1.DS gelöscht (entkoppelt).
Die Retention kann man nach dem initialen Erstellen nur noch auf der 2.DS einstellen / verändern. Von daher wäre dieser Weg ( Versionierung auf 1 stellen und verschlüsselte Files syncen) nicht direkt erfolgreich (nach ein paar Monaten evtl. )