Como aumentar o disco da VPS sem perder dados

Resposta direta

Para aumentar o disco da VPS sem perder dados, primeiro amplie o volume virtual no painel do provedor. Depois, confirme o novo tamanho com lsblk, estenda a partição com growpart e, por último, aumente o sistema de arquivos. Em uma VPS com ext4 sobre /dev/vda1, a sequência mais comum é growpart /dev/vda 1 seguida de resize2fs /dev/vda1. Em XFS, use xfs_growfs apontando para o ponto de montagem. Se houver LVM, também será necessário executar pvresize e lvextend. Faça backup ou snapshot antes da mudança, registre a tabela de partições e nunca copie comandos sem confirmar os nomes dos dispositivos no servidor.

As três camadas que precisam ser ampliadas

A expansão costuma envolver três camadas independentes. O volume virtual é o disco apresentado pelo provedor, como um dispositivo de 80 GB que passa a ter 160 GB. A partição, por exemplo /dev/vda1 ou /dev/nvme0n1p1, pode continuar limitada aos 80 GB antigos. O sistema de arquivos ext4 ou XFS também preserva o tamanho anterior até receber o comando adequado.

Isso explica por que aumentar o plano não necessariamente libera espaço no df -h. O painel pode mostrar 160 GB, enquanto o Linux ainda enxerga uma partição de 80 GB. Em outro cenário, lsblk mostra a partição ampliada, mas df -hT continua no tamanho antigo porque falta redimensionar o sistema de arquivos.

Pense em uma VPS Ubuntu com disco /dev/vda, raiz em /dev/vda1 e ext4. Se o provedor expandir o disco de 50 GB para 100 GB, a operação deve seguir a ordem painel, partição e sistema de arquivos. Em um servidor Rocky Linux com XFS e LVM, o caminho será painel, partição, volume físico, volume lógico e XFS. A ordem reduz ambiguidades e permite validar cada etapa antes de avançar.

Resumo rápido

• Faça backup externo ou snapshot antes de alterar partições, mesmo quando a expansão puder ocorrer online.
• Use lsblk -f, df -hT, findmnt / e os comandos do LVM para identificar o layout real.
• Expanda primeiro o volume no painel do provedor e só depois altere partição e sistema de arquivos.
• Para uma partição comum, growpart /dev/vda 1 é mais seguro que recriar manualmente a entrada no fdisk.
• Em ext4, use resize2fs no dispositivo; em XFS, use xfs_growfs no ponto de montagem.
• Em LVM, execute pvresize e lvextend, preferencialmente validando o espaço livre entre os comandos.
• Confira capacidade, inodes, logs do kernel e funcionamento da aplicação antes de considerar a mudança concluída.

A sequência não muda apenas porque o disco é SSD ou NVMe. O tipo de armazenamento influencia latência e quantidade de operações de entrada e saída, mas não elimina as camadas lógicas do Linux. Se a expansão faz parte de uma decisão maior de capacidade, o artigo sobre como escolher CPU, RAM e NVMe ajuda a separar falta de espaço de gargalos de memória, processamento ou I/O.

Considere dois exemplos. Em uma VPS de aplicação, o diretório /var/lib/docker pode consumir 70 GB de um disco de 80 GB. Aumentar o volume para 160 GB resolve a capacidade imediata, mas imagens antigas e logs sem rotação continuarão crescendo. Em um servidor PostgreSQL, ampliar /var/lib/postgresql exige também conferir espaço temporário, retenção de WAL e duração do backup. Expandir o disco compra capacidade, não corrige sozinho políticas ruins de retenção.

Também não presuma que toda expansão é reversível. Ext4 e XFS podem crescer online em muitos layouts, porém reduzir um volume é uma operação diferente. XFS não oferece redução convencional, e diminuir ext4 exige desmontagem e planejamento cuidadoso. Escolha o novo tamanho com alguma folga, monitore o uso após a mudança e evite transformar uma correção emergencial em outra intervenção arriscada poucos dias depois.

Prepare a VPS antes de alterar o armazenamento

Mapeie disco, partição e sistema de arquivos

Comece registrando o estado atual. Os comandos abaixo mostram dispositivos, sistemas de arquivos, pontos de montagem e espaço disponível:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
lsblk -f
df -hT
findmnt /
sudo fdisk -l

