DS720+: Bestehende WD RED 3TB durch zwei WD RED 6TB austauschen

[ds4u]

Hallo, ich habe nun einige Beiträge im Forum gelesen und bin nun noch verunsicherter.

Wofür nutze ich meine DS720+?

• Mailserver
• Surveillance-Station (Zwei Kameras)
• Samba-Freigabe für Windows Clients
• WebDAV
• Docker für verschiedene Dienste
• 2 Virtuelle Maschinen (Debian)
• Kalender
• 4 Nutzer

Angeschlossene Speicher/ RAM:

• 18 GB Arbeitsspeicher
• Eine WD RED mit 3TB (ext4) für DSM, Docker und Daten
• Eine "normale" HDD mit 250GB (Btrfs) für virtuelle Maschinen
• USB-Festplatte 4TB (ntfs) für Backup

Da mein SMART-Test defekte Sektoren auf der WD RED anzeigt, möchte diese tauschen. Dazu habe ich mir zwei WD RED Pro mit je 6TB gekauft. Dabei ergeben sich die folgenden Fragen.

1. Ist ein Raid1 für meine Zwecke sinnvoll (Ausfall einer HDD)? Ein Backup auf USB-Platte soll weiterhin vorgenommen werden (keine räumliche Trennung, ich weiß ... ;-)). Die wichtigsten Daten sind zusätzlich mit diversen Clients synchronisiert.
2. Ist ein Tausch der Platten ohne größere Neueinrichtung möglich? Wenn ja, welche Option ist sinnvoller?
   1. Hyper Backup + DSM Konfiguration sichern und nach Umbau wieder zurückspielen
   2. Die HDD für die virt. Maschinen ausbauen, eine neue 6TB rein, Raid mit der alten 3TB einrichten, die alte 3TB durch die zweite 6TB ersetzen
   3. Alte 3TB mit clonezilla auf eine 6TB klonen, anschließend erweitern und die zweite 6TB für Raid einsetzen
3. Sollte ich für die Surveillance-Station auf ext4 anstatt Btrfs setzen (Hintergrund der Frage) ?
4. Kann ich ohne Probleme ein Volume mit ext4 (DSM, Daten, Surveillance) und ein Volume (ca. 300GB) Btrfs für die virt. Maschinen aufsetzen?
5. Könnte ich nach dem Klonen der 3TB auf eine 6TB, den Speicherplatz der 6TB für die Einrichtung weiterer Volumes (ext4 + Btrfs) erweitern?

Ich hoffe man kann mit diesen Infos erstmal was anfangen und meine Unsicherheit etwas beseitigen. ;-)
Vielen Dank fürs Lesen

 

[Stationary]

Die VM würde ich auf eine SSD schieben. Dazu einfach in einen der nicht genutzten SSD Cache slots eine Samsung Evo Plus M.2 einbauen und nicht als Cache, sondern als Volume konfigurieren. Dann die bestehende VM dahin verschieben.

 

[ds4u]

Gute Idee, an den Slot hab ich nicht mehr gedacht.

 

[Stationary]

Die Verwendung der beiden SSD Einschübe als Volume wird nicht offiziell unterstützt, ich habe aber beispielweise in beiden slots eine SSD jeweils als Volume (1TB und 2TB) und damit keine Probleme. Für VMs eigentlich ganz praktisch (bei mir läuft da Ubuntu und vDSM).

 

[ctrlaltdelete]

Mein Plan wäre:
1. Komplettes Backup machen
2. NVME einbauen und VMs verschieben
3. HDD2 (250 GB) rausschmeißen
4. Neue 6 TB einbauen, als neuen Speicherpool SHR einrichten, Volume erstellen und alle Pakete auf dieses neue Volume schieben, siehe hier: https://www.synology-forum.de/threads/apps-von-volume-x-nach-volume-y-verschieben.77896/
5. 3 TB rausschmeißen und die zweite 6 TB als SHR1 erweitern mit der ersten 6 TB

Bei mir läuft SS auf BTRFS ohne Probleme, wenn du bei Schritt 4. den Speicherpool mit Mehr-Volumenfähigkeit anlegst, kannst du auch ein großes BTRFS anlegen und ein kleineres Volumen mit ext4. Stichwort Benutzerdefiniert bei der Erstellung!

 

[ds4u]

Bei mir läuft SS auf BTRFS ohne Probleme, wenn du bei Schritt 4. den Speicherpool mit Mehr-Volumenfähigkeit anlegst, kannst du auch ein großes BTRFS anlegen und ein kleineres Volumen mit ext4. Stichwort Benutzerdefiniert bei der Erstellung!

Danke dir für den Fahrplan. Wenn SS auf Btrfs läuft, auf welchen Verwendungszweck zielt dann das kleinere Volumen mit ext4 ab? Für einen aktuell noch unbekannten Einsatzzweck und das es einfach schon da ist?

 

[ctrlaltdelete]

Laufen tut es, aber es fragmentiert angeblich durch die rotierende Aufzeichnung. Deshalb das kleine ext4 Volume für die SS.

 

[Stationary]

Ich lasse auch zwei Kameras mit btrfs laufen…zum Problem wird das vermutlich erst, wenn Du größere Mengen an Kameras aufzeichnen läßt.

 

[ds4u]

Ich wollte hier nur noch mal den Erfolg zurückmelden und grob mein Vorgehen beschreiben.

