Hallo,
Bin ernsthaft am ueberlegen meine Synology NAS Systeme vom EXT4 Filesystem auf BTRFS umzustellen. Das dieses Unterfangen Zeit und Aufwands maessig nicht ganz trivial ist, wollte ich hier erstmal mal nachfragen, ob das jemand von Euch schonmal gemacht hat und wenn ja, wie Eure Wefahrungen dabei waren. Danke

Aufgrund dieser Darstellung habe ich zwei Volumes eingerichtet. Surveillance Station läuft weiterhin auf Ext4 (HDD) und alles andere auf btrfs mit (SSD). Bei mir war das aber verhältnismäßig einfach, da die Datenmengen gering sind.

Ich nutze hier nur BTRFS und habe nur ne 720+ und zwei HDDs selbst mit Anwendungen wie Surveillance Station habe ich keine Probleme feststellen können. Snapshots sind ein geniale Features, auch für Datensicherheit nicht zu unterschätzen.

Von was für Datenmengen sprechen wir denn?

Genau die Snapshots sind der Hauptgrund weshalb ich den Umstieg und den Aufwand in Betracht ziehe. Gerade im Hinblick auf Ransomware Attacks.

Datenmengen sind ca. 65 TB

Danke Marm,

in Deiner Auflistung finden sich meine Bewegruende zum Wechsel.

Kannst du noch weitere Festplatten hinzufügen und schrittweise die Daten konvertieren? Du kannst prinzipiell ext4 auf btrfs umwandeln. Bloß Synology bietet das nicht an. Bzw. Es ist auch nicht die saubere Lösung.

Hast du von deinen 65TB noch eine 1:1 Sicherung?

BTW: Du solltest mal auf DSM7.2 warten, die haben da einen Schutz für Ransomware eingebaut. Außerdem hoffe ich, dass du deine Daten mit der Synology verschlüsselt hast.

War da nicht was mit RAID-5 und RAID-6, oder wird das inzwischen uneingeschränkt empfohlen?

ja meine Daten sind 3:2:1 gesichert. Insofern kann ich das Haupt NAS plattmachen und als BTRFS aufsetzen. Dennoch ist es ein ziemlicher Aufwand. Aber ich denke es wird sich lohnen.

Das klingt gut, validiere unbedingt nochmal, dass deine Backups funktionieren. Außerdem vielleicht direkt eine Verschlüsselung der Daten vornehmen. Bei Synology ist das ziemlich gut gemacht. 65TB solltest du direkt kopieren, via USB. Aber auch hier würde ich’s in Etappen machen. Das verhindert, dass der Kopiervorgang abbricht und du den ganzen Mist nochmal machen musst. Bevor du deine neuen Daten kopierst vllt. Nochmal einen Smart Test (den langen) aller Festplatten machen.

Bei der Verschlüsselung unbedingt vorher dran denken, falls gewünscht. Das geht hinterher im System nur durch ein Umkopieren durchs System. Das nächste DSM wird auch ganze Volumes verschlüsseln können, nicht nur Shares – aber soweit bekannt auch nicht nachträglich.
BTRFS hat im Syno-Kosmos mit Snapshots und Deduplizierung eigentlich nur Vorteile zu EXT, aber die Performance bei vielen kleinen Dateien könnte einbrechen/enttäuschen. Evtl. vorher mal mit einem kleinen separaten Volume/Share testen.
Es wird auch systembedingt etwas mehr Plattenplatz benötigt, als die reinen Daten ergeben und das Sytem stellt z.b. bei Snapshots-Bereinigungen einiges mit den Platten an …

Guten Morgen,

wir setzen bei allen Kunden-NAS BTRFS-Volumens ein, da die Vorteile überwiegen. Also in meinen Augen…

