Knappen Speicherplatz auf Linux VPS vergrössern

Der Speicherplatz auf dem virtuellen Debian Linux Server "examplehost" wird knapp und es soll daher zusätzlicher Speicherplatz verfügbar gemacht werden. Die folgende Anleitung zeigt, wie der verfügbare "Disk Space" auf einem Debian 9 Linux Server vergrössert werden kann.

Alles folgende bezüglich Vergrösserung des verfügbaren Speicherplatzes auf einem Linux Server kann grundsätzlich unter jedem Linux System analog ausgeführt werden. Die nachfolgend beschriebenen Prozesse wurde auf einem Debian 9 64bit Linux Server mit einem XFS-Datei ausgeführt. Bei der Nutzung abweichender Linux Distributionen oder alternativer Dateisysteme müssen einzelne Schritte analog angepasst werden) Es wird vorausgesetzt, dass die Utilities "fdisk" # apt-get install libfdisk1 und "xfsprogs" # apt-get install xfsprogs auf dem Linux VPS vorhanden sind.

Im Zusammenhang mit Cloud Services von Hostfactory bezieht sich die folgende Beschreibung für das Vergrössern von verfügbarem Speicherplatz auf einem Linux Server auf unsere Cloud Server Angebote und unsere Lösungen mit einem Cloud Server WebEdition inklusive Control Panel Plesk

Aktuelle Situation auf Debian VPS überprüfen

Prüfen wir als erstes die aktuelle Situation. Wir möchten wissen, wieviel Speicherplatz in den vorhandenen Partitionen verfügbar ist und welche Dateisysteme hier verwendet werden:

1. root@examplehost:~# df -Th
2. Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf
3. udev devtmpfs 2.0G 0 2.0G 0% /dev
4. tmpfs tmpfs 393M 5.9M 388M 2% /run
5. /dev/xvda2 xfs 119G 118G 1G 99% /
6. tmpfs tmpfs 2.0G 0 2.0G 0% /dev/shm
7. tmpfs tmpfs 5.0M 0 5.0M 0% /run/lock
8. tmpfs tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
9. tmpfs tmpfs 393M 0 393M 0% /run/user/0

Mit dem Kommando # df -Th wird mir angezeigt, dass meine "Hauptpartion" unter '/' über eine Grösse von total 119 GB verfügt, wovon aber in einem XFS-Filesystem derzeit 118 GB, also rund 99%, belegt sind.

Mit einem # fdisk -l lasse ich mir die Situation bzgl. Festplatten und Partitionen anzeigen:

1. root@examplehost:~# fdisk -l
2. Disk /dev/xvda: 120 GiB, 128849018880 bytes, 251658240 sectors
3. Units: sectors of 1 * 512 = 512 bytes
4. Sector size (logical/physical): 512 bytes / 512 bytes
5. I/O size (minimum/optimal): 512 bytes / 512 bytes
6. Disklabel type: dos
7. Disk identifier: 0x19ab9fb3
9. Device Boot Start End Sectors Size Id Type
10. /dev/xvda1 2046 3905535 3903490 1.9G 5 Extended
11. /dev/xvda2 3905536 251658239 247752704 118.1G 83 Linux
12. /dev/xvda5 2048 3905535 3903488 1.9G 82 Linux swap / Solaris
14. Partition table entries are not in disk order.

Ich erkenne also, dass meine physikalische Disk "/dev/xvda" 120 GB gross ist und in drei Devices aufgeteilt wurde. Unter "/dev/xvda2" werden die oben entdecketen 119 GB für "/" angeboten. - Ich möchte nun also diesen Speicherplatz in etwa verdoppeln.

Grössere Disk beim Cloud Service Provider beziehen

Hierfür kontaktiere ich meinen Cloud Server Hosting Provider, um ein entsprechendes Speicherplatz Upgrade zu erhalten.

Bei Hostfactory kann ein derartiges Upgrade bequem via Control Panel "my.hostfactory" bestellt werden.

Gesagt, getan: In meinem Virtual Private Server steht nun eine Hard Disk mit einer Grösse von insgesamt 240GB zur verfügung:

1. root@examplehost:~# fdisk -l
2. Disk /dev/xvda: 240 GiB, 257698037760 bytes, 503316480 sectors
3. Units: sectors of 1 * 512 = 512 bytes
4. Sector size (logical/physical): 512 bytes / 512 bytes
5. I/O size (minimum/optimal): 512 bytes / 512 bytes
6. Disklabel type: dos
7. Disk identifier: 0x19ab9fb3
9. Device Boot Start End Sectors Size Id Type
10. /dev/xvda1 2046 3905535 3903490 1.9G 5 Extended
11. /dev/xvda2 3905536 251658239 247752704 118.1G 83 Linux
12. /dev/xvda5 2048 3905535 3903488 1.9G 82 Linux swap / Solaris
14. Partition table entries are not in disk order.

Wie ich aber hier sehe, steht mir nun zwar eine SSD, resp. HDD mit 240GB zur Verfügung, aber mein "/dev/xvda2" ist immer noch erst 118.3 GB gross:

1. root@examplehost:~# df -Th
2. Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf
3. udev devtmpfs 2.0G 0 2.0G 0% /dev
4. tmpfs tmpfs 393M 5.9M 388M 2% /run
5. /dev/xvda2 xfs 119G 118G 1G 99% /
6. tmpfs tmpfs 2.0G 0 2.0G 0% /dev/shm
7. tmpfs tmpfs 5.0M 0 5.0M 0% /run/lock
8. tmpfs tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
9. tmpfs tmpfs 393M 0 393M 0% /run/user/0

Partitionstabelle mit "fdisk" auf neuer Disk revidieren

Damit ich nun also die zusätzlichen rund 120 GB neuen Speicherplatz auf meinem Debian Linux Server auch tatsächlich verwenden kann, müss die Partitionsatabelle neu geschrieben werden. Ich verwende hierzu wiederum das Utility "fdisk" und bearbeite '/dev/xvda'.

Hierbei gilt es festzuhalten, dass die Cloud Server Lösungen von Hostfactory von Haus aus und in aller Regel mit einer "bequem" zu verwaltenden Partitionstabelle daherkommen. In abweichenden Fällen müssen die unten ausgeführten Schritte möglicherweise leicht angepasst, respektive erweitert ausgeführt werden.

1. # fdisk /dev/xvda
3. Welcome to fdisk (util-linux 2.29.2).
4. Changes will remain in memory only, until you decide to write them.
5. Be careful before using the write command.
8. Command (m for help):

Ich wähle "m", um die hier verfügbaren Optionen anzeigen zu lassen:

1. Command (m for help): m
3. Help:
5. DOS (MBR)
6. a toggle a bootable flag
7. b edit nested BSD disklabel
8. c toggle the dos compatibility flag
10. Generic
11. d delete a partition
12. F list free unpartitioned space
13. l list known partition types
14. n add a new partition
15. p print the partition table
16. t change a partition type
17. v verify the partition table
18. i print information about a partition
20. Misc
21. m print this menu
22. u change display/entry units
23. x extra functionality (experts only)
25. Script
26. I load disk layout from sfdisk script file
27. O dump disk layout to sfdisk script file
29. Save & Exit
30. w write table to disk and exit
31. q quit without saving changes
33. Create a new label
34. g create a new empty GPT partition table
35. G create a new empty SGI (IRIX) partition table
36. o create a new empty DOS partition table
37. s create a new empty Sun partition table
40. Command (m for help):

Mit p lasse ich mir die aktuellen Partitionstabellen noch einmal anzeigen:

1. Command (m for help): p
2. Disk /dev/xvda: 240 GiB, 257698037760 bytes, 503316480 sectors
3. Units: sectors of 1 * 512 = 512 bytes
4. Sector size (logical/physical): 512 bytes / 512 bytes
5. I/O size (minimum/optimal): 512 bytes / 512 bytes
6. Disklabel type: dos
7. Disk identifier: 0x19ab9fb3
9. Device Boot Start End Sectors Size Id Type
10. /dev/xvda1 2046 3905535 3903490 1.9G 5 Extended
11. /dev/xvda2 3905536 251658239 247752704 118.1G 83 Linux
12. /dev/xvda5 2048 3905535 3903488 1.9G 82 Linux swap / Solaris
14. Partition table entries are not in disk order.

