Warum Abraten von Time-Machine Backup vom Mac auf verschlüsselten freigegebenen Ordner auf NAS?

[cehgeh]

Hallo zusammen,

ich habe mir vor kurzem eine DS224+ und eine DS118 gekauft und bin jetzt nach und nach am einrichten.
Ziel: DS224+ bei mir zuhause als zentrale Datenablage aller Daten sowie Time-Machine Backup nur der Systemdateien+Programme eines Macbooks. Die DS118 als räumlich getrenntes reines Backup der Haupt-NAS 224+.

Habe die folgende Frage auch in meinem ersten Thread gestellt LINK, aber da es da um die Kaufberatung ging, denke ich ist es hier sinnvoller aufgehoben.

Wollte grade das Time-Machine Backup für die Systemdateien von meinem Mac einrichten. Aber in dem Synology Artikel dazu (LINK) steht folgendes:

Wir raten davon ab, den Papierkorb zu aktivieren oder verschlüsselte freigegebene Ordner als Time Machine-Ziel zu verwenden.

Da ich meiner ganzen Haupt-NAS nur ein Volumen zugewiesen hatte bei der Ersteinrichtung und dieses verschlüsselt habe, geht das aber jetzt nicht mehr so einfach.
Ein zusätzliches Volume nachträglich einrichten, scheint nicht zu gehen, da ich die volle Speicherkapazität an das bestehende Volume schon vergeben habe und nachträglich nicht ändern kann.
Da würde nur bleiben alle Daten von der NAS zwischensichern, Speicherpool löschen und mit zwei Volumes neu anlegen (eins verschlüsselt für die Daten und eins unverschlüsselt für das TM-Backup), oder?
Da hab ich wenig Lust drauf, aber wenn es langfristig sinnvoll ist, dann mache ich das.

Was für Nachteile hat das denn, wenn ich das TM-Backup doch auf einen freigegebenen Ordner auf dem verschlüsselten Volume erstelle?

Freue mich auf eure Antworten

 

[Thonav]

Kann Dir letztlich nur Synology sagen. Generell verstehe ich aber den ganzen „Verschlüsselungswahn“ nicht. Bei mir ist nur ein Ordner verschlüsselt, der „sensible“ Daten wie Verträge oder Daten von Mietern enthält.
Wozu müsste ich Videos, Musik, Bilder oder verschlüsselte Mac-Backups verschlüsseln?

 

[patrickn]

In meinem Fall, z.B. ein besseres Gefühl, wenn eine Defekte HDD wegen Gewährleistung/Garantie eingeschickt werden muss, was danach mit der HDD passiert kann mir keiner garantieren.

Abgesehen davon ist es einfach Standard heute - jedes Android und Apple Handy ist von Haus aus verschlüsselt.

Und zum Thema: vermutlich Performance Grunde. Wobei ich eine Volumenverschlüsselung auch nicht gleichsetzen würde mit freigegebener Ordner verschlüsseln.

 

[cehgeh]

Wobei ich eine Volumenverschlüsselung auch nicht gleichsetzen würde mit freigegebener Ordner verschlüsseln.

Meinst du damit, dass es okay wäre, wenn mein Volumen verschlüsselt ist, aber der darin befindliche freigegebene Ordner für Time Machine Backup nicht verschlüsselt ist?

Oder: sobald das Volumen verschlüsselt ist, ist doch der freigegebene Ordner darin eh schon verschlüsselt?


Und generell Fazit: würdet ihr die Volumen noch mal neu erstellen und teilen (eins verschlüsselt für Daten, eins unverschlüsselt für TM Backup)?

 

[Monacum]

Synology rät dazu, nicht die Festplatte zu verschlüsseln, sondern die Datenübertragung und das Backup selber, das kann mit der Geschwindigkeit zusammenhängen, weil du auf ein unverschlüsseltes Volumen schneller schreiben kannst als auf ein verschlüsseltes. Und wenn man mal davon ausgeht, dass alle Verschlüsselungen gleich gut sind, ist es auch egal, ob ich die Festplatte oder Partition als solche verschlüssele oder das Backup (die hak-Datei). Bei deinem Beispiel, mit der eingeschickten Festplatte sieht derjenige, der sie ausliest auch nur, dass dort eine verschlüsselte Backup-Datei liegt.

Also quasi genau das Gegenteil von dem, was du oben fragst. Bei mir ist das Volumen verschlüsselt, ich hatte aber vorher keine Verschlüsselung für den Ordner, sondern eben nur für das hbk-File selbst.

 

[cehgeh]

Also wenn das nur mit der Geschwindigkeit zusammenhängt, dann wäre mir das relativ egal.

Ich lasse das jetzt einfach mal so laufen: Also das Volume der NAS verschlüsselt, der freigegebene Ordner für das TM-Backup aber nicht verschlüsselt.
Bis jetzt scheints erstmal zu funktionieren.