DSM 6.x und darunter Kryptischer Text beim Verschlüsseln

[Holtor]

Hallo,

ich verschlüssele gerade nachträglich. Wobei der Komfortgewinn sich in Grenzen hält, man braucht anscheinend noch einmal den Platzbedarf des zu verschlüsselnden Ordners auf dem Volume. Das System scheint im Grunde einen 2. verschlüsselten Ordner zu erstellen, kopiert dann den alten da hinein und löscht den alten. Und so lange das passiert, ist der DSM abgeriegelt. Nicht zu vergleichen etwa mit dem nachträglichen Verschlüsseln bei MacOS. Ein Gewinn könnte aber sein, dass einige der Einstellungen vom alten Ordner übertragen werden. Und genau dazu, nämlich zu Backups des Ordners, gibt es vorab eine Meldung des DSM, die aber leider ebenfalls schon verschlüsselt zu sein scheint, denn ich verstehe gar nichts:

Dieser freigegebene Ordner ist das Sicherungsziel der einzigen Aufgabenversion in Hyper Backup. Alle Daten werden erneut gesichert, nachdem dieser freigegebene Ordner umgewandelt wurde; Gleichzeitig werden weitere Volumes am Sicherungsziel verwendet. Damit dieser freigegebene Ordner nicht mit den verschlüsselten Daten vermischt wird, die bereits am Sicherungtsziel vorhanden sind, empfehlen wir Ihnen, diese freigegebenen Ordner regelmäßig von der Sicherungsquelle der einzigen Aufgebenversion von Hyper Backup zu entfernen. Nachdem dieser freigegebene Ordner umgewandelt wurde, erstellen Sie bitte neue Sicherungsaufgaben und wählen diesen freigegebenen Ordner als Sicherungsquelle.

Ich habe 3 Hyper Backup Jobs (2 verschiedene Arten: rsync und auf eine andere DS), von denen aber keiner den verschlüsselten Ordner als Ziel hat. Vielmehr dient dieser mit anderen Ordnern als Quelle eines Backups. Der erste Satz klingt also völlig sinnfrei.

Und was für "weitere Volumes am Sicherungsziel" sollen verwendet werden? Wie viele denn? Was für "verschlüsselten Daten" sollen "am Sicherungtsziel" bereits vorhanden sein? Ich soll "regelmäßig" irgendwelche Ordner entfernen, wie oft denn?

Vielleicht hat schon einer von euch diesen Text dechiffriert?

Viele Grüße

Holtor

 

[tproko]

Ich glaube, sie wollen dir damit sagen, dass du einfach mal deine Backups während der "Verschlüsselung" deaktivierst.
Sonst kann es hier zu Problemen kommen, wenn der das Backup gerade zieht während er noch verschlüsselt.

Nachdem die Verschlüsselung durch ist, dann mal kontrollieren und ggf. Backup wieder anstoßen bzw. aktivieren.

 

[Holtor]

Vielleicht. Ich hatte die Backups nicht deaktiviert. Der Effekt war, dass ein Backup, bei dem ein Ordner gerade verschlüsselt wurde, nicht gestartet wurde mit der Fehlermeldung "Ziel konnte nicht gefunden werden" (die Ziel-DS war natürlich da). Was bei Backups Quelle und Ziel ist, scheint Geschmacksache zu sein. Jedenfalls hat es auf diese Weise das Backup nicht beschädigt. Die Anweisung "erstellen Sie bitte neue Sicherungsaufgaben" klingt aber nach weitergehenden Forderungen.

Was genau der DSM beim nachträglichen Verschlüsseln tut, ist mir immer noch nicht klar. Am Schluss gibt es einen sehr lange dauernden Prozeß, der "Ordner wird verschoben" betitelt wird. Das dauerte gerade über 4 Stunden bei einem 2TB-Ordner. Da ja alles in einem Volume stattfindet, ist mir ein Rätsel, von wo nach wo da verschoben werden soll. Wäre ja schön, wenn der DSM anbieten würde, temporäre Dateien dabei auf einem anderen Volume unterzubringen.

 

[Holtor]

Jetzt habe ich versuchshalber ein Backup angestossen (rsync (Legacy) auf eine DS212j). Anscheinend wird das bisherige Backup nicht mehr angerührt, sondern daneben ein @Ordner@ mit verschlüsselten Dateien platziert (obwohl der Quell-Ordner eingehängt ist). Merkwürdig ist, dass sich der Prozessor der DS212j dabei halbtot arbeitet, 90% Auslastung durch den Prozess "rsync". Ich weiß nicht, ob er das bei unverschlüsselten Ordnern auch macht; ich verstehe nicht, womit der so beschäftigt ist? Es geht extrem langsam, 10 MB/s.

 

[Fusion]

