Plattenplatzkapazität erweitern ohne Neuaufsetzen
Vorbemerkungen
Eigentlich ist es nur bei den teureren NASen vorgesehen, die Plattenkapazität durch Austausch von Platten gegen solche mit größerer Kapazität zu erweitern. Bei einfachen Modellen müsste man sich mit Backup der Daten, Neuaufsetzen auf den größeren Platten, Restore der Daten behelfen. Wenn man sich etwas mit den Linux-Storage-Befehlen auskennt, geht es aber auch bei den einfachen Modellen ohne diesen Umweg - und zwar auf der Kommandozeile.
Hier möchte ich beschreiben, wie ich es gemacht habe. Die Anleitung ist halbwegs neutral gehalten, so dass sie hoffentlich auch bei anderen funktionieren kann.
In meinem Fall war das Modell ein TS-210 - es sollte jedoch mit allen funktionieren, die mindestens zwei Festplatten haben!
Alle Angaben ohne Garantie und ohne Gewähr. Aber nach bestem Wissen und Gewissen.
Grundkenntnisse sollten vorhanden sein. Linux-Erfahrung ist sehr hilfreich!
Ausgangssituation
[NAS Typ:] QNAP TS-210
[Firmware:] 3.8.3 Build 20130426
[Getestet:] ja
[Sonstige Modifikationen:] keine
Ursprüngliche Konfiguration: 2 * 1 TB-Festplatten, gespiegelt (RAID1).
Eine Festplatte fiel defekt aus und wurde durch eine 3 TB-Festplatte ersetzt.
Die neue Ersatz-Festplatte wurde sofort beim ersten Start erkannt, angenommen und als Spiegel eingebunden.
Die verbleibende 1 TB-Festplatte wurde später ebenfalls durch eine 3 TB-Festplatte ersetzt. Auch diese neue Platte wurde sofort beim ersten Start erkannt, angenommen und als Spiegel eingebunden.
Die Gesamtgröße des logischen Datenträgers war immer noch 1 TB (915,42 GB), obwohl beide Festplatten jeweils eine Kapazität von 3 TB (2794,52 GB) bieten.
Bei teureren NAS könnte man wie erwähnt einfach im Web-GUI die Kapazität erweitern. Beim TS-210 ist das leider nicht möglich.
Deshalb blieb als einzige Möglichkeit, das auf der Kommandozeile des NAS zu erledigen.
Die Grundlagen und Ideen dieser Anleitung stammen aus "[HOWTO] Expanding RAID5 from the command line (TS 509)" <http://forum.qnap.com/viewtopic.php?f=25&t=12109>
Eine günstige Zeit suchen und die anderen Benutzer/Familienmitglieder informieren: Es sollte niemand mehr Zugriff über das Netzwerk benötigen!
Vorgehensweise
Per ssh als 'admin' anmelden.
Spiegel anzeigen:
# df /dev/md0Filesystem Size Used Available Use% Mounted on/dev/md0 915.4G 851.7G 63.2G 93% /share/MD0_DATA
Überprüfen, dass alle gespiegelten Partitionen vorhanden und gesund sind:
# cat /proc/mdstatPersonalities : [linear] [raid0] [raid1] [raid6] [raid5] [raid4] md0 : active raid1 sda3[0] sdb3[1] 975193600 blocks [2/2] [UU]md2 : active raid1 sdb2[1] sda2[0] 530048 blocks [2/2] [UU]md13 : active raid1 sda4[0] sdb4[1] 458880 blocks [2/2] [UU] bitmap: 0/57 pages [0KB], 4KB chunkmd9 : active raid1 sda1[0] sdb1[1] 530048 blocks [2/2] [UU] bitmap: 0/65 pages [0KB], 4KB chunkunused devices: <none>
Wichtig ist hier, dass hinter keinem Device (F) steht und keines der U in den eckigen Klammern durch einen Unterstrich _ ersetzt wurde. Denn dann wäre etwas nicht in Ordnung.
# mdadm -D /dev/md0/dev/md0: Version : 00.90.03 Creation Time : Wed Dec 1 21:20:37 2010 Raid Level : raid1 Array Size : 975193600 (930.02 GiB 998.60 GB) Used Dev Size : 975193600 (930.02 GiB 998.60 GB) Raid Devices : 2 Total Devices : 2Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Sat Sep 14 18:43:52 2013 State : clean Active Devices : 2Working Devices : 2 Failed Devices : 0 Spare Devices : 0 UUID : ebc90a3d:9dab907f:68d5499d:33e132b9 Events : 0.177032 Number Major Minor RaidDevice State 0 8 3 0 active sync /dev/sda3 1 8 19 1 active sync /dev/sdb3
Welches Dateisystem ist auf dem Spiegel?
# grep MD0_DATA /etc/mtab/dev/md0 /share/MD0_DATA ext4 rw,usrjquota=aquota.user,jqfmt=vfsv0,user_xattr,data=ordered,delalloc,noacl 0 0
In meinem Fall ist das Dateisystem ext4.
Eventuelle NFS-Mounts auf Linux-Clients aushängen.
Alle Dienste anhalten:
# /etc/init.d/services.sh stopStop qpkg service: .Stop service: cloud3p.sh vpn_openvpn.sh vpn_pptp.sh ldap_server.sh antivirus.sh iso_mount.sh qsyncman.sh rsyslog.sh snmp nvrd.sh lunportman.sh iscsitrgt.sh smb.sh nfs crond.sh Qthttpd.sh twonkymedia.sh init_iTune.sh ImRd.sh StartMediaService.sh bt_scheduler.sh btd.sh ftp.sh atalk.sh mysqld.sh recycled.sh .
Der SSH-Server läuft dabei zum Glück dennoch weiter.
Nun sollte kein Zugriff auf den Datenträger mehr stattfinden und wir können ihn aushängen:
Falls dabei die Meldung "umount: /share/MD0_DATA: device is busy" erscheint, greift immer noch jemand/etwas über das Netzwerk auf den Speicherplatz zu!
Herausfinden, wer oder was das ist, kann man mit 'lsof':
Das Dateisystem auf Fehler überprüfen. Kann etwas dauern!
Je nach Dateisystem muss das passende Überprüfungswerkzeug ausgewählt werden. Für ext2, ext3 und ext4 kommt 'e2fsck' zum Einsatz:
# e2fsck -f /dev/md0e2fsck 1.41.4 (27-Jan-2009)Pass 1: Checking inodes, blocks, and sizesPass 2: Checking directory structurePass 3: Checking directory connectivityPass 4: Checking reference countsPass 5: Checking group summary information/dev/md0: 73209/60956672 files (4.3% non-contiguous), 227091096/243798400 blocks
Dateisysteme wie ext3 und ext4 verwenden ein sog. Journal, in dem alle Änderungen vor dem eigentlichen Schreiben aufgezeichnet werden (beschleunigt die Reparatur bei Problemen). Dieses Journal schalten wir bei den betroffenen Dateisystemen ab. Für ext3 und ext4 wird das Werkzeug 'tune2fs' verwendet:
Sicherheitshalber können wir noch überprüfen, dass die Partition, auf der unser Dateisystem liegt auch wirklich größer als die aktuelle Größe des Dateisystems angelegt wurde. Der Name der Partition wurde oben beim "mdadm -D /dev/md0" Befehl angezeigt, hier war es die dritte auf beiden Platten.
# parted /dev/sda printModel: WDC WD30EFRX-68AX9N0 (scsi)Disk /dev/sda: 3001GBSector size (logical/physical): 512B/512BPartition Table: gptNumber Start End Size File system Name Flags 1 20.5kB 543MB 543MB ext3 primary 2 543MB 1086MB 543MB linux-swap(v1) primary 3 1086MB 3000GB 2999GB ext2 primary 4 3000GB 3001GB 510MB ext3 primary# parted /dev/sdb printModel: WDC WD30EFRX-68AX9N0 (scsi)Disk /dev/sdb: 3001GBSector size (logical/physical): 512B/512BPartition Table: gptNumber Start End Size File system Name Flags 1 20.5kB 543MB 543MB ext3 primary 2 543MB 1086MB 543MB linux-swap(v1) primary 3 1086MB 3000GB 2999GB ext2 primary 4 3000GB 3001GB 510MB ext3 primary
Ja, Partition 3 hat knapp 3 TB Größe!
Nun kann die eigentliche Vergrößerung beginnen.
Zuerst den Spiegel über die komplette 3. Partition vergrößern. Achtung: Das wird sehr, sehr lange dauern! (Bei mir 5 Stunden - mit schnellen Festplatten!)
Das NAS piepste einmal (als Zeichen, dass die Synchronisierung startet) und die Festplatten begannen zu flackern.
Fortschrittsanzeige mit
# cat /proc/mdstatPersonalities : [linear] [raid0] [raid1] [raid6] [raid5] [raid4] md0 : active raid1 sda3[0] sdb3[1] 2928697600 blocks [2/2] [UU] [======>..............] resync = 33.7% (987396416/2928697600) finish=290.7min speed=111278K/secmd2 : active raid1 sdb2[1] sda2[0] 530048 blocks [2/2] [UU]md13 : active raid1 sda4[0] sdb4[1] 458880 blocks [2/2] [UU] bitmap: 0/57 pages [0KB], 4KB chunkmd9 : active raid1 sda1[0] sdb1[1] 530048 blocks [2/2] [UU] bitmap: 1/65 pages [4KB], 4KB chunkunused devices: <none>
In der 'resync'-Zeile wird die aktuelle Geschwindigkeit beim Kopieren und eine Hochrechnung der verbleibenden Zeit bis zum Ende angezeigt.
Die Fortschrittsanzeige startete bei 33%, denn ein TB von dreien war ja bereits synchronisiert!
Nach etwa 5 Stunden für die restlichen 67% war es dann endlich geschafft:
# mdadm -D /dev/md0/dev/md0: Version : 00.90.03 Creation Time : Wed Dec 1 21:20:37 2010 Raid Level : raid1 Array Size : 2928697600 (2793.02 GiB 2998.99 GB) Used Dev Size : 2928697600 (2793.02 GiB 2998.99 GB) Raid Devices : 2 Total Devices : 2Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Sun Sep 15 01:05:32 2013 State : active Active Devices : 2Working Devices : 2 Failed Devices : 0 Spare Devices : 0 UUID : ebc90a3d:9dab907f:68d5499d:33e132b9 Events : 0.177046 Number Major Minor RaidDevice State 0 8 3 0 active sync /dev/sda3 1 8 19 1 active sync /dev/sdb3
Ja, der Spiegel ist nun 3 GB groß!
In Internet-Foren ist zu lesen, dass der nächste Schritt häufig wegen Speichermangel abstürzt. Da mein NAS nur 256 MB Hauptspeicher hat, habe ich vorsorglich einen USB-Stick angeschlossen und dort zusätzlich zur vorhandenen 512 MB Swap-Partition noch eine Swap-Datei von einem Gigabyte Größe angelegt.
Der USB-Stick wurde nach dem Anstecken automatisch als 'sdt1' eingebunden.
Eine Datei von 1 GB Größe anlegen:
Die Datei als Swap-Datei 'formatieren':
# mkswap swap1Setting up swapspace version 1, size = 1073737 kBno label, UUID=7a51c309-b435-4e9e-b7af-29bedeab2f1b
Und den neuen Swap-Space aktivieren:
Überprüfen, wie viel Swap-Space verwendet wird:
# free total used free shared buffers Mem: 255628 230236 25392 0 8992 Swap: 1578608 24808 1553800Total: 1834236 255044 1579192
Ja, es ist nun 1 GB mehr als vorher!
Nun kann das Dateisystem vergrößert werden. Achtung: Das kann lange dauern!
Auch hier muss das passenden Werkzeug verwendet werden: Für ext2, ext3 und ext4 es es 'resize2fs':
# resize2fs -p /dev/md0resize2fs 1.41.4 (27-Jan-2009)Resizing the filesystem on /dev/md0 to 732174400 (4k) blocks.Begin pass 1 (max = 14904)Extending the inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXThe filesystem on /dev/md0 is now 732174400 blocks long.
Ohne Angabe einer Größe wird einfach das Maximum genommen.
Mit '-p' bekommt man eine Fortschrittsanzeige.
Nach der Vergrößerung sicherheitshalber das Dateisystem nochmal überprüfen:
# e2fsck -n /dev/md0e2fsck 1.41.4 (27-Jan-2009)/dev/md0: clean, 73209/183050240 files, 234722059/732174400 blocks
Die Option '-n' bewirkt, dass nur lesend überprüft und keine Änderungen durchgeführt werden.
Bei protokollierenden Dateisystemen können wir jetzt das Journal wieder einschalten. Für ext3 und ext4 wieder mit dem Befehl 'tune2fs':
# tune2fs -j /dev/md0tune2fs 1.41.4 (27-Jan-2009)Creating journal inode: doneThis filesystem will be automatically checked every -1 mounts or0 days, whichever comes first. Use tune2fs -c or -i to override.
Den Swap-Space auf dem USB-Stick wieder deaktivieren:
In der grafischen Oberfläche unter "Externes Gerät" kann der USB-Stick zum Abziehen vorbereitet und dann entfernt werden.
Um alles wieder sauber zu initialisieren, noch einen Neustart des NAS durchführen.
Nach dem erfolgtem Neustart können wir uns wieder anmelden und die erhaltene Größe überprüfen:
# df /dev/md0
Filesystem Size Used Available Use% Mounted on
/dev/md0 2.7T 851.7G 1.9T 31% /share/MD0_DATA
Yippie!!!!! :thumb:
Auch in der grafischen Oberfläche unter 'Datenspeicher' --> 'Datenträgerverwaltung' wurde nun die neue Größe von 2749,20 GB angezeigt!