Uma saída com /dev/vda de 100 GB e /dev/vda1 de 50 GB indica espaço não alocado depois da partição. Já um disco /dev/sda com uma partição LVM exige outra leitura. Confirme com:

sudo pvs
sudo vgs
sudo lvs -a -o +devices

Se / estiver em /dev/mapper/ubuntu--vg-ubuntu--lv, não execute resize2fs diretamente na partição física sem entender o encadeamento. Nesse caso, a partição contém um volume físico LVM, que alimenta um grupo de volumes e um volume lógico. Cada camada precisa reconhecer o espaço adicional.

Outro cenário frequente é um volume de dados separado, montado em /srv ou /var/lib/docker. Use findmnt /srv para descobrir o dispositivo correspondente. Não confie apenas na ordem exibida no painel, pois o primeiro disco adicional pode aparecer como /dev/vdb, /dev/sdb ou /dev/nvme1n1, dependendo da virtualização.

Crie um ponto de recuperação consistente

Um snapshot facilita a reversão de erros, mas não substitui uma cópia externa. Antes de criar o snapshot, reduza gravações e sincronize buffers com sync. Para bancos de dados, use o mecanismo de backup da própria aplicação ou coloque-a em modo consistente. Copiar os arquivos de um PostgreSQL ativo como se fossem documentos comuns pode gerar uma restauração inutilizável.

Para uma aplicação pequena, uma estratégia prática é gerar um dump do banco, copiar configurações de /etc e manter um backup externo com Restic ou Borg. O conteúdo sobre backups de VPS com Restic e Borg detalha retenção, criptografia e testes de restauração. Se o provedor oferecer snapshot, confirme escopo, cobrança, retenção e procedimento de recuperação na documentação atual.

Registre ainda a tabela de partições com sudo sfdisk --dump /dev/vda > vda-partitions.txt, ajustando o dispositivo. Guarde o arquivo fora da VPS. Essa cópia não contém os dados do volume, mas ajuda a reconstruir a geometria das partições em uma recuperação. Por fim, abra uma segunda sessão SSH ou tenha acesso ao console web. Uma alteração que afete rede, boot ou montagem pode derrubar a sessão principal no pior momento.

Expanda o volume no painel do provedor

A primeira mudança efetiva ocorre fora do sistema operacional. No painel da VPS ou da cloud instance, localize o disco correto e solicite o novo tamanho. Se o servidor tem um disco de sistema de 60 GB e um volume de dados de 200 GB, confirme pelo identificador qual deles será expandido. Nomes exibidos no painel nem sempre correspondem diretamente a /dev/vda ou /dev/sdb dentro do Linux.

O procedimento varia entre provedores. Alguns permitem ampliar o disco principal com a VPS ligada. Outros exigem desligamento, alteração do plano ou migração para uma instância maior. Volumes de bloco anexados costumam ter fluxo próprio. Leia a documentação oficial e confira se a ação modifica apenas a capacidade ou também CPU e RAM. Não há um comando Linux universal que substitua essa etapa, pois o hipervisor precisa apresentar o novo tamanho ao sistema convidado.

Como exemplo, suponha um disco de 80 GB que foi ampliado para 160 GB. Depois da confirmação no painel, execute:

lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS
sudo blockdev --getsize64 /dev/vda
sudo dmesg | tail -n 30

O valor de blockdev será exibido em bytes. Um disco anunciado como 160 GB pode aparecer com unidade diferente no sistema por causa da distinção entre GB decimal e GiB binário. Isso não representa perda de espaço.

Confirme se o Linux detectou o novo tamanho

Se lsblk ainda mostrar 80 GB, aguarde a conclusão da operação no painel e verifique eventos no console. Em dispositivos SCSI, uma nova leitura pode ser solicitada com cuidado:

echo 1 | sudo tee /sys/class/block/sda/device/rescan

Troque sda somente após confirmar o nome correto. Em discos NVMe, o caminho de rescan é diferente e pode depender do driver e da plataforma. Não aplique o comando SCSI a um dispositivo NVMe por tentativa.

Quando uma reinicialização pode ser necessária

