Vorgehen Umzug von HDDs auf SSDs

[mstr_Q]

Hallo zusammen,

ich betreibe meine DS416play mit 4x 14 TB HDDs in einem SHR2. (Belegt sind lt. Anzeige 12,55 von 24,4 TB). Ich habe heute morgen 3x 8TB SSDs (Samsung QVO) gekauft (zeitnah kommt eine vierte hinzu) und beabsichtige die HDDs mit Diesen in einer SHR-Konfiguration zu ersetzen und hätte gerne Feedback, ob das so funktioniert, wie ich es plane oder ob ich was übersehe. Da ich von SHR2 auf SHR zurück gehen möchte und die SSds eh vuiel keliner sind, kann ich leider nicht einfach HDD für HDD ersetzen.

Mein Plan:
1) Aktualisieren des Komplettbackups (Hyperbackup) auf eine externe 16er HDD.
2) Ziehen einer der 14er HDDs im NAS (SHR2 degradet)
3) Manuelle Kopie oder weitere HyperBackup-Kopie aller Daten auf diese 14er (was ist besser?).
4) Shutdown des NAS, Ausbau der restlichen drei HDDs. Einbauposition wird festgehalten.
5) SSDs einsetzen, Konfigurationsbackup einspielen und Volume im SHR einrichten.
6) Daten wiederherstellen.


- Klappt das so?
- Zu 4): Sehe ich das richtig, dass ich im Zweifel die drei verbliebenen HDDS mit dem degradierten SHR2 wieder einsetzen und weiterbetreiben könnte?

Danke vorab.

 

[ctrlaltdelete]

Ja, das sollte so funktionieren. Achte bei Hyperbackup darauf möglichst alle Pakete zu sichern und falls du Docker verwendest da auch manuell sichern.

 

[mstr_Q]

Ich habe jetzt noch etwas anderes versucht:
Habe die vierte HDD aus dem SHR2 entfernt und als neuen Speicherpool mit neuem Volume (auch btrfs) hinzugefügt. Dann habe ich einen neuen SharedFolder (datenkopie) angelegt und die Daten via Filestation kopieren lassen. Seltsamerweise wird die Belegung auf dem neuen Volume weiter als praktisch null angezeigt. Läuft die Deduplizierung auch poolübergreifend? Wie kann ich das umgehen?
Ich brauche die Daten ja physisch vorliegend, wenn ich Pool1 dann entferne.

 

[maxblank]

Richtigen Pool ausgewählt?
Bitte Screenshots vom Speichermanager posten.

Speicher-Analysator könnte dir auch helfen:
https://www.synology.com/de-de/dsm/packages/StorageAnalyzer

 

[mstr_Q]

Danke, hatte gestern spät abends wohl den falschen Pool ausgewählt. Wie peinlich
Ordner kopiert gerade.

Aber nun hatte ich einen Gedanken: Gibt es denn keinen Weg, alle Dienste/Docker/etc. temporär auf Volume 2 umzubiegen, so dass das NAS weiterlaufen kann? Denn das OS usw. müsste ja nun auch auf der HDD4, welche Vollume 2 beherbert laufen.
Dann Volume 1 mit den SSDs neu erstellen und wieder zurückbiegen? Theoretisch muss das doch gehen.

 

[maxblank]

Es gibt dazu hier ein Skript…

 

[w00dcu11er]

temporär auf Volume 2 umzubiegen

Umbiegen in dem Sinne nicht, aber verschieben in etwa so:
https://www.synology-forum.de/threads/alle-daten-von-volume-verschieben.77822/

 

[ctrlaltdelete]

https://www.synology-forum.de/threads/apps-von-volume-x-nach-volume-y-verschieben.77896/

 

[mstr_Q]

Ich habe den Umzug nun abgeschlossen und möchte kurz meine Erfahrungen teilen.

