How AI Designed a Storage Layout I'd Have Spent Days Planning Myself

Instale Linux com Prompts: Uma Série em 4 Partes

Parte 1: Escolhendo sua Distro → Parte 2: Armazenamento e Criptografia → Parte 3: Instalação Manual → Parte 4: Serviços e GPU

Se você já viu uma partição root lotar às 3 da manhã e assistiu o sistema travar completamente, já sabe: o particionamento padrão é uma armadilha. Mas projetar um layout LVM criptografado adequado para seis cargas de trabalho diferentes em três discos físicos? Isso é um dia inteiro de planejamento solo, cruzando documentações, calculando tamanhos e se questionando o tempo todo.

Veja como deixar a IA fazer o trabalho pesado no design de armazenamento para você não ficar enterrado em man pages por um dia inteiro. Você fornece os requisitos das suas cargas de trabalho, recebe de volta uma arquitetura completa com um raciocínio que você consegue acompanhar, e sai entendendo cada camada do que está construindo.

Na Parte 1, você escolheu sua distro e mapeou o hardware. Agora vem a parte em que a maioria das pessoas ou aceita os padrões ruins ou desiste completamente: design de armazenamento.

Comece pelas Cargas de Trabalho, Não pelos Tamanhos das Partições

Você tem o hardware mapeado da Parte 1: digamos um ThinkPad mais antigo com um drive NVMe, um SSD e um HDD. As especificações dizem o que é possível. Mas as cargas de trabalho dizem o que é necessário.

Aqui está a jogada. Não peça à IA uma tabela de partições. Não especifique tamanhos. Não diga "coloque /home em sua própria partição." Em vez disso, descreva comportamentos e requisitos e deixe-a derivar a arquitetura. Algo assim:

"Esta máquina vai rodar containers Docker, PostgreSQL com TimescaleDB, Redis, Ollama para modelos de IA locais, e armazenar artefatos de ataque de uma rede honeypot. Ela também precisa de um espaço de trabalho de análise criptografado separado do SO, e armazenamento de arquivo criptografado para evidências de longo prazo. Projete a melhor estratégia de particionamento e criptografia para os três discos que encontramos."

Veja a diferença? Você está entregando restrições e objetivos, não microgerenciando a solução. Se o raciocínio retornar sólido, o design também será. E se uma escolha não fizer sentido, você vai perceber porque entende o que sua máquina realmente precisa fazer.

Separando Cargas de Trabalho por Comportamento de Disco

A primeira coisa a resolver é a separação das cargas de trabalho por padrão de IO. Não por tamanho, não por importância, mas por como cada carga de trabalho realmente acessa o disco.

As Três Faixas

• Alto IOPS, baixa latência = NVMe. É aqui que ficam o SO, Docker, bancos de dados e modelos de IA. Essas cargas de trabalho fazem muitas leituras e gravações aleatórias pequenas. Elas precisam do armazenamento mais rápido disponível.
• Espaço temporário rápido, isolado = SSD. O espaço de trabalho de análise fica aqui. Ele precisa de velocidade razoável para processar capturas e executar ferramentas, mas mais importante, precisa estar separado do disco do SO. Se o trabalho de análise corromper um sistema de arquivos ou encher um disco, o SO continua funcionando.
• Grande capacidade, gravações sequenciais = HDD. Armazenamento de arquivo de longo prazo para pcaps, exportações de evidências e backups. O desempenho de gravação sequencial é suficiente. A capacidade importa mais do que a velocidade.

Essa separação por si só previne o modo de falha mais comum: uma carga de trabalho privando outra de IO de disco ou espaço.

Por Que Cada Serviço Tem seu Próprio Volume Lógico

Não pare nos três discos. No NVMe, divida o espaço em seis volumes lógicos separados, cada um por um motivo específico:

• /var/lib/docker recebe isolamento porque o Docker consome disco de forma imprevisível. Uma build de container descontrolada ou cache de imagens esquecido não deve conseguir encher o root.
• /var/lib/postgresql recebe isolamento para dimensionamento independente, snapshots de backup e ajuste de desempenho futuro. Bancos de dados têm padrões de IO únicos que se beneficiam de espaço dedicado.
• /var/lib/ollama recebe isolamento porque modelos de IA são enormes e crescem de forma independente. Um único LLM pode ter 8 GB ou mais. Você não quer que downloads de modelos concorram com seu SO por espaço.
• /home recebe isolamento para que dados do usuário, dotfiles e configurações pessoais sobrevivam a reinstalações do SO.
• swap como seu próprio volume lógico, dimensionado para suportar hibernação se necessário.
• root (/) limitado a um tamanho fixo para que nada fora dos caminhos designados possa enchê-lo. Se o root encher, o sistema para de funcionar. Limitá-lo é um design defensivo.