Falls die Daten auf anderen NAS liegen, kopieren wir die immer über den zweite LAN ( NAS 1 LAN 2: 4.4.4.4 und NAS 2 LAN 2: 4.4.4.3 ). Dann einfach die CIFS-Freigabe direkt auf die IP und es läuft direkt. War mal die Empfehlung eines Synology Support Mitarbeiters als schnellst Lösung.
Falls die zwei Satz-Mini-Schnell-Anleitung zu knapp und damit unverständlich war, hier melden

Und ja, Verschlüsselung ist gut. Bitte immer das Thema der Dateinamen/Pfadlängen im Hinterkopf zu haben. Das nervt manchmal, wenn mal beim Kopieren von un- in verschlüsselte Ordner einzelne Dateien oder Ordner sucht, weil die nicht verschlüsselt werden können und alles abbricht…
Aber auch da gibt es einfach Wege, das im laufenden Betrieb zu realisieren. Bei Fragen, hier melden

Sonniges Wochenende !! C.

Sind die Synologys 1:1 verkabelt oder läuft das dann übers gesamte lan?

FlyingSloth, verzeih mir bitte, wenn ich mich hier mit einer eigenen Frage einklinke: ich verwende derzeit ein DAS-System an einem Mac Pro und überlege mir in Zukunft ein NAS anzuschaffen. Das Dateisystem des NAS ist ja i.d.R. ein Linux-Dateisystem, so wie hier in dieser Diskussion beispielsweise ext4 oder Btrfs. Mich würden Eure Erfahrungen interessieren, wie diese Mac-fremden Dateisysteme mit Mac-eigenen Dateieigenschaften(Locked, Invisible, Bundle Bit, Alias Bit, Custom Icon), und der recht freizügigen Namensgebung von Dateien unter macOS (bei Verwendung von APFS und HFS) umgehen. Die Dateigrößen von HFS+ dagegen machte ja nur früher mit dem älteren Windows-FAT-Dateisystem Probleme. Vielleicht gibt es aber noch andere potentielle Probleme zu beachten. Soweit ich weiss, werden bei Synology TimeMachine-Backups z.B. immer in ein HFS-formatiertes Diskimage durchgeführt, so dass das Dateisystem des NAS insofern keine Rolle spielt. Aber wie läuft das bei einem Nicht-Time-Machine-Backup mit eigener Backup-Software (also auch nicht die vom NAS-Anbieter), das direkt auf das ext4 - oder Btrfs-Dateisystem schreibt? Werden da z.B. Finder-Kommentare, Tags oder die oben erwähnten Dateieigenschaften (z.B. invisible oder locked) gewahrt?

Dazu erlaube ich noch weitere Detailfragen:
@Wellenbrett ..
Was für Software nutzt du denn zum sichern?

Das Dateisystem bleibt dem Mac eigentlich (also fast immer) verborgen. Da du Netzwerkprotokolle wie z.B. NFS, SMB, AFP benutzt. Der MAC schaut also immer ein paar eben drüber auf die Synology. Die Synology verwaltet das Dateisystem und stellt sicher, dass deine Daten nicht korrumpiert werden.

Da du TimeMachine ansprichst, die Synology bietet einen extra Server an, der dir TimeMachine ermöglicht. Analog zur AirPort von Apple. Das funktioniert ziemlich gut. Auch hier spielt das Dateisystem keine Rolle für den Mac.

Auch für Carbon Copy Cloner habe ich ein Sparsebundle auf dem NAS angelegt. Das funktioniert zuverlässig.
Bombich hat diese Methode früher empfohlen und rät mittlerweile davon ab. Mehr dazu: .

Mir ist schon klar, dass das NAS über ein Netzwerkprotokoll angesprochen wird (im Gegensatz zum DAS) und die Dateien dann selbst verwaltet, dennoch hat das NAS ja ein Filesystem und das macht etwas mit den Mac-Dateien, wenn sie nicht in einem Diskimage gekapselt sind. Ich vermute, das NAS verhält sich genau gleich, egal ob ein Mac-Client oder z.B. ein Linux-Client darauf Dateien ablegen will. (Also es erzeugt nicht automatisch ein Diskimage, wenn es einen Mac-Client erkennt um dessen erweiterte Dateiattribute zu retten). Die Backupsoftware die dabei auf dem Mac läuft müßte für diese Überlegungen eigentlich egal sein.

