Versioning verbraucht doppelten Speicherplatz

[sol21]

Hallo zusammen

ich habe neu eine DS218j und habe mir als erste mal meine Dateien vom Windows 10 PC mit "Cloud Station Backup" auf die NAS gesichert.

Nun ist mir aufgefallen, dass der doppelte Speicherplatz belegt wurde als die eigentliche Dateigrösse auf dem PC ist. Das heisst, wenn auf dem PC ein Verzeichnis 50GB belegt, hat es auf der NAS 100GB belegt.
Mit testen habe ich rausgefunden das dies nur der Fall ist wenn das "Versioning" im "Cloud Station Server" auf der NAS eingeschaltet ist. Wenn ich dieses ausschalte und Daten das Verzeichnis übertrage, stimmt die belegte Speichergrösse.
Dass die Speicherbelegung mit jeder neuen Version grösser wird ist verständlich, aber dass scheinbar von Anfang an irgend eine versteckte Kopie erstellt wird auch wenn die Datei nie verändert wurde finde ich seltsam. So werden z.B. grosse Foto- und Musiksammlungen selten geändert und trotzdem wird der doppelte Speicherplatz verbraucht?

Ist das normal?

Zudem bringe ich den "gesperrten" Speicherplatz nur wieder frei (nachdem ich einmal mit Versioning übertragen hatte), wenn ich das ganze Verzeichnis lösche und dann alle Dateien neu übertrage (diesmal ohne Versioning). Gibt es da keine Weg den Platz wieder frei zu bekommen? Papierkorb und Versionsdatenbank habe ich bereits gelöscht ohne Erfolg.

Besten Dank

 

[dil88]

Willkommen im Forum!

Ja, das ist normal, wenn man als Filesystem nicht btrfs nutzt, weil die Daten für die Versionierung in eine Datenbank geschrieben werden und grundsätzlich auch einmal ins Filesystem. Wenn das Löschen der Versionsdatenbank den Platz nicht freigibt, wirst Du m.W. nicht um die Neubespielung herum kommen.

 

[sol21]

Danke für die Rückmeldung.
Habe nun die Ordner nochmals gelöscht und nochmals neu angefangen mit ausgeschalteter Versionierung und werde nun in Zukunft auch so arbeiten.

 

[Minotaurus007]

Versionsanzal auf 1 setzen, dann baut er die Datenbank wieder ab und Du brauchst nicht neu alles aufspielen.

 

[TeXniXo]

Ich schätze, das hat er nach knapp zwei Jahren mit Sicherheit so eingestellt.

 

[Minotaurus007]

Ups... ja, da hast Du wahrscheinlich Recht.

 

[TeXniXo]

Na, sag mal, hast wohl eine lange Leitung? 2 Monate nach meinem Beitrag eine Reaktion ...
Bis dann in 2 Monaten wieder

 

[Minotaurus007]

10 x schneller als beim ersten Beitrag... Nee ernst, ich dachte, das kann vielleicht auch anderen nützen. Winke!

 

[cookiedude]

10 x schneller als beim ersten Beitrag... Nee ernst, ich dachte, das kann vielleicht auch anderen nützen. Winke!

Mir zum Beispiel
Ich nutze Cloud Station Backup um meine Lightroom Bibliothek auf der Diskstation zu sichern und habe mich gewundert, warum die auf dem Mac gelöschten Fotos immer noch auf der NAS liegen, bis ich die Versioning-Einstellungen sah und feststellte, dass ich das nicht deaktiviert hatte. Sicherheitshalber hier nochmal nachgeguckt, aber Eure Aussagen bestätigen meinen Ansatz.

VG
André

 

[Minotaurus007]

Schön, dass es geholfen hat!

... Ich frage mich, warum das Versioning, obwohl man nur einige wenige Dateien in mehreren Versionen hält, gleich das gesamte Datenvolumen verdoppelt, und zwar auch dann, wenn man jeweils nur eine Version hält. Ist das wirklich nicht ökonomischer zu lösen? ...

