Wenn man lange genug ein NAS hat und es mit Daten füttert, laufen die Festplatten zwangsläufig voll. Es gibt dann zwei Möglichkeiten: 1) aufräumen oder 2) größere Platten kaufen.

Letzte Woche habe ich mich für die pragmatische, zweite Lösung entschieden.

Dort draußen gibt es eine Menge Tutorials und Videos, wie man nun ein solches Upgrade durchführt, wenn man ein RAID hat. In der Kurzform: Platte raus, neue Platte rein, synchronisieren, wiederholen, RAID erweitern, fertig.

In meinem Fall verwende ich allerdings kein RAID, so dass ein anderer Prozess her musste. Da Synology natürlich auch auf Linux aufsetzt, bedarf es auch keiner großen Magie.

Wie bei einem Gebäude besteht die Speicherarchitektur bei Synology aus mehreren Ebenen: ganz unten, die Partition (bspw. /dev/sdb3), darüber der Software-RAID-Layer (bspw. /dev/md3) und schließlich das Dateisystem (bspw. /volume2):

|===========|
| /volume2  |
|===========|
| /dev/md3  |
|===========|
| /dev/sdb3 |
|===========|

Diese drei Ebenen gilt es zu vergrößern, von unten nach oben. Wir erweitern das Fundament (Partition/RAID) und machen dann einen Anbau (erweitern das Dateisystem).

Aber bevor es losgehen kann, klonen wir zunächst die alte Platte auf die neue:

# time dd if=/dev/sdX of=/dev/sdY bs=32M

Über die ideale Blockgröße (bs=32M, also 32 MB) lässt sich lange diskutieren, in meinem Fall konnte ich zwischen 32M und 64M keinen signifikanten Unterschied feststellen. Für 4 TB dauerte die ganze Aktion circa 9,5 Stunden.

Partition erweitern

Mit fdisk können wir nun die Partitionstabelle auf der neuen Platte ansehen. Synology verwendet hier drei Partition: zwei für das System, eine für die Daten:

Device       Start        End    Sectors  Size Type
/dev/sdb1      256    4980735    4980480  2.4G Linux RAID
/dev/sdb2  4980736    9175039    4194304    2G Linux RAID
/dev/sdb3  9437184 7814032064 7804594881  3.6T Linux RAID

Eventuell beschwert sich fdisk darüber, dass es keine Backup GPT Tabelle finden kann, das Problem wird aber im gleichen Schritt gelöst. Wichtig ist hierbei darauf zu achten, dass die Partitionen nicht “bündig” sind, das heißt es bleiben einige leere Sektoren.

Die Partition zu erweitern ist recht einfach: Zunächst löschen wir die bestehende Partition 3 (d, 3) und legen dann eine neue an (n, 3). fdisk erkennt hier die bestehende RAID-Signatur, diese wollen wir allerdings behalten und löschen sie daher nicht.

Der Startsektor muss identisch sein (in diesem Fall 9437184), den letzten Sektor setzt fdisk automatisch so, um die volle Größe der Platte zu nutzen.

Abschließend setzen wir den Typ der Partition auf 29, Linux RAID (t, 3, 29). Bevor wir fdisk beenden schreiben wir die neue Partitionstabelle auf die Platte (w).

RAID erweitern

Ein Blick in /proc/mdstat zeigt uns, welche Software-RAIDs derzeit aktiv sind:

# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md127 : active (auto-read-only) raid1 sdb3[0]
      3902296256 blocks super 1.2 [1/1] [U]

unused devices: <none>

In diesem Fall hat das System die ID 127 zugewiesen, erreichbar unter /dev/md127. Diese ID ist nicht fix, wir brauchen sie allerdings ohnehin nur temporär.

mdadm ist das Werkzeug um Software-RAIDs zu verwalten, wir schauen uns also zunächst den Status an:

# mdadm -D /dev/md127
/dev/md127:
           Version : 1.2
     Creation Time : ***
        Raid Level : raid1
        Array Size : 3902296256 (3721.52 GiB 3995.95 GB)
     Used Dev Size : 3902296256 (3721.52 GiB 3995.95 GB)
      Raid Devices : 1
     Total Devices : 1
       Persistence : Superblock is persistent

       Update Time : Fri Jun 17 19:58:57 2022
             State : clean
    Active Devices : 1
   Working Devices : 1
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : resync

              Name : DiskStation:3
              UUID : ***
            Events : 6

    Number   Major   Minor   RaidDevice State
       0       8       19        0      active sync   /dev/sdb3

Das RAID hat also, nach wie vor, eine Größe von ca. 4 TB, obwohl es nun auf einer bereits vergrößerten Partition von fast 8 TB liegt. Das lässt sich mit mdadm‘s Grow-Funktion leicht ändern:

# mdadm --grow /dev/md127 -z max
mdadm: component size of /dev/md127 has been set to 7809306951K

In wenigen Sekunden nimmt so das Software-RAID den gesamten verfügbaren Platz der nun vergrößerten Partition ein.

Dateisystem erweitern

Im letzten Schritt müssen wir nun das Dateisystem erweitern, um den gesamten Platz des Software-RAIDs zu verwenden. Da Synylogy ext4 als Dateisystem verwendet, kommt hier resize2fs zum Einsatz. Dieses Werkzeug kann ext2, 3 und 4 verwalten. Als Parameter braucht es lediglich die Angabe der Partition bzw. des Software-RAIDs, auf dem das zu vergrößernde Dateisystem liegt:

# resize2fs /dev/md127
resize2fs 1.44.5 (15-Dec-2018)
Please run 'e2fsck -f /dev/md127' first.

resize2fs ist vorsichtig, und verlangt, dass wir das Dateisystem zunächst einer Kontrolle durch e2fsck unterziehen. Das stellt sicher, dass das Dateisystem konsistent ist und vermeidet Probleme beim erweitern.

# e2fsck -f /dev/md127
e2fsck 1.44.5 (15-Dec-2018)
Pass 1: Checking inodes, blocks, and sizes
Inode 18 has INDEX_FL flag set on filesystem without htree support.
Clear HTree index<y>? yes
Inode 20 has INDEX_FL flag set on filesystem without htree support.
Clear HTree index<y>? yes
Inode 8913957 has INDEX_FL flag set on filesystem without htree support.
Clear HTree index<y>? yes
Inode 104991253 has INDEX_FL flag set on filesystem without htree support.
Clear HTree index<y>? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

1.42.6-4482: ***** FILE SYSTEM WAS MODIFIED *****
1.42.6-4482: 15180/243900416 files (0.7% non-contiguous), 924041481/975574064 blocks

In meinem Fall fand e2fsck sogar eine Handvoll Fehler. Man kann relativ bedenkenlos hier mit “Ja” auf die Vorschläge von e2fsck antworten, schließlich weiß dieses Werkzeug deutlich mehr über Dateisystemstrukturen als wir. Der gesamte Check sollte nicht länger als 1-2 Minuten dauern.

Jetzt, wo das Dateisystem überprüft und als “sauber” markiert ist, können wir einen zweiten Anlauf mit resize2fs starten:

# resize2fs /dev/md127
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/md127 to 1952326737 (4k) blocks.
The filesystem on /dev/md127 is now 1952326737 (4k) blocks long.

Auch diese Aktion braucht lediglich 1-2 Minuten und das Dateisystem hat nun die neue Größe.

Die neue Platte ist nun einsatzbereit und kann zurück in die DiskStation. Wenn man alles richtig gemacht hat, sollte diese ohne Probleme booten und die Speicher-Manager App zeigt das vergrößerte Volume an.