HDD Upgrade ohne Datenverlust bei DS415+ mit 4 HDDs (Basis-Volume)

[Moep89]

Moment. Jetzt bin ich verwirrt, das sollte doch gerade bei einem Raid 1 einwandfrei funktionieren?

Ja, aber natürlich mit anschließendem Rebuild des RAIDs. Ich meine aber einen einfachen Austausch ohne das irgendetwas neu erstellt wird. Das einzige, was zu beachten ist, ist dass auf einer Platte immer das Sytem liegt. Entfernt man die, muss das System natürlich neu installiert werden.
Ich denke was die im Forum meinen bezieht sich auf das Zugreifen bei externem Anschluss. Das kann schwierig werden, wie ich ja auch schrieb. Das liegt eben u.a. an dem etwas spezielleren Dateisystem bzw. der Partition. Das kann durchaus auch mit einer Art Vorbereitung für RAID zu tun haben, aber deswegen sind die Platten selbst trotzdem nicht in einem RAID wenn Basic ausgewählt wurde. Nimmt man eine raus, passiert an den Daten der anderen rein gar nichts. Habe ich selbst schon so gemacht als ich 2x4 TB zunächst auf 12T B + 4 TB und etwas später dann auf 12 TB + 14 TB gebracht habe.

 

[Master_Chief_87]

Das einzige, was zu beachten ist, ist dass auf einer Platte immer das Sytem liegt. Entfernt man die, muss das System natürlich neu installiert werden.

Das System (DSM) spiegelt sich doch aber völlig selbständig über alle internen "Platten" hinweg?


Wie lautet also nun das Fazit zu meinem Anliegen?

Die neue 16TB Exos per eSATA an die Diskstation, darauf ein Volume erstellen, alles von der ausgedienten 6TB WD-Red dort hin kopieren und anschließend kommt die 16TB Exos in den Slot wo die 6TB WD-Red saß.

Oder doch lieber wie eingangs von mir als Idee vorgetragen mit dem vorübergehenden freilegen eines HDD-Slots?

 

[Moep89]

Ich würde sie eher intern direkt einrichten. Ich weiß nicht ob die DS die Platte am eSATA exakt genauso einrichtet wie intern.

 

[XN04113]

Link
You can follow the steps below to replace the hard disks without losing your data.

1. Turn off the Synology Product.
2. Replace the internal hard drive with a larger one.
3. Turn on the Synology Product.
4. Reinstall the system. das sollte entfallen sofern nicht das DSM zufällig auf der auszutauschen HDD liegt
5. Connect the replaced hard drive to the USB or eSATA port using external hard drive case.
6. Copy the data from the replaced hard drive to the new hard drive.
7. Remove the replaced hard drive.

Ich hoffe mal das der Hinweis "For one-bay models:" egal ist, da es hier wohl nur um Punkt 4 dreht.

 

[Master_Chief_87]

Link

Ich hoffe mal das der Hinweis "For one-bay models:" egal ist.

Soviel wie ich gelesen ist das leider nicht egal. Bei der 1-Bay DS werden die "Platten" anders eingerichtet/organisiert (-> RAID-Modus bei Multi-Bay DS auch bei Einzelbetrieb). Aber Moep89 meinte ja, dass das gar nicht stimmen würde. 🤷‍♂️
Sehr verwirrend das alles.

Ich würde sie eher intern direkt einrichten. Ich weiß nicht ob die DS die Platte am eSATA exakt genauso einrichtet wie intern.

😅 Ist/war auch meine Befürchtung - wenn es aber klappt, muss ich das Risiko nicht eingehen, dass mir das DSM das Volume auf der WD-Red zerschießt, sobald ich diese per eSATA anstöpsel.
Gibt es denn nirgendwo offizielle Hinweise dazu, wie eine per eSATA angeschlossene HDD vom DSM eingerichtet wird?

 

[Moep89]

Aber Moep89 meinte ja, dass das gar nicht stimmen würde. 🤷‍♂️