Se o kernel não reconhecer a nova geometria, uma reinicialização controlada costuma ser o caminho mais simples. Antes disso, confirme que o bootloader, o /etc/fstab e o console de recuperação estão acessíveis. Em produção, agende a janela e valide a aplicação depois do boot. O reboot não amplia a partição por si só, apenas pode fazer o kernel detectar o novo tamanho apresentado pelo provedor.

Aumente a partição sem apagar os dados

Expansão com growpart

Quando o disco já aparece maior e existe espaço livre imediatamente após a partição, growpart é a opção mais direta. Em Ubuntu e Debian, a ferramenta costuma vir no pacote cloud-guest-utils. Em distribuições da família RHEL, ela pode ser fornecida pelo pacote cloud-utils-growpart. Confirme a disponibilidade com command -v growpart antes de instalar qualquer pacote.

Para expandir a primeira partição de /dev/vda, faça inicialmente uma simulação:

sudo growpart -N /dev/vda 1

Se a prévia indicar crescimento esperado, execute:

sudo growpart /dev/vda 1
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS

Observe a sintaxe. O disco e o número da partição são argumentos separados. Para /dev/nvme0n1p1, o comando será growpart /dev/nvme0n1 1, não growpart /dev/nvme0n1p1. Esse detalhe evita um dos erros mais comuns em instâncias com armazenamento NVMe.

Considere uma VPS com /dev/vda de 120 GB, /dev/vda1 de 1 GB para boot e /dev/vda2 de 59 GB para a raiz. Se os 60 GB livres estiverem depois da partição 2, use growpart /dev/vda 2. Não use o número 1 apenas porque se trata do primeiro disco. O alvo deve ser identificado por findmnt / e lsblk -f.

Cuidados com GPT, discos NVMe e partições intermediárias

Em discos GPT, ferramentas modernas normalmente ajustam a cópia secundária da tabela ao novo final do disco. Ainda assim, mensagens sobre cabeçalho GPT devem ser lidas antes de confirmar alterações manuais. Utilize sudo parted /dev/vda print free para visualizar o espaço livre e a posição das partições.

A partição só pode crescer de forma simples quando o espaço não alocado está contíguo ao seu final. Imagine /dev/vda2 como raiz, /dev/vda3 como swap e, só depois, 80 GB livres. A raiz não pode atravessar a partição de swap. As alternativas incluem recriar a swap em arquivo, mover partições em modo de recuperação ou anexar um novo volume e montar um diretório pesado separadamente. Mover partições com dados aumenta o risco e quase sempre pede indisponibilidade.

Se growpart retornar NOCHANGE, confira três possibilidades: o disco ainda não foi ampliado, a partição já ocupa todo o dispositivo ou o espaço livre não é contíguo. Se a alteração ocorrer, mas o kernel mantiver a tabela antiga, partprobe pode solicitar uma releitura. Caso o dispositivo esteja ocupado e a releitura falhe, reinicie em uma janela controlada antes de seguir. Não recrie uma partição no fdisk sem conhecer exatamente o setor inicial, pois uma entrada iniciada no setor errado pode tornar o sistema de arquivos inacessível.

Expanda ext4, XFS ou um volume LVM

A partição maior não entrega espaço à aplicação até que o sistema de arquivos também cresça. Confirme o tipo com findmnt -no SOURCE,FSTYPE / ou df -hT. Não escolha o comando pela distribuição. Ubuntu pode usar XFS, enquanto Rocky Linux pode hospedar ext4. O que define a ferramenta é o sistema de arquivos real.

Sistema de arquivos ext4

Em ext4, resize2fs amplia o sistema de arquivos até o limite disponível quando nenhum tamanho é informado. Para uma raiz em /dev/vda1, use:

sudo resize2fs /dev/vda1
df -hT /

O ext4 pode ser expandido enquanto está montado em configurações usuais. Se a raiz estiver em um volume lógico, o alvo muda para algo como /dev/mapper/ubuntu--vg-ubuntu--lv. Nunca execute resize2fs /dev/vda se o sistema de arquivos está em /dev/vda1. O disco inteiro e a partição são dispositivos diferentes.

Um segundo exemplo é um volume de dados ext4 em /dev/sdb1, montado em /srv. Depois de aumentar o disco e a partição, execute resize2fs /dev/sdb1 e valide com df -hT /srv. O ponto de montagem continua online durante o crescimento, mas aplicações intensivas podem sentir aumento temporário de latência. Faça a operação fora do pico quando houver banco de dados ou filas no mesmo volume.