Ah, danke marm! Ich lese mir den verlinkten Bombich-Artikel gerade durch. Also Du arbeitest weiterhin mit den Sparsebundles und das klappt. Mountest Du das Sparsebundle dann manuell vor dem Backup mit CCC im Finder? Hattest Du dann auch mal richtig große Diskimages/Sparsebundles auf dem NAS-Dateisystem liegen, also im TB-Bereich?

Hi, Faultier, Mateteetasse (was fuer ein name) und another macuser, danke duer die wertvollen tips. vor allem die moeglichkeit zwei nas direkt ueber die 2 rj45 buchse zu verbinden ist sehr interessant. kannte ich so nicht.

Hi Wellenbrett, das faultier hat die sache mit dem dateisysteme ganz gut erklaert. der mac sieht nie das native dateiensystem auf dem nas, sondern nur das protokoll welches du am nas freigibst. in meinem LAN ist das SMB.

Das Sparsebundle wird erst durch CCC gemountet. Es ist lediglich als Ziel im Backupplan definiert. Mehr nicht. Selbst das Backup-Volume des NAS, wo das Sparsebunle lagert, ist zuvor nicht gemountet worden. Das passiert alles von alleine in CCC.

Mit Spundle von Mr. Oakley lässt sich die Größe des Sparsebundle bei Bedarf korrigieren. Ich musste das neue Sparsebundle auf dem Mac anlegen (auch mit Spundle) und auf das NAS verschieben.

Nein, die sind alle klein (< 500 GB)

Aber Probleme mit nicht unterstützten Attributen kann es auch geben, wenn Du per SMB zugreifst. Hier mal eine Übersicht zu diversen Clouds und ihre Unterstützung der Mac-Attribute.

Damit gibt es in der Tat oft Probleme, aber die hängen nicht vom Dateisystem des Servers ab, sondern von der Client-Implementation des Netzwerkprotokolls in der gerade laufenden macOS-Version. Es kann z.B. passieren, dass die Kombination "NFS-Protokoll in macOS 13" Finder-Tags nicht unterstützt, während die Kombination "NFS in macOS 12" oder "SMB in macOS 13" das einwandfrei kann.

Schon seit Mac OS X 10.2 emuliert das Betriebssystem wenn notwendig alle fremden Dateiattribute durch das Anlegen versteckter Dateien im sogenannten AppleDouble-Format. Ob das hundertprozentig korrekt funktioniert, ist leider in jeder Version von macOS anders.

Die Namensgebung an sich ist in der Praxis kaum ein Problem, da so gut wie alle Hersteller seit etwa 2001 Unicode mit UTF-8 für die Dateinamen unterstützen. Man muss allerdings auf die Unicode-Normalisierung aufpassen: Einige Protokolle und Hersteller verwenden standardmäßig die Normalisierung des Typs C, andere des Typs D. Das kann meistens durch Parameter auf Client- oder Server-Seite angepasst werden.

Nicht ganz. Alle Time Machine-Versionen von Mac OS X, OS X und macOS arbeiten grundsätzlich mit Disk Images wenn die Sicherung auf einen File Server erfolgt. Das hat mit Synology nichts zu tun, sondern ist z.B. auch bei der Apple Time Capsule so. Wird das Disk Image von macOS 10 angelegt, ist das Format grundsätzlich HFS+, wird es von macOS 11 oder höher angelegt, ist es grundsätzlich APFS.

Danke für die sehr ausführliche Antwort, Marcel! Die Rolle des Netzwerkprotokolls hier ist mir echt neu. Bedeutet das, dass das Netzwerkprotokoll wissen muss in welches Dateisystem letztendlich geschrieben wird? Ich vermute eher, dass es irgendwo eine Art Übergabe der Datei oder des Datenstroms zwischen Netzwerkprotokoll und dem Dateisystem des NAS gibt und somit beide beteiligt sind. Und selbst wenn das Netzprotokoll perfekt ist, unterstützt doch selbst btrfs nicht die oben aufgezählten Mac-eignen Datei-Attribute, oder? Sonst wären doch die Sparsebundle-Notlösungen für Mac-Backups nicht nötig.
Insgesamt erscheint mit die NAS-Situation für Macs nicht wirklich zufriedenstellend.