Nein, ich meinte, dass die Platten nicht wirklich als RAID betrieben werden. Dass es Unterschiede beim Dateisystem bzw. bei den Partitionen gibt hab ich extra geschrieben. Das beeinflusst aber eben nur ob die relativ einfach per USB anzuschließen geht oder nicht. Das betrifft nicht den eigentlichen Wechsel.
Mach die Datenübertragung doch einfach wie geplant intern. Das theoretische Risiko von Problemen hast du immer sobald du die Konfiguration irgendwie änderst, das kannst du ohne Backup also nie ganz eliminieren.
Alternativ die Daten einfach über einen Rechner wieder draufkopieren. Live Linux auf‘n USB Stick und los geht‘s.

 

[morcego]

Du kannst nicht einfach eine Platte ziehen die nicht Teil eines RAID (nicht 0) ist. Ich hab das schonmal probiert weil ich auch wissen wollte was dann passiert.
https://imaginado.de/2018/11/synology-laufwerksfehler-und-fehlerhafte-apps/

Du müsstest die Daten vorher runterziehen, Das Volume löschen, dann die Platte ziehen.
Neue rein, Wieder einrichten, Daten raufkopieren.
Du kannst meines Wissens nach auch nicht einfach Platten im Slot tauschen. Das NAS verwaltet seine Platten pro Slot und wenn sich da was ändert ist die Platte "neu". Es erkennt nichtmal die selbe Platte wenn sie innerhalb eines RAIDs gezogen und wieder gesteckt wird.
Auch bei einem Umzug müssen die Platten wieder 1:1 in den selben Slot wandern und dürfen nicht vertauscht werden.
Der eSATA klappt laut Test eines bekannten nicht mit jeder Hardware. Er wollte sich die Expansion Unit sparen, ging nicht.

 

[Master_Chief_87]

@morcego

Mach mir nicht so viel Hoffnung.

Das Akasa eSATA/USB3.0-Gehäuse habe ich jetzt wieder hier und auch schon eine kleinere alte Festplatte (NTFS) über eSATA mit der DS415+ verbunden.
Sieht gut aus soweit. Sie wird direkt als "satashare" gemountet und ich kann auf alle Dateien zugreifen.

Jetzt wäre mein Plan folgender:

1. DS415+ herunterfahren
2. ausgediente 6TB WD-Red aus Slot 3 rausziehen und in das per eSATA angeschlossene Akasa-Case
3. DS415+ hochfahren und testen ob die WD-Red über eSATA ausgelesen werden kann...

Wenn JA: Direkt die neue EXOS in den freien Slot 3, einrichten und alles über eSATA dort drauf kopieren - Problem gelöst!

Wenn NEIN: DS415+ herunterfahren, WD-Red wieder in Slot 3, hochfahren und es funktioniert so wie vorher - oder wird die WD-Red dann gar nicht mehr erkannt?
Anschließend müsste ich mir eine andere Lösung überlegen.

 

[morcego]

OK, gut wenn es erkannt wird. Aber wie du feststellst heißt es erstmal satashare.
"Eigentlich" müsste man das Konstrukt an einem anderen NAS ausprobieren was auch esata hat. Also deine 415+ ausschalten, 6TB raus, an einem anderen NAS gucken was passiert, und dann wieder zurück in die 415+ wenn sich das komisch verhält.
Hoffnung ist halt relativ, ohne Backup wäre mir das persönlich zu heikel. Es gibt keine unwichtigen Daten. Daten die das Kriterium erfüllen können gelöscht werden und existieren überhaupt nicht. schulterzuck
Von daher ist das Geschrei immer groß wenn was fehlt.
Kannst du nicht alternativ den Datenbestand auf der 6TB so zerlegen und verteilen, dass er erstmal woanders existiert bis du die neue HDD sauber nachgeschoben hast?

 

[Master_Chief_87]

Leider habe ich kein anderes NAS mit eSATA zur Hand. Immerhin habe ich gestern noch zwei alte aber zumindest lauffähige HDDs gefunden. Konnte somit nochmal 1TB sichern... sofern man das bei den merkwürdigen Arbeitsgeräuschen der alten Platten überhaupt noch so bezeichnen kann.