-Mino

 

[Heidi]

Achtung: eine Anmerkung zum Platzverbraucht und der Versionierung (Drivepaket). Sobald die Ordern verschlüsselt sind -egal ob btrfs oder ext4- braucht man den doppelten Platz!"
Grund hierfür ist, dass beim verwenden der Verschlüsselungsfunktion eines Ordners in dem Ordner selbst ein neues Filesystem (vom standrad-verschlüsselungs-linux-typ "CryptFS") angelegt wird. Dieses unterstützt die Versionierung (also das WriteOnCopy) des BTRFS nicht.
Schade.

 

[McFlyHH]

@Heidi: Achte doch bitte mal auf das Datum der Beiträge, auf die du antwortest...

 

[Heidi]

@McFlyHH tue ich. Aber das Internet ist ja zum Glück zeitlos und diesen Beitrag findet noch in 10 Jahren jemand. Und dann hilft es jemandem, egal welcher Abstand zwischen den posts liegt.

Aus diesem Grund sind Antworten à la "hi, ich werde heute abend mal danach schauen" auf langfristige Sicht völlig unsinnig.

Aber danke für den Tadel ...

 

[McFlyHH]

@McFlyHH
...
Aber danke für den Tadel ...

Gern geschehen.
In einem anderen Thread wurdest du (nicht von mir) ja auch schon als Leichenfledderer bezeichnet. Scheint also nicht nur mir so zu gehen.

 

[Heidi]

Zugegeben, amnchmal schreibe ich drauf los, bemerke es dann währenddessen, denke dann aber, ach was solls.

Leichenfledderer? So wird das also bezeichnet. nice. Aber gut zu wissen, dass ich einen Fan habe....

 

[gaspard]

Ist doch besser als das (mouseover nicht verpassen!). @Heidi : weiter so!

 

[Heidi]

@gaspard NICE Comic ! Haha.
@McFlyHH Dann hier noch ein weiterer Eintrag vom leichenfledderer:


Ich hatte heute Kontakt mit dem Syno Support. Die Krücke mit doppelter Speicher via Drive im verschlüsselten gemeinsamen Ordner gibt es nicht mehr in verschlüsselten Volumes!

 

[Thonav]

Das heißt mit der neuesten Version 3.4.0-25724 wurde das geändert?

 

[Heidi]

Hall @Thonav

nein, das ist nicht Drive-Paket-seitig beseitigt worden, sondern bei der Benutzung von verschlüsselten Volumen gilt die Einschränkung nicht, die bei der Verwendung von verschlüsselten Gemeinsamen Ordnern gilt.
Die verschl. Volumens sind in den neuern Syno-Modellen und ab DSM 7 (-.2?) verfügbar.

Hier der genaue Wortlaut des Supports.

Guten Morgen,
unsere Entwickler haben bestätigt, dass diese Einschränkung bei verschlüsselten Volumes nicht vorhanden sind.
Wenn Sie dort die Versionierung aktivieren und das Btrfs Dateisystem verwenden, werden die Btrfs Funktionen für die Versionierung verwendet, sodass kein doppelter Speicherplatz verbraucht wird.

Mit freundlichen Grüßen
Technical Support

 

[Master Chief]

Achtung: eine Anmerkung zum Platzverbraucht und der Versionierung (Drivepaket). Sobald die Ordern verschlüsselt sind -egal ob btrfs oder ext4- braucht man den doppelten Platz!"
Grund hierfür ist, dass beim verwenden der Verschlüsselungsfunktion eines Ordners in dem Ordner selbst ein neues Filesystem (vom standrad-verschlüsselungs-linux-typ "CryptFS") angelegt wird. Dieses unterstützt die Versionierung (also das WriteOnCopy) des BTRFS nicht.
Schade.

Vielen Dank für die mir fehlende Info!