Ingrandire partizione LUKS contenuta in un disco immagine

Data: 31 maggio 2017 Categoria: linux

Per il mio backup personale uso un contenitore LUKS all'interno di una immagine disco da circa 30GB. Vi sono memorizzati backup incrementali con versioni che risalgono a qualche mese fa. Con l'aumento dei dati da salvare lo spazio è diventato poco ma non volevo rinunciare a troppe versioni precedenti. Invece che fare un altro file immagine più grande e copiarci i dati ho provato ad aumentare le dimensioni di quello esistente.

Dopo essermi documentato su come ingrandire un'immagine disco e come ingrandire un contenitore LUKS sono arrivato a questa scaletta di operazioni:

  1. ridimensionare il file immagine
  2. ridimensionare il contenitore LUKS
  3. ridimensionare il filesystem.

Al termine sarà tutto come prima, ma più grande.

Ridimensionare il file immagine

I miei backup sono contenuti in un file di nome isaac:

$ ls -l isaac
-rw------- 1 massimo massimo 31457280000 mag 30 19:19 isaac

Il file immagine si può ridimensionare facilmente aggiungendo degli zeri con il comando dd. Io volevo aggiungere circa 10GB:

$ dd if=/dev/zero bs=1M count=10000 >> ./isaac
10000+0 record dentro
10000+0 record fuori
10485760000 byte (10 GB) copiati, 312,744 s, 33,5 MB/s

Controllando le dimensioni vedo che effettivamente il file isaac è passato da 30GB a 40GB:

$ ls -l isaac 
-rw------- 1 massimo massimo 41943040000 mag 31 17:15 isaac

Questa operazione equivale ad un ridimensionamento di una partizione.

Ridimensionare il contenitore LUKS

Per ridimensionare il contenitore LUKS bisogna aprirlo e poi usare resize:

$ sudo cryptsetup luksOpen isaac pippo
Inserire la passphrase per isaac: 

$ sudo cryptsetup resize pippo -v
Comando eseguito con successo.

Ridimensionare il filesystem

Al primo tentativo resize2fs mi ha chiesto di controllare prima il filesystem esistente:

$ sudo resize2fs /dev/mapper/pippo 
resize2fs 1.42.9 (4-Feb-2014)
Eseguire prima 'e2fsck -f /dev/mapper/pippo'.

Non so perché, forse è una procedura di sicurezza per evitare di intervenire su un filesystem danneggiato. Non ho approfondito e ho ubbidito:

$ sudo e2fsck -f /dev/mapper/pippo
e2fsck 1.42.9 (4-Feb-2014)
Passo 1: Controllo di inode, blocco(i) e dimensioni
Passo 2: Analisi della struttura delle directory
Passo 3: Controllo della connettività di directory
Pass 4: Controllo del numero dei riferimenti
Pass 5: Checking gruppo summary information
/dev/mapper/pippo: 259235/1921360 files (0.3% non-contiguous), 5015214/7679488 blocks

e poi finalmente

$ sudo resize2fs /dev/mapper/pippo 
resize2fs 1.42.9 (4-Feb-2014)
Resizing the filesystem on /dev/mapper/pippo to 10239488 (4k) blocks.
The filesystem on /dev/mapper/pippo is now 10239488 blocks long.

A questo punto controllo che tutto sia andato bene montando il contenitore e verificando che tutto sia a posto:

$ sudo mount -o loop /dev/mapper/pippo /mnt/luks/

$ df -h /mnt/luks/
File system     Dim. Usati Dispon. Uso% Montato su
/dev/loop1       39G   19G     18G  52% /mnt/luks

I file presenti sono leggibili senza errori. Ho provato ad eseguire un backup e tutto è andato bene. Per qualche mese non avrò problemi di spazio.