Quando a gente começa a usar nuvem, é comum pensar na máquina virtual como “o computador inteiro”: CPU, memória e aquele disco onde o sistema operacional está instalado. Só que esse disco de sistema, em muitos provedores, é efêmero: se você recriar a VM, trocar o tipo, apagar a instância ou tiver um incidente, aquele armazenamento pode ir embora junto. Para ambientes de teste isso pode até ser tolerável. Para qualquer coisa que envolva dado importante, não.
É justamente nesse ponto que entra o Block Storage.
De forma conceitual, Block Storage é um tipo de armazenamento em que a nuvem entrega para você um disco em blocos, exposto à VM como se fosse um segundo HD ou SSD. Esse disco não depende da “vida” da máquina virtual: ele é um recurso separado, com identidade própria, que pode ser criado, anexado, desanexado e reaproveitado em outras instâncias. Você continua administrando o sistema de arquivos (ext4, XFS, etc.) dentro do sistema operacional, mas a infraestrutura de desempenho, replicação e disponibilidade é responsabilidade da nuvem.
Na Magalu Cloud, esses volumes são oferecidos em perfis pensados para diferentes cargas, com base em NVMe e latência baixa, o que os torna apropriados para bancos de dados, sistemas de arquivos compartilhados, aplicações que fazem muitas leituras e escritas e até para separar melhor responsabilidades: um volume só para banco, outro para uploads de usuários, outro para logs de auditoria, e assim por diante.
Os casos de uso aparecem rápido:
- um banco de dados que não pode sumir se você precisar recriar a VM;
- um diretório de uploads de um e-commerce que precisa crescer sem que você mude toda a máquina;
- um conjunto de logs de aplicação que você conserva em disco resiliente para análise posterior;
- volumes dedicados a ambientes de homologação, criados a partir de snapshots de produção.
O desafio prático que este artigo resolve é simples e muito real:
“Tenho uma VM Linux na Magalu Cloud e quero adicionar um disco persistente, separado do sistema, usando a CLI.”
A ideia é caminhar desde o conceito até o comando real, mostrando como criar o volume, anexar à VM e prepará-lo no Linux para uso cotidiano.
Criando e usando um volume de Block Storage na Magalu Cloud
Vamos supor o seguinte cenário: você já criou uma VM Linux na Magalu Cloud, instalou a CLI mgc, autenticou na sua conta e agora quer um novo disco de 10 GiB para armazenar dados da aplicação em produção ou em teste.
Antes de escrever qualquer comando, vale reforçar uma regra de arquitetura: volume e VM precisam estar na mesma região e na mesma Zona de Disponibilidade (AZ). Isso existe porque o volume é fisicamente associado a uma infraestrutura específica; tentar anexar a uma VM em outra zona simplesmente não faz sentido do ponto de vista de rede e desempenho.
Com isso em mente, o fluxo natural é:
- criar o volume de Block Storage na região/AZ correta;
- anexar esse volume à VM;
- entrar na VM, formatar o dispositivo e montar em um diretório;
- tornar a montagem persistente entre reboots.
Criando o volume pela CLI
A criação do volume pela CLI é direta. Você descreve o tamanho, o nome e o tipo de desempenho desejado. Um exemplo típico seria:
mgc block-storage volumes create --name volume-app-prod --size 10 --type.name cloud_nvme1k
O --name identifica o volume dentro da região; é um rótulo lógico, útil para saber, por exemplo, que esse é o volume de dados da aplicação de produção. O --size define o tamanho em gibibytes (GiB) podendo ser 10, 20, 50, 100, e assim por diante, dentro dos limites que a Magalu Cloud impõe para aquele tipo de volume. Já --type.name aponta para o perfil de IOPS/latência. Perfis baseados em NVMe costumam ser adequados para cargas que fazem muito I/O, como bancos de dados e aplicações mais intensas.
Depois da criação, o volume nasce em um estado equivalente a “livre”, pronto para ser anexado. Você pode conferir isso com um simples:
mgc block-storage volumes list
Na listagem, o volume recém-criado aparece geralmente com o status available. Enquanto ele estiver assim, nenhuma VM está usando esse recurso.
Anexando o volume à máquina virtual
O passo seguinte é anexar à máquina virtual. Conceitualmente, é como plugar um SSD extra em um servidor físico: a VM passa a “enxergar” um novo disco. Para que isso funcione, a VM precisa estar em um estado válido (ligada ou desligada) e compartilhar a mesma AZ do volume. Em muitas arquiteturas, é mais seguro realizar esse tipo de operação com a instância desligada, principalmente se você estiver mexendo em ambientes sensíveis, ainda que a plataforma permita anexar com a VM em execução.
Com o ID da VM e do volume em mãos, o comando é semelhante a:
mgc block-storage volumes attach --id vol-1234567890abcdef --virtual-machine-id vm-abcdef1234567890
Depois de alguns instantes, o volume deixa o estado available e passa para algo como in-use, indicando que agora existe uma relação concreta com uma máquina virtual.
Preparando o volume dentro da VM
A partir desse ponto, a “bola” passa para o sistema operacional. Dentro da VM, esse volume aparece como um novo dispositivo de bloco, por exemplo /dev/vdb. Para enxergar isso, você pode usar:
lsblk
A saída costuma mostrar o disco de sistema como vda com partições e pontos de montagem já preenchidos, e o novo volume como vdb, ainda sem partição e sem sistema de arquivos. É aqui que entra a parte de teoria de armazenamento que desenvolvedores às vezes pulam: um volume de Block Storage é só um conjunto de blocos; cabe a você criar o sistema de arquivos por cima dele.
Se o volume é novo e não contém dados, faz sentido criar um sistema de arquivos moderno como ext4:
sudo mkfs.ext4 /dev/vdb
Esse comando grava estruturas internas no volume, preparando-o para guardar arquivos, diretórios, permissões e tudo mais que o kernel vai gerenciar. Caso o volume tenha sido criado a partir de um snapshot, a situação é outra: nesses casos, ele já traz um sistema de arquivos e dados, então não se deve formatar novamente.
Montando o volume em um diretório
Com o sistema de arquivos pronto, o próximo passo é escolher um ponto de montagem. Um caminho clássico para dados de aplicação é algo como /mnt/data:
sudo mkdir -p /mnt/data
sudo mount /dev/vdb /mnt/data
df -h | grep /mnt/data
A partir desse momento, qualquer escrita em /mnt/data é uma escrita no volume de Block Storage. É aqui que você pode configurar o banco de dados para usar um diretório dentro desse caminho, apontar uploads de usuário, logs de auditoria ou o que fizer sentido para a sua arquitetura.
Tornando a montagem persistente com /etc/fstab
No entanto, essa montagem ainda é temporária: se você reiniciar a VM, o Linux não vai remontar automaticamente o volume. Para que isso aconteça, entra em cena o arquivo /etc/fstab, onde ficam descritas as montagens permanentes.
Uma prática recomendada é montar não pelo nome /dev/vdb, mas pelo UUID do sistema de arquivos, que é estável mesmo se a ordem de dispositivos mudar. Você descobre o UUID com:
sudo blkid /dev/vdb
Com a informação em mãos, edita o /etc/fstab com:
sudo nano /etc/fstab
E adiciona uma linha descrevendo a montagem, algo nesta linha:
UUID=abcd-1234-... /mnt/data ext4 defaults 0 0
Antes de reiniciar, é sempre prudente testar a configuração desmontando e pedindo para o sistema montar tudo de novo:
sudo umount /mnt/data
sudo mount -a
Se não houver mensagens de erro, o Linux aceitou a sintaxe e vai remontar o volume automaticamente na próxima inicialização. Assim, você garante que o diretório de dados da sua aplicação volta exatamente ao mesmo lugar, mesmo que a VM seja restartada diversas vezes.
Do ponto de vista conceitual, a partir daqui você já está usufruindo das propriedades do Block Storage: o disco de sistema continua efêmero (caso deseje), mas os dados críticos residem em um volume persistente, que pode ser dimensionado, copiado via snapshot ou até reaproveitado em outra VM, dependendo da necessidade.
Gerenciando o ciclo de vida: resize, retype e snapshots
Além dessa trilha básica, a CLI também oferece operações de ciclo de vida interessantes. É possível, por exemplo, aumentar o tamanho do volume (sempre para cima) quando o espaço se aproximar do limite, ou alterar o tipo de desempenho (“retype”) para um perfil com mais IOPS conforme a carga evolui. Outra operação comum é a criação de snapshots, que são cópias pontuais do volume: a partir de um snapshot, você consegue gerar um novo volume idêntico para testes, homologação ou recuperação de desastre, reduzindo impacto na produção.
Conclusão
Block Storage é um daqueles conceitos que parecem meramente “infra” à primeira vista, mas que definem a diferença entre um ambiente frágil e uma arquitetura preparada para crescer. Ao separar o disco de dados da vida da máquina virtual, você passa a tratar armazenamento como um recurso de primeira classe: com identidade própria, políticas de backup, perfis de desempenho e possibilidades de migração.
Ao longo do texto, vimos como esse modelo funciona na prática na Magalu Cloud: um volume NVMe criado via CLI, anexado a uma VM, formatado e montado em um diretório específico, pronto para receber dados de aplicação. Esse caminho, embora simples, libera algumas boas práticas importantes: não guardar banco de dados no disco de sistema, isolar uploads de usuários, manter logs críticos em armazenamento persistente e poder, se necessário, recriar a VM sem derrubar o estado da aplicação.
Na Magalu Cloud, a ideia é justamente oferecer essa base de infraestrutura com cara de nuvem moderna, mas com vantagens muito concretas para o dia a dia de quem desenvolve no Brasil: cobrança em reais, foco em soberania de dados, documentação em português e integração com o ecossistema Magalu. Se você ainda não experimentou, vale criar uma VM de laboratório, seguir o passo a passo deste artigo e começar a construir suas próprias combinações de volumes, snapshots e ambientes.
Top comments (1)
Era uma dúvida minha (agora não mais, rs), excelente explicação (obrigado)!