• Hyper Backup der Home-Verzeichnisse, Bilder, Musik, Video und aller wichtigen Anwendungen auf USB-Platte
• Sicherung der Konfiguration (Systemsteuerung -> Auktualisieren & Wiederherst. -> Konfigurationssicherung)
• Virtuelle Maschinen aus VMM auf USB-Platte exportiert
• Alte Festplatten raus und eine NVMe M.2 (Samsung 500GB, MZ-V8V500BW) eingebaut sowie 2 WD RED Pro (6TB)
• RAID 1 (ext4) mit den 2 WD RED eingerichtet und wesentliche Apps wie z.B. VMM installiert
• Wiederherstellung der Konfigurationssicherung
• M.2 so eingerichtet, dass sie nicht als Cache, sondern als Volume läuft (siehe Anleitung)
• Virtuelle Maschinen von USB-Platte auf die M.2 importiert
• Hyper Backup wiederhergestellt

Ich habe mich für eine Neueinrichtung entschieden, um ggf. Abweichungen aus DSM x -> DSM 7 nicht mit zu übernehmen. Für meine Zwecke reichen die Synology Backup-Lösungen und ich halte sie für komfortabel. Ein Kopieren der Pakete mittels des o.g. Skripts war demnach nicht notwendig. Bei dem Raid habe ich mich doch für good old ext4 entschieden, da zum einen btrfs nicht essentiell für mich ist und ich irgendwo auch gelesen habe, dass btrfs etwas "beta" sein soll.

Vielen Dank noch mal für die Rückmeldungen

 

[Stationary]

btrfs “etwas beta“??? Das gibt es seit 15 Jahren und es wird kommerziell nicht nur von Synology, sondern auch von Oracle, Fedora Workstation und in Suse Linux eingesetzt. Wie alt war der Artikel, in dem „etwas beta“ stand?

 

[ds4u]

Deshalb auch die Anführungszeichen und meine Anmerkung, dass dies Entscheidung für meine Zwecke irrelevant ist. ;-)

Hier der Artikel, der mich beeinflusst hat. Eine intensive Recherche habe ich für diesen Fall nicht betrieben. ;-)

Relevante Stelle im Artikel

However, Btrfs is not stable. Many Btrfs users complain that the partition gets corrupt after a period – sometimes two months, other times two years – which inherently makes ext4 more reliable than Btrfs.

 

[peterhoffmann]

Die Verwendung der beiden SSD Einschübe als Volume

Das wäre für mich der einzige Grund mal von der DS716+ auf eine DS720+ umzusteigen.

für eine Neueinrichtung entschieden

Das ist bzw. war ein Mehraufwand, ist aber oft der bessere Weg.

 

[Stationary]

Den Artikel finde ich deswegen etwas fragwürdig, weil der Autor (dessen einziger Artikel auf unixmen das ist) über ext4 so ungefähr sagt „in use since more than a decade” (ext4 kam 2008 heraus), weswegen es zuverlässiger ist als btrfs. btrfs kam 2007 heraus…
Auch die Aussage, daß 16TB Festplatten nur sehr schwer zu bekommen seien, läßt mich etwas stutzen. Es gibt dutzendweise Angebote dafür. Entweder ist der Artikel veraltet oder der Verfasser sagen wir mal nicht so sehr qualifiziert.
Die beiden Systeme unterscheiden sich einfach grundlegend in ihrem Ansatz, ext4 betreibt ein journaling, während btrfs ein copy-on-write-System ist, wie auch APFS.
Ich nutze btrfs seit über 6 Jahren auf mehreren Geräten ohne jemals ein Problem gehabt zu haben (klar, das macht keine Statistik, aber für mich persönlich erscheint das System durchaus vertrauenswürdig und zuverlässig). Vermutlich hätte ich auch mit ext4 kein Problem gehabt. Und wieder andere Leute haben sich ebenso vermutlich auch schon ext4 zerschossen…die 100%ige Sicherheit bietet Dir kein Dateisystem, weshalb wir alle brav unsere Backups machen.

 

[Stationary]

Das wäre für mich der einzige Grund

Funktioniert bisher sehr zuverlässig. 3 TB mehr für Daten, die ich nie verändere und bei denen es nicht ganz so schlimm ist, wenn sie mal verloren gingen (ich habe die Filme dahin ausgelagert), im Schadensfall müßte ich sie von extern zurückspielen, da ich die SSDs ohne Ausfallsicherheit betreibe.

 

[peterhoffmann]

ext4 kam 2008 heraus

Wobei man hier nicht unerwähnt lassen sollte, dass ext4 eine lange Geschichte hat (ext, ext1, ext2, ext3) und somit in diesem Bereich 30 Jahre Entwicklung und Erfahrung zur Verfügung stehen.

ext4 betreibt ein journaling

... was abschaltbar ist.

 

[Stationary]

Na ja gut, wenn wir soweit zurückgehen wollen, dann basiert btrfs im Kern auf xfs von Silicon Graphics (oh, wie habe ich die Octane, die Indy und die Indigo im Studium geliebt) das ist um 1994 für Irix entwickelt worden, es verwendet ebenfalls die Baumstruktur, arbeitet aber im Gegensatz zu xfs nicht mit journaling. Letztendlich sind viele der Unix-Dateisysteme auf vergleichbare Grundkonzepte aus der Frühzeit von Unix zurückzuführen.

 

[ctrlaltdelete]

@ds4u Glückwunsch, das alles so gut geklappt hat.