Grundsätzlich hat es geklappt. Ich habe eine der SSDs eingebaut, einen neuen Speicherpool und Volume erstellt und dann erstmal die kleineren Shares verschieben lassen. Dann habe ich die APPs umgezogen, nicht mittels dieses Skripts, sondern per Deinstallation und Neuinstallation. Die Einstellungen sind eigentlich überall erhalten geblieben. In manchen Apps kann man auch wählen, auf welchem Volume die Einstellung/Datenbank liegen soll, das habe ich dann jeweils vorher gemacht.
Irgendwann geht natürlich dann der Platz auf der SSD aus, dann habe ich die HDDs entfernt. Dadurch dass Volume1 dann weg war, ist mir die Zwei-Faktor-Authentifizierung kaputt gegangen, kA warum. Da war dann eine Mode1-Reset nötig. Ich habe dann die zwei weiteren SSDs hinzugefügt, Volume erweitert und die restlichen Daten vom Backup eingespielt.

 

[maxblank]

Prima, dass es geklappt hat und danke für dein Feedback zum Vorgehen.
Es ist dann evtl. angebracht, zukünftig vorher 2FA zu deaktivieren.

 

[SpiderPOH1701]

Mal so als Frage hierzu da ich auch auf SSDs umstellen möchte , aber ist der einsatz von QVO Platten wirklich sinnvol ?
Die verschleißen doch extrem schnell oder ? zumindesten deutlich schneller als die EVOs oder ?
Ich lasse mich hier gerne aufklären

 

[dil88]

Die vom Hersteller prognostizierte Lebensdauer (TBW) einer Samsung 870 QVO ist mit 1,44 PB geringer als die einer 870 EVO mit 2,4 PB. Die Performance soll aber vor allem unter Last erheblich einbrechen können, insofern wird hier im Forum m.W. die EVO empfohlen.

 

[mstr_Q]

Wieso sollten Sie?
Die TBW ist hoch genug und normalerweise lagern auf einem NAS ja Daten (also primär Lesezugriffe), keine Datenbanken (permanente Schreibzugriffe). Ich habe da keine Bedenken, kann und werde aber gerne berichten, sobald Ausfallerscheinungen auftreten.

In Sachen Hardware ist die Umstellung natürlich übrigens ein Träumchen. Der Geräuschpegel ist praktisch verschwunden und der Energieverbrauch liegt bei unter der Hälfte.

 

[metalworker]

also mit der TBW ist ja in den meistne fällen eher kein Problem. Gerade bei nem Normalen NAS daheim .
Du schaufelst ja nicht permanent daten durch die gegend.

Wo du es echt vermeiden solltest ist bei arbeit als Überwachungsrecorder oder als Backupziel. Da bekommst schnell einiges an TB zusammen.

 

[plang.pl]

Die QVO sind auch langsamer als die EVO wegen fehlendem DRAM

 

[ctrlaltdelete]

Ich denke das fällt in einer DS nicht auf.

 

[plang.pl]

Kommt darauf an, was da läuft. Aufgrund der höheren TBW + besseren Durchsatz würde ich aber in jedem Server eher zu einer EVO greifen.

 

[maxblank]

Ich war auch immer der Meinung, dass die Samsung QVO keinen eigenen DRAM hat - ist allerdings vorhanden.


Quelle: https://gzhls.at/blob/ldb/b/2/5/8/35e00c7479fae32a4fa425171dcbdef10d05.pdf

 

[plang.pl]

Ah ok. Keine Ahnung, woher dann dieser Glaube kam. Deshalb bin ich die Tage im Elektrofachmarkt wieder eiskalt an der SSD vorbeigelaufen. Hätt ich also doch mitnehmen können. Die hat nichtmal weniger DRAM als die EVO: https://gzhls.at/blob/ldb/f/f/2/7/4def5e0930cb2d2dd4fc41f70c7e41c326fb.pdf

 

[maxblank]

Ja, das ist allerdings Standard, zumindest war es mal so. Pro 1 TB Kapazität waren es 1 GB RAM. Das reicht auch. Ist kein Cache im eigentlichen Sinne, dort liegt die Mapping-Tabelle.