Amazon Web Services (AWS) fournit un service de serveurs virtuels extensibles (Elastic Cloud, aka EC2) qui permet notamment de démarrer des serveurs Ubuntu à partir d’images disque complètes (sans installation). Ces serveurs utilisent, pour la partie stockage disque, des volumes EBS (Elastic Block Store), qui sont en quelque sorte des disques durs virtuels, de taille spécifiée par l’utilisateur, et facturés à l’usage en fonction de l’espace de stockage. S’il est très facile d’augmenter la taille de ces volumes, lorsque vos besoins augmentent, il est en revanche assez complexe et pénible de réduire leur taille. Sauf que, si vous avez des Go inutilisés sur un volume, et que vous gardez en plus des sauvegardes intégrales du disque (snapshots), chaque Go en trop vous est refacturé sur le volume EBS en cours d’utilisation, mais aussi sur toutes vos sauvegardes.
Note
Cette page a été initialement rédigée comme aide-mémoire personnel. Aucune des méthodes mentionnées n’a aboutie à un disque redimensionné fonctionnel et il faudrait débugger les erreurs résiduelles. Le débuggage distant de volume virtuels est une plaie et j’ai fini par quitter AWS EC2 de toute façon pour louer un VPS dédié, pour des raisons de coûts/performance. Par manque de temps, je publie tout de même mes notes pour ce qu’elles valent, car les étapes détaillées ici sont des préalables nécessaires. Gardez à l’esprit qu’il faudra simplement les compléter vous-même pour aboutir à un système utilisable.Introduction
La méthode détaillée ici n’est pas propre à AWS, mais s’applique pour toute tentative de copie intégrale de disque contenant l’OS vers un autre disque de taille différente qui sera utilisé dans la même machine.
L’incohérence des tailles d’origine et de destination nous empêche d’utiliser des méthodes simples et rapides comme la création d’image disque.
À la place, il va nous falloir recréer manuellement la table des partitions et copier tous les fichiers en respectant leurs propriétés système initiales (date, propriétaire et permissions).
Prérequis
On attend un serveur Linux (préférablement Ubuntu 22.04) installé sur une instance EC2 démarrée, et connectée à un volume EBS. Tout autre système qu’Ubuntu 22.04 pourrait demander des adaptations plus ou moins importantes de la méthode détaillée ici. Vous devez avoir un accès SSH vers le serveur.
Préparation
Taille de disque requise
Démarrez une console SSH vers votre serveur, puis exécutez :
1df -HOn obtient par exemple :
Ici, on utilise un peu plus de 14 Go, c’est donc la taille minimale du nouveau volume.
Structure de la table de partitions
Exécutez :
1lsblkOn obtient par exemple :
On a donc 3 partitions sur le volume nvme1n1. Les noms des disques et partitions peuvent varier sur votre système.
Exécutez ensuite :
1sudo fdisk -lOn obtient par exemple :
1Disk /dev/nvme1n1: 32 GiB, 34359738368 bytes, 67108864 sectors
2Disk model: Amazon Elastic Block Store
3Units: sectors of 1 * 512 = 512 bytes
4Sector size (logical/physical): 512 bytes / 512 bytes
5I/O size (minimum/optimal): 4096 bytes / 4096 bytes
6Disklabel type: gpt
7Disk identifier: 3686890E-384D-47FF-8376-B554064EE59B
8
9Device Start End Sectors Size Type
10/dev/nvme1n1p1 227328 67108830 66881503 31.9G Linux filesystem
11/dev/nvme1n1p14 2048 10239 8192 4M BIOS boot
12/dev/nvme1n1p15 10240 227327 217088 106M EFI System
13
14Partition table entries are not in disk order.Si l’on résume, on apprend donc que le volume est de type GPT et a 3 partitions, dans l’ordre du disque :
/dev/nvme1n1p14, partition BIOS sans point de montage, d’index 14,/dev/nvme1n1p15, partition EFI montée comme/boot/efi, d’index 15,/dev/nvme1n1p1, partition EXT4 montée comme/, d’index 1.
Créer un nouveau volume
Dans votre console EC2 , créez un nouveau volume EBS de la taille minimale trouvée ci-dessus (ici, 15 Go), puis attachez le sur votre instance en fonctionnement.
Warning
Assurez vous de créer votre nouveau volume dans la même région AWS que votre instance, sinon il sera inaccessible.Dupliquer le volume actuel
Copier le volume contenant le système d’exploitation en fonctionnement, directement vers un nouveau volume, n’est pas conseillé et peut créer des incohérences. On va donc créer un doublon du volume, qui sera copié “froid”, dans la console EC2, en créant un snapshot du volume, puis un nouveau volume à partir de ce snapshot. Lorsque c’est fait, attachez le nouveau volume à votre instance.
Méthode 1 : création d’un nouveau système de fichiers miroir
Dans cette variante, on créée une table de partitions sur le volume cible qui reproduit en tout point la table de partition d’origine (sauf pour les tailles), et on copie les données.
Créer la nouvelle table de partitions
Une fois le nouveau volume EBS attaché à l’instance, exécutez depuis la console SSH de celle-ci :
1lsblkOn obtiendra par exemple :
Notre nouveau disque est donc identifié comme nvme0n1.
Exécutez ensuite blkid :
1/dev/nvme1n1p1: LABEL="cloudimg-rootfs" UUID="767f2b75-d030-4999-951c-d4ab6b37f31f" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="978fa93b-fe56-4d1d-8615-58ea7b0e0ea4"
2/dev/nvme1n1p15: LABEL_FATBOOT="UEFI" LABEL="UEFI" UUID="83EA-FFE2" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="0442e197-3c18-4136-9cbb-395ca6412ba2"Ceci nous donne le label de chacune des partitions d’origine (cloudimg-rootfs et UEFI).
Pour créer une nouvelle table GPT, exécutez donc :
1sudo gdisk /dev/nvme0n1puis tapez o pour créer une nouvelle table vierge. L’idée est ensuite de reproduire la table de partitions du disque actuel :
Note
Ubuntu (et AWS) permettent d’avoir un volume entièrement chiffré. Dans cette configuration, l’amorçage (partition/boot/efi) doit être séparé du disque chiffré, et donc non chiffré lui-même. La fonctionnalité est optionnelle, mais toutes les images disques utilisent donc cette configuration.- Partition BIOS :
- taper
n(pour “nouvelle partition”), - tapez
14(index de la partition) - choisissez le premier secteur par défaut,
- tapez
+4Mpour la taille, - tapez le code hexadécimal
ef02pour créer une partition de type BIOS,
- taper
- Partition
/boot/efi:- tapez
n, - puis
15, - choisissez le premier secteur par défaut
- tapez
+106Mpour la taille, - tapez le code hexadécimal
ef00pour créer une partition de type EFI, - tapez
c(pour “changer le nom de la partition), - tapez
15, - saisissez
UEFI(ou adaptez au label retourné par la commandeblkidprécédemment),
- tapez
- Partition racine
/:- tapez
n, - puis
1, - laissez l’emplacement du premier secteur par défaut,
- laissez l’emplacement du dernier secteur par défaut (tout l’espace disque restant),
- laissez le code hexadécimal par défaut (système de fichier Linux),
- tapez
c, - tapez
1, - saisissez
cloudimg-rootfs(adaptez encore le label si besoin).
- tapez
- Allez dans le mode “expert command” en tapant
x:- tapez
cpour changer lePARTUUID, - tapez
15pour la partition EFI, - saissisez le
PARTUUIDretourné parblkidpour la partition EFI d’origine - recommencez pour la partition root (
1).
- tapez
Finissez avec la commande w (pour “write”), qui va écrire le nouveau partitionnement.
Vérifions que tout s’est bien passé. Exécutez lsblk :
1nvme1n1 259:0 0 32G 0 disk
2├─nvme1n1p1 259:2 0 31.9G 0 part /
3├─nvme1n1p14 259:3 0 4M 0 part
4└─nvme1n1p15 259:4 0 106M 0 part /boot/efi
5nvme0n1 259:1 0 15G 0 disk
6├─nvme0n1p1 259:7 0 14.9G 0 part
7├─nvme0n1p14 259:8 0 4M 0 part
8└─nvme0n1p15 259:13 0 106M 0 part
9nvme2n1 259:5 0 32G 0 disk
10├─nvme2n1p1 259:6 0 31.9G 0 part
11├─nvme2n1p14 259:9 0 4M 0 part
12└─nvme2n1p15 259:10 0 106M 0 partExécutez sudo fdisk -l :
1Disk /dev/nvme0n1: 15 GiB, 16106127360 bytes, 31457280 sectors
2Disk model: Amazon Elastic Block Store
3Units: sectors of 1 * 512 = 512 bytes
4Sector size (logical/physical): 512 bytes / 512 bytes
5I/O size (minimum/optimal): 4096 bytes / 4096 bytes
6Disklabel type: gpt
7Disk identifier: 2C6C2F26-721F-49F5-B234-F15719768825
8
9Device Start End Sectors Size Type
10/dev/nvme0n1p1 227328 31457246 31229919 14.9G Linux filesystem
11/dev/nvme0n1p14 2048 10239 8192 4M BIOS boot
12/dev/nvme0n1p15 10240 227327 217088 106M EFI SystemNote
Lorsqu’on redimensionne un volume EBS dans la console AWS, c’est seulement la première partition (racine) qui est redimensionnée. On s’efforce donc de respecter l’ordre des partitions ici.Il faut ensuite créer le système de fichier pour nos deux nouvelles partitions :
Dupliquer les données
Monter les partitions
À ce stade, vous devriez avoir 3 volumes attachés à votre instance :
nvme1m1, le système hôte, qui contient le volume trop grand, et qui fournit l’OS avec lequel nous interagissons depuis le shell SSH. Il est identifiable par le fait que ses partitions sont montées en tant que/et/boot/efi.nvme2n1, le doublon du volume hôte, chargé à froid (l’OS n’est pas actif),nvme0n1, le nouveau volume cible, plus petit, et vide à ce stade.
Les numéros peuvent changer dans votre cas. On va donc créer les nouveaux points de montage :
Puis on monte les partitions racines :
On recommence avec les partitions EFI :
Et on monte tout ça :
À ce stade, lsblk retourne :
1NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
2nvme1n1 259:0 0 32G 0 disk
3├─nvme1n1p1 259:2 0 31.9G 0 part /
4├─nvme1n1p14 259:3 0 4M 0 part
5└─nvme1n1p15 259:4 0 106M 0 part /boot/efi
6nvme0n1 259:1 0 15G 0 disk
7├─nvme0n1p1 259:7 0 14.9G 0 part /mnt/newroot
8├─nvme0n1p14 259:8 0 4M 0 part
9└─nvme0n1p15 259:13 0 106M 0 part /mnt/newefi
10nvme2n1 259:5 0 32G 0 disk
11├─nvme2n1p1 259:6 0 31.9G 0 part /mnt/oldroot
12├─nvme2n1p14 259:9 0 4M 0 part
13└─nvme2n1p15 259:10 0 106M 0 part /mnt/oldefiCopier le contenu des partitions
Exécutez :
Il est capital de respecter les slash ici car on effectue une copie récursive du contenu de /mnt/oldroot/, oublier le dernier slash reviendrait donc à copier seulement le répertoire de plus haut niveau.
On traite ensuite le contenu de la partition BIOS, qui n’est pas un système de fichier :
1sudo dd if=/dev/nvme2n1p14 of=/dev/nvme0n1p14 bs=512Vérifier les nouvelles partitions
Démontez les partitions du nouveau volume :
Puis exécutez e2fsck sur la nouvelle partition racine (EXT4) et dosfsck sur la partition EFI (FAT32) :
Ces deux commandes vérifient l’intégrité des volumes et sont des préalables requis par la commande tune2fs qu’on exécutera plus bas.
Réparer l’amorçage du volume
Les identifiants des tables et partitions (UUID) de notre nouveau volume ont changé. Le fichier /etc/fstab copié sur le nouveau volume n’est donc plus valide, et GRUB doit être réinstallé.
fstab
Affichez le contenu du fichier /etc/fstab. Par exemple :
On voit ici que les volumes sont références par label. On va donc s’assurer que les labels du nouveau volume sont corrects :
On va ensuite ré-appliquer l’UUID de l’ancien volume racine sur le nouveau (voir l’UUID de l’ancien dans la sortie de blkid ci-dessus) :
On peut alors vérifier que tout s’est bien passé avec la commande lsblk -o name,mountpoint,label,size,uuid :
1NAME MOUNTPOINT LABEL SIZE UUID
2nvme0n1 15G
3├─nvme0n1p1 cloudimg-rootfs 14.9G 767f2b75-d030-4999-951c-d4ab6b37f31f
4├─nvme0n1p14 4M 0e5538f3-11a2-4e5d-93a9-682f1979665e
5└─nvme0n1p15 UEFI 106M 83EA-FFE2
6nvme0n1 32G
7├─nvme1n1p1 / cloudimg-rootfs 31.9G 767f2b75-d030-4999-951c-d4ab6b37f31f
8├─nvme1n1p14 4M
9└─nvme1n1p15 /boot/efi UEFI 106M 83EA-FFE2
10nvme2n1 32G
11├─nvme2n1p1 /mnt/oldroot cloudimg-rootfs 31.9G 767f2b75-d030-4999-951c-d4ab6b37f31f
12├─nvme2n1p14 4M
13└─nvme2n1p15 /mnt/oldefi UEFI 106M 83EA-FFE2On a donc adéquation entre les labels et les UUID, sur tous les clones.
Réinstaller GRUB
Vous remarquerez qu’on n’a rien fait sur la partition BOOT de 4 Mo. C’est normal : c’est GRUB qui s’en charge. La complexité est ici qu’on ne peut réinstaller GRUB que depuis l’intérieur du système, c’est à dire depuis l’intérieur de notre volume redimensionné. Sauf qu’en l’état, il ne bootera pas. Il nous faut donc chrooter depuis l’instance hôte avant de relancer l’installation de Grub.
On remonte tout dans l’ordre :
Puis on monte le système invité à la place du système hôte :
Puis on réinstalle GRUB :
Puis on un-chroot :
Relancer l’instance avec le nouveau volume
Éteignez votre instance, détachez tous les volumes, puis ré-attachez votre nouveau volume réduit à l’emplacement /dev/sda1.
Méthode 2 : redimensionnement des partitions à chaud
Dans cette variante, on redimensionne directement le système de fichier puis les partitions de notre disque. L’avantage est de ne pas avoir à réinstaller GRUB ni le chargeur d’amorçage, l’inconvénient est de devoir calculer les nombres de secteurs à la main. Cette méthode se rapproche, en ligne de commande, de ce qu’on fait avec Gparted en interface graphique (et avec assistance). Travaillez dans tous les cas sur un volume dupliqué à partir d’un snapshot du volume initial.
Les commandes sont données directement, voir leurs explications dans la méthode précédente.
Lister les disques
1$ lsblk
2NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
3nvme0n1 259:0 0 32G 0 disk
4├─nvme0n1p1 259:1 0 31.9G 0 part /
5├─nvme0n1p14 259:2 0 4M 0 part
6└─nvme0n1p15 259:3 0 106M 0 part /boot/efi
7nvme1n1 259:4 0 32G 0 disk
8├─nvme1n1p1 259:5 0 31.9G 0 part
9├─nvme1n1p14 259:6 0 4M 0 part
10└─nvme1n1p15 259:7 0 106M 0 part
11nvme2n1 259:8 0 15G 0 disk
12├─nvme2n1p1 259:9 0 14.9G 0 part
13├─nvme2n1p14 259:10 0 4M 0 part
14└─nvme2n1p15 259:11 0 106M 0 partLister les partitions
1$ sudo gdisk /dev/nvme1n1
2GPT fdisk (gdisk) version 1.0.8
3
4Partition table scan:
5 MBR: protective
6 BSD: not present
7 APM: not present
8 GPT: present
9
10Found valid GPT with protective MBR; using GPT.
11
12Command (? for help): p
13Disk /dev/nvme1n1: 67108864 sectors, 32.0 GiB
14Model: Amazon Elastic Block Store
15Sector size (logical/physical): 512/512 bytes
16Disk identifier (GUID): 3686890E-384D-47FF-8376-B554064EE59B
17Partition table holds up to 128 entries
18Main partition table begins at sector 2 and ends at sector 33
19First usable sector is 34, last usable sector is 67108830
20Partitions will be aligned on 2048-sector boundaries
21Total free space is 2014 sectors (1007.0 KiB)
22
23Number Start (sector) End (sector) Size Code Name
24 1 227328 67108830 31.9 GiB 8300
25 14 2048 10239 4.0 MiB EF02
26 15 10240 227327 106.0 MiB EF00Vérifier la partition à redimensionner
Vérifier la taille de partition minimale
Note : la taille est donnée en blocs.
1sudo dumpe2fs -h /dev/nvme1n1p1
2dumpe2fs 1.46.5 (30-Dec-2021)
3Filesystem volume name: cloudimg-rootfs
4Last mounted on: /
5Filesystem UUID: 767f2b75-d030-4999-951c-d4ab6b37f31f
6Filesystem magic number: 0xEF53
7Filesystem revision #: 1 (dynamic)
8Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
9Filesystem flags: signed_directory_hash
10Default mount options: user_xattr acl
11Filesystem state: clean
12Errors behavior: Continue
13Filesystem OS type: Linux
14Inode count: 4128768
15Block count: 8360187
16Reserved block count: 0
17Overhead clusters: 278028
18Free blocks: 4876429
19Free inodes: 3870057
20First block: 0
21Block size: 4096
22Fragment size: 4096Redimensionner le système de fichiers
Recréer la partition
Un peu de calcul… On a redimensionné le système de fichier (à l’intérieur de la partition) à 3854448 blocks de 4096 bits, donc on a un système de fichiers de 15787819008 bits, soit 14.7 GiB (on divise le nombre de bits par $2^{30}$). Avec les 100 Mo de partitions de boot, on est sur une taille de volume minimale pour le nouveau système de 14.8 GiB. AWS EC2 ne permet que des tailles arrondies au GiB entier, on va donc se donner un peu de marge de sécurité et monter à 16 GiB.
On vérifiée que gdisk utilise une taille de secteur de 512 octets (4096 bits), donc un secteur gdisk équivaut à un bloc de ext4.
1$ sudo gdisk /dev/nvme1n1
2GPT fdisk (gdisk) version 1.0.8
3
4Partition table scan:
5 MBR: protective
6 BSD: not present
7 APM: not present
8 GPT: present
9
10Found valid GPT with protective MBR; using GPT.
11
12Command (? for help): p
13Disk /dev/nvme1n1: 67108864 sectors, 32.0 GiB
14Model: Amazon Elastic Block Store
15Sector size (logical/physical): 512/512 bytes
16Disk identifier (GUID): 3686890E-384D-47FF-8376-B554064EE59B
17Partition table holds up to 128 entries
18Main partition table begins at sector 2 and ends at sector 33
19First usable sector is 34, last usable sector is 67108830
20Partitions will be aligned on 2048-sector boundaries
21Total free space is 63029068 sectors (30.1 GiB)
22
23Number Start (sector) End (sector) Size Code Name
24 1 227328 4081776 1.8 GiB 8300 Linux filesystem
25 14 2048 10239 4.0 MiB EF02
26 15 10240 227327 106.0 MiB EF00
27
28Command (? for help): d
29Partition number (1-15): 1
30
31Command (? for help): n
32Partition number (1-128, default 1): 1
33First sector (34-67108830, default = 227328) or {+-}size{KMGTP}:
34Last sector (227328-67108830, default = 67108830) or {+-}size{KMGTP}: +15G
35Current type is 8300 (Linux filesystem)
36Hex code or GUID (L to show codes, Enter = 8300):
37Changed type of partition to 'Linux filesystem'Méthode 3 : repartir d’une image disque
Notre principal problème, dans les méthodes précédentes, est de conserver les UID des partitions et le chargeur d’amorçage intact pour éviter d’endommager GRUB et de rendre le volume non bootable, tout en évitant d’endommager les systèmes de fichiers. Je n’ai pas réussi, pour des raisons difficiles à identifier sans accès physique au serveur.
La version la plus simple est de repartir d’une image Linux AWS vierge, dimensionnée à la taille souhaitée. Ensuite, il suffit de copier l’intégralité de la partition root / d’origine vers le nouveau volume, à l’exception du fichier /etc/fstab et du répertoire /boot, qui contiennent des références vers les UID du disque cible. (Non testé).
Conclusion
C’est l’enfer. N’hésitez pas à dimensionner au plus juste vos volumes EBS car il suffit de quelques clics dans la console AWS pour les agrandir, alors que l’inverse est une sainte ostie de purge. Dans tous les cas, AWS EC2 a le mérite d’être flexible et adaptable, mais est plus cher qu’un serveur VPS à performances égales. À mon avis, il n’est pertinent que pour des besoins très réduits (en remplacement d’un serveur basé sur Raspberry Pie à domicile, par exemple), ou pour des instances en fonctionnement intermittent (lancées à la demande par des scripts, par exemple pour effectuer des tâches planifiées qui demandent un OS complet, pour lesquelles AWS Lambda ne suffirait pas).