Sistema de arquivos XFS

XFS cresce pelo ponto de montagem, não pelo dispositivo. Se /dev/vda2 estiver montado em /, execute:

sudo xfs_growfs /
df -hT /

Para um volume montado em /var/lib/mysql, use sudo xfs_growfs /var/lib/mysql. O sistema de arquivos precisa estar montado. Passar /dev/vda2 como se fosse um ext4 produz erro ou não realiza a operação esperada.

XFS suporta expansão online, mas não uma redução convencional. Se você ampliou um volume de 100 GB para 500 GB, retornar a 100 GB exigirá migração para outro sistema de arquivos ou recriação controlada. Essa característica reforça a necessidade de dimensionar crescimento, retenção e custo antes da mudança.

LVM com pvresize e lvextend

Em um layout LVM, amplie primeiro a partição que contém o volume físico. Depois, informe ao LVM que o dispositivo cresceu:

sudo pvresize /dev/vda3
sudo pvs
sudo vgs

Para entregar todo o espaço livre ao volume lógico raiz, uma opção é:

sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

Em seguida, use resize2fs se o volume lógico tiver ext4 ou xfs_growfs no ponto de montagem se tiver XFS. O lvextend -r pode crescer o volume lógico e o sistema de arquivos em uma única execução, por exemplo sudo lvextend -r -L +40G /dev/vg0/root. A forma automática é conveniente, mas executar as etapas separadamente deixa mais claro onde ocorreu um erro e facilita a validação em ambientes críticos.

Compare os caminhos de expansão

O procedimento correto depende do layout, não apenas do tamanho desejado. A tabela resume três configurações comuns. Os nomes dos dispositivos são exemplos e precisam ser substituídos pelos identificados na VPS.

Layout real	Exemplo de origem	Etapas depois do painel	Comandos principais	Ponto de atenção
Partição direta com ext4	/dev/vda1 montado em /	Crescer partição e ext4	growpart /dev/vda 1 e resize2fs /dev/vda1	Confirmar número da partição e espaço contíguo
Partição direta com XFS	/dev/vda2 montado em /	Crescer partição e XFS	growpart /dev/vda 2 e xfs_growfs /	XFS recebe o ponto de montagem e não pode ser reduzido normalmente
LVM com ext4 ou XFS	/dev/vda3 alimenta vg0/root	Crescer partição, PV, LV e sistema de arquivos	growpart, pvresize, lvextend e ferramenta do sistema de arquivos	Há mais camadas e o espaço pode ser dividido entre vários LVs
Volume de dados separado	/dev/sdb1 montado em /srv	Crescer volume, partição e sistema de arquivos	Varia entre ext4 e XFS	Conferir se a aplicação realmente grava no ponto montado

A partição direta tem menos componentes e funciona bem em servidores simples. Uma VPS com Nginx, aplicação e banco pequenos no mesmo disco pode usar ext4 em /dev/vda1 sem LVM. O fluxo é curto, mas a flexibilidade para separar /var, /home ou dados de banco é limitada.

LVM adiciona uma camada operacional, porém permite distribuir o espaço livre do grupo entre volumes lógicos. Em um servidor com 100 GB livres no vg0, a equipe pode adicionar 60 GB a /var/lib/postgresql e 40 GB a /var/log, em vez de entregar tudo à raiz. Isso ajuda no isolamento, embora não substitua quotas, monitoramento e rotação de logs.

Um volume separado é interessante para Docker, uploads ou bancos que crescem mais rápido que o sistema operacional. Ele também simplifica algumas migrações, pois pode ser desanexado e associado a outra instância quando a plataforma oferece esse recurso. Ainda assim, a aplicação precisa lidar com montagem, permissões e indisponibilidade. Uma entrada incorreta no /etc/fstab pode impedir o boot, então prefira UUID obtido com blkid e teste com mount -a antes de reiniciar.

Valide o resultado e resolva erros comuns

O que conferir depois da expansão

Não encerre a manutenção assim que resize2fs ou xfs_growfs terminar. Compare as camadas novamente:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
df -hT
df -ih
findmnt /
sudo dmesg --level=err,warn | tail -n 50

