Crescer o disco sem reinstalar: LVM e resize na prática

O disco chegou a 92% e a limpeza já foi feita — não há mais log para rotacionar nem imagem antiga para remover. O que resta é aumentar o disco de fato.

A boa notícia é que isso não exige migrar para outra máquina nem reinstalar nada. Em Linux, crescer o armazenamento é uma sequência de comandos que roda com o sistema no ar, e na maioria dos casos sem nenhum downtime.

A parte que confunde é que existem várias camadas empilhadas, e todas precisam crescer, na ordem certa, de baixo para cima.

As camadas, e por que a ordem importa

Do hardware até o diretório onde você grava arquivo:

Aumentar o disco no painel e parar por aí é o erro mais comum: o df -h continua mostrando o tamanho antigo, e a conclusão apressada é que o provedor não aplicou a mudança. Aplicou — o espaço está lá, esperando as camadas de cima o reivindicarem.

Comece sempre olhando o que existe:

lsblk
df -hT
sudo vgs; sudo lvs        # se houver LVM

O lsblk mostra o tamanho do dispositivo; o df mostra o tamanho do sistema de arquivos. Quando os dois divergem, a diferença é exatamente o que falta reivindicar.

Antes de tudo: snapshot

Operação de partição é uma das poucas em que um erro de digitação destrói dados de forma imediata e irreversível. Escrever a tabela de partições errada não tem desfazer.

Tire um snapshot antes de começar. Leva segundos, custa pouco pelo tempo que fica guardado, e transforma um erro grave em cinco minutos de retorno.

Vale também anotar o estado atual, para comparação:

lsblk -f > /root/antes-do-resize.txt
sudo fdisk -l >> /root/antes-do-resize.txt

Sem LVM: o caso mais comum em VPS

A maioria das imagens de VPS usa uma partição única, sem LVM. O caminho tem dois passos.

Primeiro, crescer a partição para ocupar o espaço novo:

sudo apt install cloud-guest-utils      # fornece o growpart
sudo growpart /dev/sda 1

Repare no espaço entre o dispositivo e o número da partição — é a sintaxe do growpart, e escrever /dev/sda1 junto não funciona.

Depois, crescer o sistema de arquivos. O comando depende do tipo, que o df -hT informou:

# ext4
sudo resize2fs /dev/sda1

# XFS — precisa do ponto de montagem, não do dispositivo
sudo xfs_growfs /

Ambos funcionam com o sistema de arquivos montado e em uso. Não é preciso parar nada.

df -h /

Uma limitação que vale conhecer: XFS não pode ser reduzido. Se há chance de você querer diminuir depois, ext4 é a escolha mais flexível — ainda que reduzir exija desmontar, e portanto downtime.

Com LVM: dois passos a mais

Se vgs retornou algo, o servidor usa LVM, e há duas camadas intermediárias. Em compensação, o LVM traz flexibilidade que compensa o passo extra.

# 1. A partição cresce igual ao caso anterior
sudo growpart /dev/sda 3

# 2. O volume físico reconhece o espaço novo
sudo pvresize /dev/sda3
sudo pvs

# 3. O volume lógico toma o espaço livre
sudo lvextend -l +100%FREE /dev/mapper/vg0-root

# 4. E o sistema de arquivos, por último
sudo resize2fs /dev/mapper/vg0-root

O lvextend tem um atalho que junta os dois últimos passos:

sudo lvextend -r -l +100%FREE /dev/mapper/vg0-root

O -r chama a ferramenta correta de redimensionamento automaticamente, seja ext4 ou XFS. É a forma preferível, porque elimina a chance de esquecer o último passo — que é justamente o esquecimento que faz o df continuar igual.

Para distribuir entre vários volumes em vez de dar tudo a um:

sudo lvextend -r -L +20G /dev/mapper/vg0-var
sudo lvextend -r -L +10G /dev/mapper/vg0-home

Essa é a vantagem real do LVM: /var pode crescer sem tocar em /home, e o espaço não alocado fica reservado para quem precisar depois.

Quando o disco novo é outro disco

Às vezes a opção é adicionar um segundo dispositivo em vez de expandir o primeiro. Com LVM, ele é incorporado ao conjunto existente:

sudo pvcreate /dev/sdb
sudo vgextend vg0 /dev/sdb
sudo lvextend -r -l +100%FREE /dev/mapper/vg0-root