Ich werde den Eingriff jetzt mal so vornehmen (WD-Red an eSATA). Drückt mir die Daumen.


EDIT:

So.... DSM läuft wieder. Gab auch keine Fehlermeldungen. Bis jetzt wurde die extern angeschlossene WD-Red aber noch nicht gemountet.

Dafür finden hier zeitgleich (intern + extern) wiederkehrende Lese-/Schreib-Operationen statt. Das DSM scheint wohl irgendwas zu synchronisieren. - Eventuell meine installierten Pakete? -> Sind ja gerade alle mit dem Zusatz "Fehler" im Paketzentrum gelistet mit einem Reparieren-Knopf.

Mal abwarten....



EDIT2:

OK, bis auf die wiederkehrenden Festplatten-Aktivitäten aller 4 Festplatten, passiert hier garnix. DSM scheint die per eSATA angeschlossene WD-Red komplett zu ignorieren. 🤔
Ab- und wieder Anstöpseln des eSATA Case bringt ebenso nichts.

Also wieder zurück in Slot 3.....

 

[morcego]

Das klingt ja schon verdächtig nach meinen Erfahrungen die ich beschrieben habe.
Dann musst du womöglich auch per ssh die Datenbank neu erstellen lassen.

 

[Master_Chief_87]

Die WD-Red ist nun wieder an ihrem angestammten Ort. Nach dem Hochfahren lief alles so wie vorher.

Die einzige Fehlermeldung:

... aber ein Klick auf "(Reparieren)" brachte alles in Ordnung.

Ein (vorübergehend) externes Anschließen verursacht also keine Probleme.


Könnte man die WD-Red nicht auch mit einer HDD Klon-Software auf die Exos spiegeln?

Ansonsten bleibt mir nur noch der umständlichere Weg, alles von WD-Red zu EXOS zu schieben, WD-Red mit NTFS formatieren, von EXOS wieder alles auf die WD-Red, EXOS in DS, Volume erstellen und wieder alles von WD-Red (NTFS) zu EXOS kopieren. 🤪

 

[Master_Chief_87]

Also ich habe nun mit Hilfe eines Ubuntu Boot Stick die WD-Red mounten können.

Ebenso kann ich von diesem Ubuntu auf meine Diskstation zugreifen, in der jetzt auch die eingerichtete Exos steckt und auf Befüllung wartet.

Das Kopieren an sich klappt aber noch nicht so wie ich will.
Von dem Dateimanager bekomme ich ständig folgende Fehlermeldung, die ich jedes mal manuell überspringen muss.

Was sind das denn überhaupt für komische Ordner. Im DSM waren die nie zu sehen.
Habe die vorhin sogar alle gelöscht und tauchen jetzt nicht mehr im Ubuntu Dateimanager auf aber trotzdem versucht der jedes mal diese komischen Ordner zu kopieren.

Kann man das mit dem "Überspringen" denn nicht irgendwie automatisieren?

 

[Master_Chief_87]

Ich habe es nun endlich geschafft alle Daten (inklusive Plex Datenbank) von der alten WD-Red auf die neue SG-Exos umzuziehen (ohne ständig Fehlermeldungen beim Kopieren überspringen zu müssen) und zwar auf relativ direktem Weg.

Hier die Lösung:

1a. Überprüfung ob bzw. welche Pakete (Apps) im DSM sich auf dem auszutauschenden Volume (bei mir ist das volume1) befinden:

-> PowerShell in Windows öffnen
-> "ssh admin@192.168.XXX.XX" (Benutzername und IP-Adresse der/eurer DiskStation)
-> "ls -l /volume1/\@appstore/"
--> wenn dort Pakete (Apps) aufgelistet werden, folgendes ausführen um eben
diese (vorübergehend) auf ein anderes Volume/Festplatte (zBsp. volume2) zu verschieben:
---> "sudo mv -v /volume1/\@appstore /volume2/"
---> warten bis der Vorgang durchgelaufen ist

1b. DiskStation herunterfahren