Im aktuellen Fall wurde unter '/dev/xvda1' eine logische Partition erstellte und "darin" die Swap-Partition '/dev/xvda5. Diese beiden Partitionen interessieren uns für das Vergrössern des unter '/' verfügbaren Speicherplatzes nicht und wir beachten diese beiden Partitionen nicht weiter.

Ich lösche nun als nächstes die zu kleine Partition "/dev/xvda2". Dieser Vorgang ist grundsätzlich unproblematisch, zumal ich hier keine Daten, sondern lediglich eine Partition lösche und dies gem. Begrüssung beim starten von "fdisk" vorerst lediglich im Cache erfasst wird, nicht aber tatsächlich geändert wird:

1. Welcome to fdisk (util-linux 2.29.2).
2. Changes will remain in memory only, until you decide to write them.
3. Be careful before using the write command.

Um sicher zu gehen, dass meine '/dev/xvda2' auch wirklich die Partitionsnummer 2 trägt, prüfe ich diese Partition:

1. Command (m for help): i
2. Partition number (1,2,5, default 5): 2
4. Device: /dev/xvda2
5. Start: 3905536
6. End: 251658239
7. Sectors: 247752704
8. Cylinders: 15422
9. Size: 118.1G
10. Id: 83
11. Type: Linux
12. Start-C/H/S: 243/27/41
13. End-C/H/S: 305/0/15

Perfekt, die Partition mit der Nummer 2 gilt für meinen Device '/dev/xvda2'. Ich lösche diese also mit d:

1. Command (m for help): d
2. Partition number (1,2,5, default 5): 2
4. Partition 2 has been deleted.

Die Situation sieht nun also wie folgt aus:

1. Command (m for help): p
2. Disk /dev/xvda: 240 GiB, 257698037760 bytes, 503316480 sectors
3. Units: sectors of 1 * 512 = 512 bytes
4. Sector size (logical/physical): 512 bytes / 512 bytes
5. I/O size (minimum/optimal): 512 bytes / 512 bytes
6. Disklabel type: dos
7. Disk identifier: 0x19ab9fb3
9. Device Boot Start End Sectors Size Id Type
10. /dev/xvda1 2046 3905535 3903490 1.9G 5 Extended
11. /dev/xvda5 2048 3905535 3903488 1.9G 82 Linux swap / Solaris

Ich lasse mir den ungenutzten nicht-partitionierten Speicherplatz anzeigen:

1. Command (m for help): F
2. Unpartitioned space /dev/xvda: 238.1 GiB, 255698403328 bytes, 499410944 sectors
3. Units: sectors of 1 * 512 = 512 bytes
4. Sector size (logical/physical): 512 bytes / 512 bytes
6. Start End Sectors Size
7. 3905536 503316479 499410944 238.1G
9. Command (m for help):

Wunderbar! Dann erstelle ich jetzt also auf '/dev/xvda2' die neue Partition über 238.1 GB:

1. Command (m for help): n
2. Partition type
3. p primary (0 primary, 1 extended, 3 free)
4. l logical (numbered from 5)
5. Select (default p): p
6. Partition number (2-4, default 2): 2
7. First sector (3905536-503316479, default 3905536):
8. Last sector, +sectors or +size{K,M,G,T,P} (3905536-503316479, default 503316479):
10. Created a new partition 2 of type 'Linux' and of size 238.1 GiB.
11. Partition #2 contains a xfs signature.
13. Do you want to remove the signature? [Y]es/[N]o: n
15. Command (m for help):

Schauen wir uns die neue Situation noch einmal an:

1. Command (m for help): p
3. Disk /dev/xvda: 240 GiB, 257698037760 bytes, 503316480 sectors
4. Units: sectors of 1 * 512 = 512 bytes
5. Sector size (logical/physical): 512 bytes / 512 bytes
6. I/O size (minimum/optimal): 512 bytes / 512 bytes
7. Disklabel type: dos
8. Disk identifier: 0x19ab9fb3
10. Device Boot Start End Sectors Size Id Type
11. /dev/xvda1 2046 3905535 3903490 1.9G 5 Extended
12. /dev/xvda2 3905536 503316479 499410944 238.1G 83 Linux
13. /dev/xvda5 2048 3905535 3903488 1.9G 82 Linux swap / Solaris
15. Partition table entries are not in disk order.