Criptografia Não É Opcional

Criptografia não é opcional aqui, e o raciocínio é direto. Esta é uma máquina portátil funcionando como uma estação de trabalho de segurança que armazena dados sensíveis em repouso: capturas de honeypot, artefatos de ataque, resultados de análise de rede. Se a máquina for roubada, perdida ou desativada, cada disco precisa ser ilegível sem a senha.

Criptografia de disco completo com LUKS é o mínimo para este caso de uso. Ponto final.

Deixe Espaço de Reserva no seu Grupo de Volumes

Este detalhe separa um bom design LVM de um trabalho amador. Deixe cerca de 5 a 10% do seu grupo de volumes não alocado. Não desperdiçado. Reservado. Veja o porquê:

Com LVM, você pode expandir volumes lógicos em tempo real sem reiniciar. Se o Docker precisar de mais espaço em seis meses, você estende o LV e redimensiona o sistema de arquivos em segundos. Se você alocou tudo antecipadamente, precisaria encolher um volume para expandir outro, e encolher é lento, arriscado e às vezes impossível com certos sistemas de arquivos.

Espaço de reserva intencional é um recurso, não desperdício.

O Modelo Mental da Camada de Armazenamento

Este modelo mental é a coisa mais valiosa a levar deste capítulo inteiro. Não os tamanhos das partições. Não os pontos de montagem. Esta pilha de 8 camadas que explica como o armazenamento Linux realmente funciona, de cima para baixo.

A maioria das falhas que você vai encontrar durante a instalação real, especialmente com fstab e crypttab na Parte 3, vem de confundir essas camadas. Escrever um UUID da camada 2 onde a camada 6 era esperada. Referenciar um caminho de dispositivo da camada 3 em uma configuração que precisava da camada 1. Todo erro de armazenamento remete a uma incompatibilidade de camada.

Marque esta pilha como favorito. Tatue no seu antebraço. Depois de internalizar essas oito camadas, o armazenamento Linux deixa de ser misterioso. São apenas oito coisas, cada uma fazendo um trabalho, conectadas em ordem.

O Layout Final do NVMe

Aqui está o design completo para o drive NVMe primário:

NVMe Primário (nvme0n1)

Dentro do container LUKS em nvme0n1p3:

nvme0n1p3 → cryptnvme (LUKS2) → LVM PV → vgkali (Grupo de Volumes)

Discos Secundários

SSD (sdb): sdb1 → cryptanalysis (LUKS2) → ext4 → /srv/analysis

HDD (sda): sda1 → cryptarchive (LUKS2) → ext4 → /srv/archive

Três discos criptografados. Seis volumes lógicos no primário. Cada carga de trabalho em sua própria faixa. Nada compartilha espaço com o que não deveria.

Transformando o Design em um Script de Build

Assim que o design estiver definido, o próximo prompt é simples:

"Me dê os comandos exatos para construir todo esse layout de armazenamento a partir do ambiente Kali live. Assuma que todos os três discos podem ser apagados."

Peça um script shell completo: apagar assinaturas existentes, criar tabelas de partição GPT, criar partições com sgdisk, criar contêineres LUKS2 com padrões robustos, abri-los, inicializar volumes físicos LVM, criar o grupo de volumes, alocar todos os seis volumes lógicos, formatar tudo e repetir a configuração LUKS para o SSD e o HDD.

Espere cerca de 80 linhas. Cada comando deve ser auditável. Se algo no script não fizer sentido para você, peça à IA para explicar aquela linha específica antes de executá-la.

O Que Vai Dar Errado (E Não Será o Design)

Um aviso justo: o design será sólido. A execução vai te dar trabalho. Aqui estão as armadilhas a observar:

Quebras de linha do Windows. Se você escrever o script em uma máquina Windows e transferi-lo para o ambiente live via USB, cada linha termina com \r\n em vez de \n. O Bash engasga em cada comando, e as mensagens de erro são crípticas. Corrija com sed -i 's/\r$//' script.sh antes de executar qualquer coisa.

