Ingrandire partizione LUKS contenuta in un disco immagine

31 maggio 2017 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.