Das sieht wieder perfekt aus, so dass wir es wagen dürfen, die neue Partitionstabelle mit dem "w"_Kommando zu schreiben:

1. Command (m for help): w
3. The partition table has been altered.
4. Calling ioctl() to re-read partition table.
5. Re-reading the partition table failed.: Das Gerät oder die Ressource ist belegt
7. The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).

Linux VPS neustarten

Jetzt führen wir einen Neustart unseres Debian Linux Servers aus: # reboot

Ich lassen den Linux Server also neustarten und melde mich anschliessend erneut an, um die Situation abschliessend zu prüfen:

1. root@examplehost:~# fdisk -l
2. Disk /dev/xvda: 240 GiB, 257698037760 bytes, 503316480 sectors
3. Units: sectors of 1 * 512 = 512 bytes
4. Sector size (logical/physical): 512 bytes / 512 bytes
5. I/O size (minimum/optimal): 512 bytes / 512 bytes
6. Disklabel type: dos
7. Disk identifier: 0x19ab9fb3
9. Device Boot Start End Sectors Size Id Type
10. /dev/xvda1 2046 3905535 3903490 1.9G 5 Extended
11. /dev/xvda2 3905536 503316479 499410944 238.1G 83 Linux
12. /dev/xvda5 2048 3905535 3903488 1.9G 82 Linux swap / Solaris
14. Partition table entries are not in disk order.

Sehr schön! Aber offenbar weiss jetzt an dieser stelle das hier eingerichtete XFS File System noch nichts vom zusätzlichen Speicherplatz:

1. # df -h
2. Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
3. udev 3.9G 0 3.9G 0% /dev
4. tmpfs 797M 9.0M 788M 2% /run
5. /dev/xvda2 119G 1.1G 118G 1% /
6. tmpfs 3.9G 0 3.9G 0% /dev/shm
7. tmpfs 5.0M 0 5.0M 0% /run/lock
8. tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
9. tmpfs 797M 0 797M 0% /run/user/0

XFS-Dateisystem mit "xfs_growfs" vergrössern

Ich verwende nun also noch "xfs_growfs", um das Dateisystem auf meinem Linux Server unter '/' auf das Maximum zu vergrössern:

1. # resize2fs /dev/xvda2
2. resize2fs 1.43.4 (31-Jan-2017)
3. resize2fs: Ungültige magische Zahl im Superblock beim Versuch, /dev/xvda2 zu öffnen
4. Es kann kein gültiger Dateisystem-Superblock gefunden werden.
5. root@s1633:~# xfs_growfs -d /
6. meta-data=/dev/xvda2 isize=512 agcount=59, agsize=533248 blks
7. = sectsz=512 attr=2, projid32bit=1
8. = crc=1 finobt=1 spinodes=0 rmapbt=0
9. = reflink=0
10. data = bsize=4096 blocks=30969088, imaxpct=25
11. = sunit=0 swidth=0 blks
12. naming =version 2 bsize=4096 ascii-ci=0 ftype=1
13. log =Intern bsize=4096 blocks=2560, version=2
14. = sectsz=512 sunit=0 blks, lazy-count=1
15. realtime =keine extsz=4096 blocks=0, rtextents=0
16. Datenblöcke von 30969088 auf 62426368 geändert.

Und wie sieht es denn jetzt aus?

1. root@examplehost:~# df -h
2. Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
3. udev 3.9G 0 3.9G 0% /dev
4. tmpfs 797M 9.0M 788M 2% /run
5. /dev/xvda2 239G 118G 121G 51% /
6. tmpfs 3.9G 0 3.9G 0% /dev/shm
7. tmpfs 5.0M 0 5.0M 0% /run/lock
8. tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
9. tmpfs 797M 0 797M 0% /run/user/0

Sensationell: Es stehen unter '/' ab sofort total 240 GB Speicherplatz zur Verfügung und meine bereits vorhandenen Daten (118 GB) sind unverändert an Ort und Stelle verfügbar. Der Datenträger, resp. die entsprechende Partition ist wieder zu 49% frei.

Mit Begeisterung!
Andi Herzig