5
Linux Softraid (Raid1) vergrößern durch Festplattentausch am Bespiel eines Synology DS210j Home-NAS
Ich stand vor dem Problem, dass das Raid1 meiner Synology Diskstation DS210j mit 1TB langsam nicht mehr in der Lage war, die RAW-Sources meiner Photosammlung zu sichern. Also kurzerhand 2 neue 2TB Platten gekauft und das alte Raid erweitert.
Die DS210j arbeitet mit einem rudimentären Linux und einem Softraid. Daher habe ich die alten Platten aus der DS210j ausgebaut und zusammen mit den beiden neuen in einen normalen PC gesetzt, den ich mit Knoppix 7.0 gebootet hab.
Das gleiche Prinzip sollte auch mit allen anderen Geräten funktionieren, die mit Linux Softraids arbeiten.
WICHTIG: Man muss sich absolut sicher sein, welche Festplatte im Linux unter welcher Zuordnung zu finden ist. Mit 'sudo gparted' kann man sich auch die Partitionierung der Festplatt noch schnell und übersichtlich anzeigen lassen.
Bei mir folgendes Setup:
/dev/sda = alte HDD 1
/dev/sdb = alte HDD 2
/dev/sdc = neue HDD 1
/dev/sdd = neue HDD 2
wenn man nur ein Volume in der DS210j hat, ist dieses in der Partition 3 zu finden. Das Raid läuft als /dev/md2
- um keinen Stress mit den DS eigenen Partitionen zu haben und diese 1:1 auf die neuen Platten zu nehmen und nicht mit meiner Sicherung herumzuspielen, habe ich zuerst per dd einen kompletten Spiegel auf die neuen Platten gezogen. Danach brauchte ich die ursprünglichen Platten gar nicht mehr anfassen:
dd if=/dev/sda of=/dev/sdc
dd if=/dev/sdb of=/dev/sdd
( mit bs=4096 kann man vielleicht die Geschwindigkeit noch etwas erhöhen. Das dd hat bei mir dann mal bis zum nächsten Tag gedauert
)
- Das Raid auf den neuen Platten nun im Knoppix aktivieren:
mdadm --examine /dev/sdc3
mdadm --examine /dev/sdd3
mdadm --assemble /dev/md2 /dev/sdc3 /dev/sdd3
- die Partition 2 aushängen:
mdadm -f /dev/sdd3
mdadm -r /dev/sdd3
- mit cfdisk dann die alte Partition löschen (sdd3) und mit dem Type FD und vollem verfügbaren Speicher neu anlegen:
cfdisk /dev/sdd
- die Partition 2 wieder einhängen:
mdadm -a /dev/md2 /dev/sdd3
- warten bis der Sync abgeschlossen ist:
less /proc/mdstat
- jetzt die Partition 1 aushängen:
mdadm -f /dev/sdc3
mdadm -r /dev/sdc3
- mit cfdisk dann auch diese Partition löschen (sdc3) und mit dem Type FD und vollem verfügbaren Speicher neu anlegen:
cfdisk /dev/sdc
- die Partition 1 auch wieder einhängen und warten bis der Sync abgeschlossen ist:
mdadm -a /dev/md2 /dev/sdd3
less /proc/mdstat
- nun die Raid-Partition vergrößern:
mdadm --grow /dev/md2 --size=max
e2fsck -f /dev/md2
resize2fs /dev/md2
e2fsck -f /dev/md2
- Zum Schluss noch Raid überprüfen und einmal mounten um zu sehen, dass der Platz zur Verfügung steht:
less /proc/mdstat
mount /dev/md2 /mnt
df -h
Das war's auch schon. Die neuen Festplatten in die DS210j einbauen und Gerät hochfahren. Alle Konfigurationen und Einstellungen sind immer, nur dass die Freigabe jetzt den doppelten Speicher hat. Geht vielleicht auch schneller, hat aber für mich gut funktioniert.
Bei mir folgendes Setup:
/dev/sda = alte HDD 1
/dev/sdb = alte HDD 2
/dev/sdc = neue HDD 1
/dev/sdd = neue HDD 2
wenn man nur ein Volume in der DS210j hat, ist dieses in der Partition 3 zu finden. Das Raid läuft als /dev/md2
- um keinen Stress mit den DS eigenen Partitionen zu haben und diese 1:1 auf die neuen Platten zu nehmen und nicht mit meiner Sicherung herumzuspielen, habe ich zuerst per dd einen kompletten Spiegel auf die neuen Platten gezogen. Danach brauchte ich die ursprünglichen Platten gar nicht mehr anfassen:
dd if=/dev/sda of=/dev/sdc
dd if=/dev/sdb of=/dev/sdd
( mit bs=4096 kann man vielleicht die Geschwindigkeit noch etwas erhöhen. Das dd hat bei mir dann mal bis zum nächsten Tag gedauert
)- Das Raid auf den neuen Platten nun im Knoppix aktivieren:
mdadm --examine /dev/sdc3
mdadm --examine /dev/sdd3
mdadm --assemble /dev/md2 /dev/sdc3 /dev/sdd3
- die Partition 2 aushängen:
mdadm -f /dev/sdd3
mdadm -r /dev/sdd3
- mit cfdisk dann die alte Partition löschen (sdd3) und mit dem Type FD und vollem verfügbaren Speicher neu anlegen:
cfdisk /dev/sdd
- die Partition 2 wieder einhängen:
mdadm -a /dev/md2 /dev/sdd3
- warten bis der Sync abgeschlossen ist:
less /proc/mdstat
- jetzt die Partition 1 aushängen:
mdadm -f /dev/sdc3
mdadm -r /dev/sdc3
- mit cfdisk dann auch diese Partition löschen (sdc3) und mit dem Type FD und vollem verfügbaren Speicher neu anlegen:
cfdisk /dev/sdc
- die Partition 1 auch wieder einhängen und warten bis der Sync abgeschlossen ist:
mdadm -a /dev/md2 /dev/sdd3
less /proc/mdstat
- nun die Raid-Partition vergrößern:
mdadm --grow /dev/md2 --size=max
e2fsck -f /dev/md2
resize2fs /dev/md2
e2fsck -f /dev/md2
- Zum Schluss noch Raid überprüfen und einmal mounten um zu sehen, dass der Platz zur Verfügung steht:
less /proc/mdstat
mount /dev/md2 /mnt
df -h
Das war's auch schon. Die neuen Festplatten in die DS210j einbauen und Gerät hochfahren. Alle Konfigurationen und Einstellungen sind immer, nur dass die Freigabe jetzt den doppelten Speicher hat. Geht vielleicht auch schneller, hat aber für mich gut funktioniert.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 201763
Url: https://administrator.de/contentid/201763
Printed on: April 19, 2024 at 04:04 o'clock
5 Comments
Latest comment
Zitat von @demokrit:
dd if=/dev/sda of=/dev/sdc
dd if=/dev/sdb of=/dev/sdd
( mit bs=4096 kann man vielleicht die Geschwindigkeit noch etwas erhöhen. Das dd hat bei mir dann mal bis zum nächsten
Tag gedauert )
dd if=/dev/sda of=/dev/sdc
dd if=/dev/sdb of=/dev/sdd
( mit bs=4096 kann man vielleicht die Geschwindigkeit noch etwas erhöhen. Das dd hat bei mir dann mal bis zum nächsten
Tag gedauert
)Hier empfehle ich bs=1M oder gar mehr. Dadurch daß dann viel mehr Sektoren sequentiell gelesen werden und diese en Block in den Speicher wandern werden die caches der Platten und das DMA besser genutzt, was meist zu einer höhere Geschwinigkeit führt.
Eine Blockgröße von 4k ist da eher kontraproduktiv.
lks
Moin,
Mir kommt das etwas zu umständlich vor.
ich würde da anders vorgehen:
Sollte deutlich schneller gehen als mit obigem Verfahren.
lks
Mir kommt das etwas zu umständlich vor.
ich würde da anders vorgehen:
- Alle RAIDs stoppen
- Mit parted -l /fdisk -l die Partitionen anzeigen lassen.
- mit dd if=/dev/sda of=/dev/sdc bs=1M count=16 die Partitionstabelle umkopieren (und für sdb sdd das gleiche).
- Wenn die Platten nach dem MBR-Schema partitioniert waren, hat man schon die PArtiotionierung kopiert, ansonsten muß man mit gdisk oder parted die gpt-Partitionstabelle reparieren lassen. (genauer die Backup-tabelle am Plattenende neu anlegen lassen).
- Danach die Partition auf dem Ziel, die vergrößert werden soll löschen und neu anlegen.
- Das RAID zusammenbauen mdadm -C /dev/md2 -n2 -l1 --assume-clean /dev/sdc3 /dev/sdd3 . Assume-clean kann benutzt werden, weil da ja noch keine Daten drauf sind und eh erstmal Daten draufkopiert werden.
- Das alte RAId starten mdadm -A /dev/md7 /dev/sda3 /dev/sdb3
- Filesystem kopieren dd if=7dev/md7 of=/dev/md2 bs=1M
- Nun wie oben mit
e2fsck -f /dev/md2
resize2fs /dev/md2
e2fsck -f /dev/md2
resize2fs /dev/md2
e2fsck -f /dev/md2
- das Filesystem vergrößern.
- fertich.
Sollte deutlich schneller gehen als mit obigem Verfahren.
lks
@lks: Das stimmt. Die Methode ist für diesen Fall sicherlich etwas fixer und sollte auch funktionieren.
Dran denken muss man beim Synology aber noch, dass man in diesem Fall auch die Partitionen 1+2 jeweils nochmal explizit mit dd kopiert, da diese das Bootsystem und die ganzen Managementtools mit allen Einstellungen beinhalten.
Ich gebe aber zu, meine Methode erschien mir als die sicherere ;) Die Variante mit dem Ein- und Aushängen kann man z.B. auch in einem normalen Server (und mit anderen Raid-Leveln) anwenden mit einer Minimierung der Downzeiten.
Die bs=1M probiere ich dann mit der nächsten Platte aus. Habe hier noch eine zu klonen ;)
Dran denken muss man beim Synology aber noch, dass man in diesem Fall auch die Partitionen 1+2 jeweils nochmal explizit mit dd kopiert, da diese das Bootsystem und die ganzen Managementtools mit allen Einstellungen beinhalten.
Ich gebe aber zu, meine Methode erschien mir als die sicherere ;) Die Variante mit dem Ein- und Aushängen kann man z.B. auch in einem normalen Server (und mit anderen Raid-Leveln) anwenden mit einer Minimierung der Downzeiten.
Die bs=1M probiere ich dann mit der nächsten Platte aus. Habe hier noch eine zu klonen ;)
Zitat von @demokrit:
@lks: Das stimmt. Die Methode ist für diesen Fall sicherlich etwas fixer und sollte auch funktionieren.
Dran denken muss man beim Synology aber noch, dass man in diesem Fall auch die Partitionen 1+2 jeweils nochmal explizit mit dd
kopiert, da diese das Bootsystem und die ganzen Managementtools mit allen Einstellungen beinhalten.
@lks: Das stimmt. Die Methode ist für diesen Fall sicherlich etwas fixer und sollte auch funktionieren.
Dran denken muss man beim Synology aber noch, dass man in diesem Fall auch die Partitionen 1+2 jeweils nochmal explizit mit dd
kopiert, da diese das Bootsystem und die ganzen Managementtools mit allen Einstellungen beinhalten.
O.K. das habe ich vergessen dazuzuschreiben, sollte aber, wenn man aufgepaßt hat, schnell auffallen, daß diese Partitionen ja auch kopiert werden müsssen.
Ich gebe aber zu, meine Methode erschien mir als die sicherere ;) Die Variante mit dem Ein- und Aushängen kann man z.B. auch
in einem normalen Server (und mit anderen Raid-Leveln) anwenden mit einer Minimierung der Downzeiten.
Wenn man "sicher" und möglichst geringen Downtimes arbeiten will, kann man auch diese Variante bei RAID1 nehmen. Da kann man das "mdadm --grow" gleich nach dem fertigsynchrobnisieren und entfernen der kleine Platten machen, ohne groß mit mit parted/fdsik herumzuspielen, was auch die Gefahr des Datenverlustes beinhaltet.
lks
Die bs=1M probiere ich dann mit der nächsten Platte aus. Habe hier noch eine zu klonen ;)
habe jetzt den dd mit bs=4M getested. Unterschied in der 'Overall-Writespeed': 16MB/s bei dd ohne Blocksize-Angabe, 71MB/s bei dd mit bs=4M. Macht also Sinn. Da allerdings auf dieser Platte ein NTFS-Volume existierte, war danach noch ein 'sudo ntfsfix /dev/sda1' nötig.