2a. die ausgediente Festplatte rausziehen und per SATA (USB geht zumindest bei nicht) an den PC anstöpseln

2b. auf diesem PC ein Lubuntu Linux booten (zBsp. per Boot-Stick)

3a. Terminal öffnen und folgende Befehle eingeben:

sudo -i

apt-get update

apt-get install -y mdadm lvm2

mdadm -Asf && vgchange -ay

-> Nach diesem Befehl taucht sofort die Partition der (Synology-)Festplatte im Dateimanager auf.


So sieht bzw. sah das Terminal-Fenster bei mir aus nach Eingabe der oben genannten Befehle:

lubuntu@lubuntu:~$ sudo -i
root@lubuntu:~# apt-get update
Ign:1 cdrom://Lubuntu 20.10 _Groovy Gorilla_ - Release amd64 (20201022) groovy InRelease
Hit:2 cdrom://Lubuntu 20.10 _Groovy Gorilla_ - Release amd64 (20201022) groovy Release
Get:4 http://archive.ubuntu.com/ubuntu groovy InRelease [267 kB]
Get:5 http://security.ubuntu.com/ubuntu groovy-security InRelease [110 kB]
Get:6 http://archive.ubuntu.com/ubuntu groovy-updates InRelease [115 kB]  
Get:7 http://archive.ubuntu.com/ubuntu groovy/main amd64 DEP-11 Metadata [463 kB]
Get:8 http://security.ubuntu.com/ubuntu groovy-security/main amd64 Packages [253 kB]
Get:9 http://security.ubuntu.com/ubuntu groovy-security/main Translation-en [61.7 kB]
Get:10 http://security.ubuntu.com/ubuntu groovy-security/main amd64 DEP-11 Metadata [4676 B]
Get:11 http://security.ubuntu.com/ubuntu groovy-security/main DEP-11 48x48 Icons [7290 B]
Get:12 http://security.ubuntu.com/ubuntu groovy-security/main DEP-11 64x64 Icons [10.8 kB]
Get:13 http://security.ubuntu.com/ubuntu groovy-security/main DEP-11 64x64@2 Icons [29 B]
Get:14 http://security.ubuntu.com/ubuntu groovy-security/main DEP-11 128x128 Icons [25.6 kB]
Get:15 http://security.ubuntu.com/ubuntu groovy-security/main amd64 c-n-f Metadata [3716 B]
Get:16 http://security.ubuntu.com/ubuntu groovy-security/restricted amd64 Packages [111 kB]
Get:17 http://archive.ubuntu.com/ubuntu groovy/universe amd64 DEP-11 Metadata [3726 kB]
Get:18 http://security.ubuntu.com/ubuntu groovy-security/restricted Translation-en [16.5 kB]
Get:19 http://security.ubuntu.com/ubuntu groovy-security/restricted amd64 c-n-f Metadata [420 B]
Get:20 http://security.ubuntu.com/ubuntu groovy-security/universe amd64 Packages [64.3 kB]
Get:21 http://security.ubuntu.com/ubuntu groovy-security/universe Translation-en [29.2 kB]
Get:22 http://security.ubuntu.com/ubuntu groovy-security/universe amd64 DEP-11 Metadata [4556 B]
Get:23 http://security.ubuntu.com/ubuntu groovy-security/universe DEP-11 48x48 Icons [12.4 kB]
Get:24 http://security.ubuntu.com/ubuntu groovy-security/universe DEP-11 64x64 Icons [19.8 kB]
Get:25 http://security.ubuntu.com/ubuntu groovy-security/universe DEP-11 64x64@2 Icons [29 B]
Get:26 http://security.ubuntu.com/ubuntu groovy-security/universe DEP-11 128x128 Icons [46.6 kB]
Get:27 http://security.ubuntu.com/ubuntu groovy-security/universe amd64 c-n-f Metadata [2864 B]
Get:28 http://security.ubuntu.com/ubuntu groovy-security/multiverse amd64 Packages [8000 B]
Get:29 http://security.ubuntu.com/ubuntu groovy-security/multiverse Translation-en [2320 B]
Get:30 http://security.ubuntu.com/ubuntu groovy-security/multiverse amd64 c-n-f Metadata [304 B]
Get:31 http://archive.ubuntu.com/ubuntu groovy/universe DEP-11 64x64 Icons [7863 kB]
Get:32 http://archive.ubuntu.com/ubuntu groovy/multiverse amd64 DEP-11 Metadata [44.4 kB]
Get:33 http://archive.ubuntu.com/ubuntu groovy-updates/main amd64 Packages [405 kB]
Get:34 http://archive.ubuntu.com/ubuntu groovy-updates/main Translation-en [102 kB]
Get:35 http://archive.ubuntu.com/ubuntu groovy-updates/main amd64 DEP-11 Metadata [40.6 kB]
Get:36 http://archive.ubuntu.com/ubuntu groovy-updates/main DEP-11 48x48 Icons [30.4 kB]
Get:37 http://archive.ubuntu.com/ubuntu groovy-updates/main DEP-11 64x64 Icons [50.8 kB]
Get:38 http://archive.ubuntu.com/ubuntu groovy-updates/main DEP-11 64x64@2 Icons [29 B]
Get:39 http://archive.ubuntu.com/ubuntu groovy-updates/main DEP-11 128x128 Icons [104 kB]
Get:40 http://archive.ubuntu.com/ubuntu groovy-updates/main amd64 c-n-f Metadata [7056 B]
Get:41 http://archive.ubuntu.com/ubuntu groovy-updates/restricted amd64 Packages [133 kB]
Get:42 http://archive.ubuntu.com/ubuntu groovy-updates/restricted Translation-en [20.1 kB]
Get:43 http://archive.ubuntu.com/ubuntu groovy-updates/restricted amd64 c-n-f Metadata [460 B]
Get:44 http://archive.ubuntu.com/ubuntu groovy-updates/universe amd64 Packages [157 kB]
Get:45 http://archive.ubuntu.com/ubuntu groovy-updates/universe Translation-en [61.1 kB]
Get:46 http://archive.ubuntu.com/ubuntu groovy-updates/universe amd64 DEP-11 Metadata [104 kB]
Get:47 http://archive.ubuntu.com/ubuntu groovy-updates/universe DEP-11 48x48 Icons [107 kB]
Get:48 http://archive.ubuntu.com/ubuntu groovy-updates/universe DEP-11 64x64 Icons [174 kB]
Get:49 http://archive.ubuntu.com/ubuntu groovy-updates/universe DEP-11 64x64@2 Icons [29 B]
Get:50 http://archive.ubuntu.com/ubuntu groovy-updates/universe DEP-11 128x128 Icons [425 kB]
Get:51 http://archive.ubuntu.com/ubuntu groovy-updates/universe amd64 c-n-f Metadata [4860 B]
Get:52 http://archive.ubuntu.com/ubuntu groovy-updates/multiverse amd64 Packages [13.9 kB]
Get:53 http://archive.ubuntu.com/ubuntu groovy-updates/multiverse Translation-en [4012 B]
Get:54 http://archive.ubuntu.com/ubuntu groovy-updates/multiverse amd64 DEP-11 Metadata [2468 B]
Get:55 http://archive.ubuntu.com/ubuntu groovy-updates/multiverse DEP-11 48x48 Icons [29 B]
Get:56 http://archive.ubuntu.com/ubuntu groovy-updates/multiverse DEP-11 64x64 Icons [2638 B]
Get:57 http://archive.ubuntu.com/ubuntu groovy-updates/multiverse DEP-11 64x64@2 Icons [29 B]
Get:58 http://archive.ubuntu.com/ubuntu groovy-updates/multiverse DEP-11 128x128 Icons [29 B]
Get:59 http://archive.ubuntu.com/ubuntu groovy-updates/multiverse amd64 c-n-f Metadata [540 B]
Fetched 15.2 MB in 4s (4130 kB/s)              
Reading package lists... Done
root@lubuntu:~# apt-get install -y mdadm lvm2
Reading package lists... Done
Building dependency tree      
Reading state information... Done
lvm2 is already the newest version (2.03.07-1ubuntu3).
Suggested packages:
  default-mta | mail-transport-agent dracut-core