Nein, genau das Gegenteil: Aus Sicht von macOS ist nur das Protokoll das Dateisystem. Nur es bestimmt, was dort implementiert wird und was nicht und handelt Zweifelsfälle mit dem Server aus. Wie einige hier schon erwähnt haben: Wie der Server das dann abspeichert, ist völlig unsichtbar für das Client-System.

Selbst wenn die Synology APFS könnte, spielt das überhaupt keine Rolle.

Die waren schon deshalb nötig, weil Time Machine mit HFS+ eine spezielle Technik verwendet hat (Hard Links auf Ordner), die in jedem Betriebssystem normalerweise streng verboten sind. Der File Server dürfte das nicht zulassen, wenn er das "wüsste". Selbst zwischen zwei Macs, die beide das gleiche Dateisystem und die gleichen Betriebssystemversionen verwendet werden, ist es zwingend, mit Sparse Bundles zu arbeiten. Dies gilt auch für aktuelle Versionen von Time Machine, die APFS-Schnappschüsse auf Quelle und Ziel benötigen.

Die ist genau so, wie bei jedem anderen Betriebssystem. Da gibt es keine Unterschiede.

Du denkst zu kompliziert. Die Synology spielt den Übersetzer. Von SMB,NFS,AFP zu BTRFS. Marcel hatte dies schon einen Beitrag über mir erläutert. Der Client sieht 0,0 von BTRFS. Es ist für ihn nicht existent. Er sieht nur da ist ein SMB-Share mit der Version 3 und ich finde ihn unter der Adresse xxx.xxx.xxx.

Wenn es für den Client unsichtbar ist, wie der Server abspeichert, ist es dann nicht erst recht wichtig, dass das richtige Dateisystem auf dem NAS gewählt wird?

Marcel Bresink, DasFaultier: Wenn nur das Netzwerkprotokoll entscheidend ist und das Dateisystem auf dem NAS keine Rolle spielt, worin liegt dann der Unterschied bei folgenden beiden Szenarien (der Mac-Client ist jeweils identisch):

1) Mac-Client mit CCC speichert per SMB-Protokoll Dateien auf ein btrfs-Volume auf dem NAS
2) Mac-Client mit CCC speichert per SMB-Protokoll Dateien in ein hfs-formatiertes Sparsebundle, das in einem btrfs-Dateisystem auf dem NAS liegt.

In beiden Fällen ist das Protokoll SMB, dennoch gibt es im Szenario 1 Probleme mit den Mac-eigenen Dateieigenschaften, in Szenario 2 aber nicht.

Genau das passiert ja nicht. Der Mac speichert die Daten deshalb in ein Sparsebundle, weil sich das wie ein lokales, externes Laufwerk verhält (also nicht SMB, sondern HFS+ oder APFS). Dass dieses Sparsebundle in Wirklichkeit auf einem SMB-Server liegt, findet auf einer zweiten Ebene statt. Ein Sparsebundle besteht nur aus einem Ordner mit ganz simplen Dateien. Das ist mit Absicht so gebaut, dass es auf ganz primitiven Dateisystemen liegen kann. Das ist gerade der Trick, um ein echtes, vorhersagbares Dateisystem auf einem ganz beliebigen anderen Dateisystem speichern zu können.

Also: Time Machine speichert auf ein APFS-Laufwerk SMB-Client speichert simple Dateien, die daraus entstehen, auf einen SMB-Server ein fremdes Betriebssystem speichert diese Dateien auf einem unbekannten Dateisystem.

Marcel Bresink: jetzt habe ich es Vielen Dank für die Erklärung!