LVM no Ubuntu Server: crie e redimensione volumes online

O particionamento tradicional do Linux trava o tamanho de uma partição no momento em que ela é criada: para crescer, normalmente é preciso desmontar o disco, redimensionar com uma ferramenta externa e torcer para não corromper dados. O LVM (Logical Volume Manager) resolve isso com uma camada entre o disco físico e o sistema de arquivos: um volume lógico pode crescer, encolher ou ganhar espaço de um disco novo com o sistema em produção, sem reboot. Este guia mostra como montar a pilha completa — disco físico, grupo de volumes e volume lógico — em um Ubuntu Server, redimensionar depois e tirar um snapshot consistente para backup.

Por que usar LVM em vez de particionar direto

Três motivos concretos para colocar o LVM entre o disco e o sistema de arquivos:

• Redimensionamento a quente. lvextend seguido de resize2fs ou xfs_growfs cresce a partição com o sistema montado e em uso.
• Agregação de discos. Um grupo de volumes (VG) pode somar vários discos físicos (PVs) em um único espaço lógico — útil quando o disco original enche e a VM só aceita volume adicional, não troca do disco existente.
• Snapshot nativo. O LVM cria uma cópia point-in-time do volume em segundos, útil para backup consistente de bancos de dados ou antes de uma atualização arriscada.

O custo é uma camada extra de abstração e uma pequena sobrecarga de I/O (geralmente abaixo de 2% em discos SSD/NVMe) — aceitável na maioria dos servidores de aplicação e arquivos.

Pré-requisitos

• Ubuntu Server 22.04 ou 24.04 com acesso root (sudo).
• Um disco ou partição livre, sem dados importantes — os comandos abaixo apagam o que estiver nele. Neste guia, /dev/sdb.
• Pacote lvm2 instalado: sudo apt update && sudo apt install -y lvm2.

Passo a passo: criar a pilha PV → VG → LV

1. Confirme o disco disponível antes de tocar nele:

   lsblk

2. Transforme o disco em um Physical Volume (PV) — isso grava os metadados do LVM no início do disco:

   sudo pvcreate /dev/sdb

3. Crie o Volume Group (VG), que agrupa um ou mais PVs em um pool de espaço:

   sudo vgcreate vg_dados /dev/sdb

4. Crie o Logical Volume (LV) dentro do VG. Aqui reservamos 80% do espaço e deixamos 20% de reserva livre no VG para snapshots futuros:

   sudo lvcreate -l 80%VG -n lv_dados vg_dados

5. Formate o volume lógico com o sistema de arquivos escolhido (ext4 neste exemplo; troque por mkfs.xfs se preferir XFS):

   sudo mkfs.ext4 /dev/vg_dados/lv_dados

6. Monte o volume e torne o ponto de montagem permanente. Primeiro crie o diretório e monte manualmente:

   sudo mkdir -p /mnt/dados
   sudo mount /dev/vg_dados/lv_dados /mnt/dados

   Depois adicione ao /etc/fstab usando o UUID (nunca o caminho /dev/sdX, que pode mudar entre boots):

   sudo blkid /dev/vg_dados/lv_dados

   Copie o UUID retornado e adicione esta linha ao /etc/fstab:

   UUID=<uuid-copiado>  /mnt/dados  ext4  defaults  0  2

Redimensionar o volume lógico sem desmontar

Esse é o motivo prático de usar LVM. Para crescer o volume usando o espaço livre que sobrou no VG:

sudo lvextend -l +50%FREE /dev/vg_dados/lv_dados

Depois de estender o LV, o sistema de arquivos ainda está no tamanho antigo — é preciso avisar o kernel. Em ext4:

sudo resize2fs /dev/vg_dados/lv_dados

Em XFS, o comando é outro e não aceita encolher, só crescer:

sudo xfs_growfs /mnt/dados

Para adicionar um disco físico novo ao VG quando o espaço acabar (sem precisar de outro servidor):

sudo pvcreate /dev/sdc
sudo vgextend vg_dados /dev/sdc

Snapshot para backup consistente

Um snapshot LVM congela o estado do volume no instante da criação, mesmo com escritas acontecendo. Por isso vale rodar um fsync ou pausar a aplicação por um segundo antes de criar:

sudo lvcreate -l 5%VG -s -n lv_dados_snap /dev/vg_dados/lv_dados

Monte o snapshot em outro ponto para copiar os arquivos sem travar o volume de produção:

sudo mkdir -p /mnt/snap
sudo mount -o ro /dev/vg_dados/lv_dados_snap /mnt/snap

Depois de copiar o backup, desmonte e remova o snapshot — ele consome espaço do VG a cada escrita no volume original e não deve ficar ativo indefinidamente:

sudo umount /mnt/snap
sudo lvremove /dev/vg_dados/lv_dados_snap

Erros comuns

• VG sem espaço livre para snapshot. Se o LV ocupar 100% do VG, lvcreate -s falha. É por isso que o passo 4 reservou 20% livre.
• Esquecer o resize2fs/xfs_growfs. O lvextend sozinho cresce o volume lógico, mas o sistema de arquivos continua no tamanho antigo até o comando de resize ser executado.
• Usar /dev/sdX no fstab. A ordem dos discos pode mudar entre boots; sempre referencie por UUID.

Perguntas frequentes

LVM funciona com SSD e NVMe sem perda de performance?
Sim. A sobrecarga do LVM é de mapeamento de blocos, não de processamento pesado — em discos modernos a diferença fica dentro da margem de erro em benchmarks de I/O.

É possível converter uma partição ext4 já em uso para LVM sem perder dados?
Não diretamente. É preciso criar o PV/VG/LV em um disco novo, copiar os dados com rsync ou dd e só então remontar — não existe conversão in-place segura para a partição raiz sem ferramentas adicionais.

LVM substitui RAID?
Não. São camadas diferentes: RAID protege contra falha de disco (redundância), LVM organiza e redimensiona o espaço. Os dois combinam bem — RAID por baixo, LVM por cima.

Dá para encolher um volume lógico?
Em ext4 sim, com resize2fs para o tamanho menor antes do lvreduce. Em XFS não — o sistema de arquivos só cresce, nunca encolhe.

O que acontece se o VG ficar sem espaço durante um snapshot ativo?
O snapshot é invalidado automaticamente e fica inutilizável. É outro motivo para não deixar snapshots LVM ativos por muito tempo.

Conclusão

Com PV, VG e LV montados, qualquer crescimento de disco em produção vira um lvextend mais um resize2fs, sem downtime e sem reparticionar nada. Se o servidor já está em produção com partições tradicionais, planeje a migração para um disco novo com LVM na próxima manutenção programada — o ganho de flexibilidade compensa o trabalho inicial.