The following NEW packages will be installed:
  mdadm
0 upgraded, 1 newly installed, 0 to remove and 218 not upgraded.
Need to get 420 kB of archives.
After this operation, 1268 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu groovy/main amd64 mdadm amd64 4.1-5ubuntu5 [420 kB]
Fetched 420 kB in 0s (1962 kB/s)
Preconfiguring packages ...
Selecting previously unselected package mdadm.
(Reading database ... 240052 files and directories currently installed.)
Preparing to unpack .../mdadm_4.1-5ubuntu5_amd64.deb ...
Unpacking mdadm (4.1-5ubuntu5) ...
Setting up mdadm (4.1-5ubuntu5) ...
Generating mdadm.conf... done.
update-initramfs is disabled since running on read-only media
/usr/sbin/grub-probe: error: failed to get canonical path of `/cow'.
Created symlink /etc/systemd/system/mdmonitor.service.wants/mdcheck_continue.timer → /lib/systemd/system/mdcheck_continue.timer.
Created symlink /etc/systemd/system/mdmonitor.service.wants/mdcheck_start.timer → /lib/systemd/system/mdcheck_start.timer.
Created symlink /etc/systemd/system/mdmonitor.service.wants/mdmonitor-oneshot.timer → /lib/systemd/system/mdmonitor-oneshot.timer.
Processing triggers for man-db (2.9.3-2) ...
root@lubuntu:~# mdadm -Asf && vgchange -ay
mdadm: /dev/md/2 has been started with 1 drive.
root@lubuntu:~#

Hier noch ein Screenshot wo die Partition mit den zu sichernden Daten im Dateimanager aufgelistet wird:

Man sieht hier auch im Partitions-Manager, dass die "Platte" vom DSM tatsächlich als RAID (1) eingerichtet wurde.

4a. neue Festplatte in den freien Slot der DiskStation und diese einschalten

4b. neues Volume sowie einen neuen "Gemeinsamen Ordner" (analog zur alten Festplatte) erstellen

4c. die zuvor auf Volume2 verschobenen Pakete (installierte Apps) wieder auf Volume1 schieben:

-> PowerShell in Windows öffnen (Terminal in Lubuntu Linux sollte aber genauso funktionieren)
-> "ssh admin@192.168.XXX.XX" (Benutzername und IP-Adresse der/eurer DiskStation)
---> "sudo mv -v /volume2/\@appstore /volume1/"
---> warten bis der Vorgang durchgelaufen ist

Nun geht es an das Kopieren der Daten von der alten zur neuen HDD.

5. zu erst der Datenbank Ordner von Plex:

5a. erstellt auf der neuen HDD (bei mir Volume1) einen neuen "Gemeinsamen Ordner" mit dem Namen "Plex"

5b. diesem "Plex" Ordner Lese-/Schreibrechte für den Benutzer "Plex" im DSM zuweisen

5c. Wieder zum Lubuntu Desktop wechseln und den Inhalt des "Plex" Datenbank Ordners von der alten HDD zum gerade erstellten "Plex" Ordner auf der neuen HDD (in der Diskstation) kopieren.
Dazu einfach im Lubuntu Dateimanager über "Network" die Diskstation aufrufen.

5d. Sobald fertig kopiert, kann Plex im Paket-Zentrum des DSM wieder gestartet werden. Plex sollte dann genauso laufen wie zuvor.

6. Nun kommt der ganze Rest dran. Einfach alles (relevante) auf der alten Partition (bei mir als "1.42.6-5004" gemountet) wieder übers Netzwerk auf die neue HDD kopieren.
Bei etwaigen Fehlern bietet der Dateimanager von Lubuntu statt eines "überspringen"-Knopfes einen "ignorieren"-Knopf an UND DIESER MUSS NUR EINMAL BETÄTIGT WERDEN.

Der Kopiervorgang läuft anschließend völlig reibungslos durch. (bei mir waren es 65MB/s über Gigabit-LAN)

7. Fertig