lsblk deve mostrar o tamanho correto do disco e da partição. df -hT deve refletir a nova capacidade do sistema de arquivos. df -ih mede inodes, pois uma VPS pode recusar novos arquivos mesmo com gigabytes livres quando milhões de arquivos pequenos esgotam os inodes.

Faça também um teste funcional. Em uma API, execute uma requisição que grave no banco e outra que processe upload. Em um host Docker, rode docker info, docker ps e docker system df. Em um servidor de arquivos, crie um arquivo pequeno no ponto expandido, confirme proprietário e remova-o. Evite testes com arquivos gigantes em produção, pois eles podem gerar I/O desnecessário e acionar alertas.

Disco cheio mesmo após o procedimento

Se o espaço ainda não aparecer, localize a camada que permaneceu antiga. Disco maior com partição antiga aponta para growpart. Partição maior com df antigo aponta para o sistema de arquivos. LVM com pvs maior, mas volume lógico inalterado, pede lvextend.

Arquivos apagados que continuam abertos por processos também consomem espaço. Detecte-os com:

sudo lsof +L1

Um log de 20 GB removido enquanto o processo permanece ativo só libera os blocos quando o descritor é fechado. Reinicie ou recarregue o serviço de forma controlada, sem matar processos aleatoriamente. Para Docker, confira imagens, volumes e logs JSON antes de usar comandos de limpeza. docker system prune pode remover recursos necessários se for executado sem revisão.

Se a VPS voltou com erro de montagem ou sistema de arquivos inconsistente, interrompa tentativas repetidas de escrita. Use o console de recuperação, restaure o snapshot ou execute as ferramentas de reparo com o volume desmontado e seguindo a documentação do sistema de arquivos. Um bom plano de snapshots para recuperação rápida reduz o tempo de retorno, mas a restauração deve ter sido testada antes da emergência.

Recomendações por perfil

Dev solo e projetos pessoais

Para um ambiente pequeno com uma única partição ext4, mantenha o processo simples. Faça um backup externo, crie um snapshot quando disponível e registre a saída de lsblk -f e df -hT. Depois de ampliar o disco no painel, use a simulação do growpart, aplique a expansão e finalize com resize2fs. Uma VPS que passa de 40 GB para 80 GB normalmente não precisa mudar de arquitetura só por causa do crescimento. Reserve, porém, pelo menos 15% a 20% de espaço livre para atualizações, logs e arquivos temporários. Configure alertas em 70%, 80% e 90% para não repetir a expansão sob pressão.

Times com serviços compartilhados

Quando várias aplicações usam a mesma VPS, separe capacidade por responsabilidade. LVM ou volumes dedicados permitem ampliar banco, uploads e logs sem entregar todo o espaço à raiz. Antes da manutenção, registre quem usa cada montagem com findmnt, lsof e arquivos de configuração. Defina uma janela curta, pause jobs pesados e mantenha um responsável com acesso ao console. Em um host com 300 GB, por exemplo, o time pode reservar 150 GB para banco, 100 GB para uploads e 50 GB para sistema e logs. Monitore cada ponto de montagem separadamente, pois um df -h / saudável não revela que /srv/uploads está quase cheio.

Produção crítica e bancos de dados

Em produção crítica, trate a expansão como mudança de infraestrutura. Documente comandos, critérios de interrupção, plano de retorno e responsáveis. Gere backup consistente do banco, confirme a restauração mais recente e valide se o snapshot captura todos os volumes envolvidos. Para PostgreSQL, MySQL ou filas persistentes, programe a operação fora do pico e acompanhe latência de disco, fila de I/O e tempo de resposta durante o crescimento do sistema de arquivos.

Evite consumir 100%FREE no LVM quando houver chance de outro volume lógico precisar crescer. Em um grupo com 200 GB livres, pode ser mais prudente adicionar 120 GB ao banco e preservar 80 GB para emergência. Depois da expansão, revise retenção de logs, WAL, binlogs, backups locais e arquivos temporários. Se o consumo cresce 10 GB por semana, adicionar 100 GB oferece cerca de dez semanas brutas, não uma solução permanente. Capacidade precisa ser acompanhada por previsão, limpeza segura e armazenamento externo.