Wie du vermutet hast wird innerhalb des Volumes einfach ein neuer Ordner erstellt und die Daten dorthin verschoben. Am Ende hat der neue dann wieder den alten Namen.
Deshalb muss auch mindestens 50% Platz übrig sein im Volume.
Wenn man den Ordner gleichzeitig verschlüsselt und auf ein anderes Volume verschiebt, gibt es diese Beschränkung nicht. Dauert aber ebenfalls ewig mit kopieren und neu verschlüsseln.

Eventuell nutzt HB nicht nur die Namen sondern noch unique IDs zu Identifiaktion von Ordnern.
Persönlich hätte ich den Backup Job gelöscht bzw erst mal angehalten, dann die Verschiebe/Verschlüsselungskation gemacht, und danach einen neuen Job erstellt mit der Option "mit vorhandener Aufgabe (also den alten Backupdaten) neu verknüpfen"

 

[Holtor]

Danke für die Erläuterungen Was HyperBackup "Ordner wird verschoben" betitelt, ist dann vermutlich das Duplizieren der ursprünglichen Dateien in den neuen verschlüsselten Ordner. Ich weiß nicht, ob "mit vorhandener Aufgabe neu verknüpfen" etwas gebracht hätte bei filebasiertem (legacy) rsync, weil ja das Backup in einem @Ordner@ entsteht. Allerdings werde ich evtl. das neuere Datenbank-Backup machen (zumindest beim Sichern ist der Geschwindigkeits-, äh, Langsamkeitsunterschied bei mir marginal, 9 MB/s legacy, 8 MB/s Datenbank). Aber auch letzteres wird im Unterschied zu früher verschlüsselt, deswegen würde das "verknüpfen" auch da wohl nicht gehen.

 

[Fusion]

"@Ordner@" ist ja der eigentliche Speicherplatz und "Ordner" ist der unverschlüsselte Mount davon. Was das mit dem Neuverknüpfen zu tun haben soll sehe ich nicht, solange du die key-files und Passwörter noch hast/weißt.
Mein Tipp: Einfach mal ausprobieren mit einem übersichtlichen kleinen Datensatz.
Bei Legacy (Lokale/Remote Datenkopie) sollte es ja noch einfacher sein, weil es gar keine Datenbank und Versionierung gibt und deshalb auch den Punkt "Neuverknüpfung" überhaupt nicht. Wenn hier Quelle oder Ziel verschlüsselt sind, musst du sie selbst einhängen oder über den Schlüsselmanager einhängen lassen. Danach sind nur noch identische Jobeinstellungen wichtig.

 

[Holtor]

Was das mit dem Neuverknüpfen zu tun haben soll sehe ich nicht, solange du die key-files und Passwörter noch hast/weißt.

Ist die Ersparnis dann, das Verknüpfen die alte Datenbank benutzt? Die alten Backup-Dateien kann es doch nicht zeitsparend verwenden, wenn die unverschlüsselt gespeichert waren und das neue Backup verschlüsselt ist. Den @Ordner@, den das legacy-Backup neu entstehen lässt, kann ich ja auch nicht ohne gewissen Aufwand selber mounten. Ziele auf der DS212j einzuhängen würde noch viel länger dauern, die ist zum Verschlüsseln viel zu langsam.

 

[Fusion]

Bei einem legacy Backup gibt es keine Datenbank.
Die Verschlüsselung ist hier auch auf DSM/Ordner Ebene und nicht durch Hyper Backup definiert.

Bei der Erstellung eines Legacy Backup kann ich auch nur eingehängte Ziele auswählen.
Wird das Ziel nach Erstellung des Jobs ausgehängt endet der nächste Job-Aufruf mit einem Fehler.

Für die Quelle ist es egal ob eingehängt oder nicht. Beide Male wird der verschlüsselte Quellordner @Ordner@ an das Ziel kopiert.
Und ja, an der neuen Stelle kannst du den verschlüsselten Ordner zumindest mit Mitteln innerhalb der DSM GUI nicht einhängen.
Einzig die Wiederherstellung geht da noch. Ist der Originalordner von dem die Sicherung gezogen wurde noch vorhanden, wird dieser umbenannt, damit die Rücksicherung wieder den originalen Namen tragen kann.
Andernfalls meckert er über ACL oder sonstige Probleme (habe ich nicht weiter verfolgt).

Das Backup ist wie gesagt nur verschlüsselt, wenn es der Quellordner auch ist.

Edit:
Wenn du also ursprünglich einen unverschlüsselten Quellordner hattest wurde dieser auch unverschlüsselt ans Ziel kopiert.
Mit einer verschlüsselten Quelle geht dies nicht mehr, weil er nur noch die verschlüsselte Form ans Ziel kopiert.
Deshalb wären die Daten am Ende zweimal dort.
Einmal die alten Daten in Ziel/"Ordner" und einmal durch die neue Sicherung/Jop-Lauf als Ziel/"@Ordner@"

In diesem Fall lassen sich also die alten Sicherungen nicht weiter verwenden und werden besser gelöscht und neu übertragen/anglegt.