Sem LVM, o disco novo vira um ponto de montagem separado — o que costuma ser melhor de qualquer forma, porque isola o crescimento:

sudo mkfs.ext4 /dev/sdb
sudo mkdir -p /var/lib/postgresql
sudo mount /dev/sdb /var/lib/postgresql

Para persistir no boot, use o UUID e não o nome do dispositivo, que pode mudar de ordem entre reinicializações:

sudo blkid /dev/sdb
echo 'UUID=xxxx-xxxx /var/lib/postgresql ext4 defaults,nofail 0 2' | \
  sudo tee -a /etc/fstab
sudo mount -a

O nofail é importante: sem ele, um disco que não aparecer no boot impede a máquina de subir por completo, e você precisa do console de emergência para corrigir uma linha de texto.

Mover um diretório para o disco novo

Adicionar disco só resolve se o que ocupa espaço passar a viver nele. Mover um diretório com dados exige parar quem escreve:

sudo systemctl stop postgresql
sudo rsync -a /var/lib/postgresql/ /mnt/novo/
sudo mv /var/lib/postgresql /var/lib/postgresql.antigo
sudo mkdir /var/lib/postgresql
sudo mount /dev/sdb /var/lib/postgresql
sudo systemctl start postgresql

O rsync -a preserva dono, grupo e permissão — indispensável aqui, porque um diretório de banco com dono errado impede o serviço de subir. As flags e a armadilha da barra final estão detalhadas no artigo sobre rsync.

Mantenha o diretório antigo por alguns dias antes de remover. É a diferença entre conferir com calma e descobrir que faltou alguma coisa depois de apagar.

Quando dá errado

O `growpart` diz que não há espaço. O painel aplicou o aumento? Alguns provedores exigem reinício para o kernel enxergar o novo tamanho:

sudo partprobe /dev/sda
# se não resolver, reinicie

`resize2fs` reclama de tamanho. A partição não cresceu — o passo anterior não funcionou. Confira com lsblk.

A partição a crescer não é a última do disco. Aí growpart não ajuda, porque não há espaço contíguo depois dela. As saídas são adicionar outro disco, ou reparticionar com o sistema desmontado — que exige console e é bem mais arriscado.

Sistema não sobe depois. Quase sempre é /etc/fstab com entrada errada. O console no browser entra pela virtualização e continua funcionando com a rede fora, o que permite corrigir a linha e reiniciar.

Planejar em vez de reagir

Crescer disco às pressas funciona, mas é sempre a segunda melhor opção. Duas medidas evitam a corrida:

Acompanhe a curva de uso. Disco enche em linha reta durante semanas, e o gráfico mostra a data em que o limite chega — com folga para agir em horário comercial, e não às três da manhã. O artigo sobre disco cheio traz o script de alerta e o diagnóstico do que está ocupando.

E questione se o dado precisa mesmo estar no disco da VM. Dump antigo, mídia enviada por usuário e arquivo histórico custam bem mais em disco de máquina que em bucket S3, e ainda somem junto com a VM em caso de perda. Mover isso costuma resolver o problema de forma mais barata que qualquer expansão.

Vale a pena adotar LVM?

Se a sua imagem não usa LVM, a pergunta aparece na primeira vez que o disco enche. A resposta honesta depende do tamanho da operação.

Em servidor único com uma partição, LVM acrescenta uma camada de complexidade para resolver um problema que o growpart já resolve. A expansão simples funciona bem, e quem opera a máquina uma vez por trimestre não quer aprender mais uma ferramenta.

LVM passa a compensar quando aparece alguma destas necessidades:

• Vários volumes com crescimento independente. /var/lib/postgresql grande e /home pequeno, cada um evoluindo no seu ritmo.
• Snapshot no nível do bloco, para congelar o estado antes de uma migração de esquema e voltar em segundos.
• Somar discos em um único espaço lógico.
• Mover dados entre discos sem downtime, com pvmove.

Adotar LVM depois exige reinstalar ou migrar para uma máquina nova — não é conversão no lugar. Por isso a decisão vale ser tomada ao provisionar, e não quando o disco já está em 92%.

Para quem está montando um servidor de banco agora, a combinação que costuma envelhecer bem é LVM com volumes separados para sistema, dados e log, deixando espaço não alocado no grupo. O espaço reservado não custa nada enquanto não é usado e elimina a corrida do dia em que um deles crescer.