Corrupção do shebang. Relacionado ao problema de quebra de linha. A linha #!/bin/bash recebe um retorno de carro invisível, então o kernel não consegue encontrar o interpretador. O erro parece que o script não existe, mesmo que ele claramente exista.

Confusão de caminhos. O USB é montado em um caminho, mas você está referenciando o script a partir de um diretório de trabalho diferente. A conclusão por Tab e os caminhos relativos em um ambiente live são pouco confiáveis quando você está gerenciando vários pontos de montagem. Use caminhos absolutos.

Sintaxe de execução errada. Esquecer o ./ antes do nome do script, ou não definir as permissões de execução primeiro. Erros clássicos que não têm nada a ver com design de armazenamento e tudo a ver com memória muscular.

"A IA pode escrever o script, mas você ainda precisa entender o que está colando. Se um comando não fizer sentido para você, pare e pergunte."

Assim que os problemas de quebra de linha e execução forem resolvidos, o build do armazenamento é concluído em menos de dois minutos. Cada contêiner LUKS abre. Cada estrutura LVM é criada sem problemas. Cada sistema de arquivos é formatado. O design se sustenta.

Verifique Tudo com o Padrão de Colar e Verificar

Não assuma sucesso. Após o script terminar, cole a saída do seu terminal de volta para a IA e peça que ela audite o resultado:

"Aqui está minha saída de lsblk e lvs. Tudo foi construído corretamente?"

Cole a saída bruta do terminal e peça à IA para percorrê-la linha por linha. Ela deve confirmar: cryptnvme ativo, vgkali presente com seis volumes lógicos nos tamanhos corretos, sistemas de arquivos corretos em cada um, discos secundários criptografados e formatados.

Esse padrão de colar e verificar é uma das técnicas mais úteis para administração de sistemas com IA. Você executa um comando, cola a saída e pergunta se a realidade corresponde ao plano. Ele detecta problemas que você perderia por estar próximo demais do trabalho:

• Um volume lógico formatado acidentalmente com o tipo de sistema de arquivos errado
• Um volume dimensionado em megabytes quando você quis dizer gigabytes
• Uma partição ausente que o script ignorou silenciosamente
• Um contêiner LUKS que na verdade não abriu

Você pode fazer isso com quase qualquer estado do sistema: lsblk, lvs, pvs, vgs, blkid, fdisk -l, cryptsetup status. Cole. Peça à IA para auditar. É mais rápido e mais completo do que verificar tudo sozinho.

A Conclusão: Projete a Partir das Cargas de Trabalho, Não dos Padrões

O layout de armazenamento aqui não foi escolhido a partir de um modelo ou copiado de um post em fórum. Ele foi derivado de requisitos reais de carga de trabalho. O Docker precisa de isolamento de espaço. Bancos de dados precisam de IO dedicado. Modelos de IA precisam de espaço para crescer. Artefatos de segurança precisam de criptografia em repouso. Arquivos precisam de capacidade acima de velocidade.

Cada decisão remonta a um requisito real. Essa é a diferença entre um layout de armazenamento que sobrevive seis meses e um que desmorona na primeira vez que algo inesperado acontece.

Essa abordagem funciona para qualquer build, não apenas estações de trabalho de segurança. Diga à IA o que a máquina vai fazer. Descreva os serviços, os padrões de dados, as expectativas de crescimento, os cenários de falha que você quer sobreviver. Então deixe-a descobrir como organizar os discos. O raciocínio que ela mostra é mais valioso do que a tabela de partições final, porque você vai entender por que cada escolha foi feita e quando ela pode precisar mudar.

Seus discos estão particionados, criptografados e divididos em volumes lógicos. A arquitetura está pronta. Agora vem a parte que realmente desafia as pessoas: instalar um SO em cima de tudo isso sem um instalador gráfico guiando você.

Na Parte 3: Instalação Manual, você vai montar os volumes criptografados, fazer o bootstrap do Kali do zero, configurar o fstab e o crypttab para que tudo seja desbloqueado na inicialização e construir uma configuração funcional do bootloader. É aqui que o modelo de 8 camadas é testado de verdade, e onde um UUID errado pode te deixar olhando para um prompt de resgate do GRUB. Traga café.