Chegou o momento de lidar com a última (e mais importante) partição: a encriptada, a principal razão para estarmos a fazer isto. Antes de executar o próximo comando, pode querer correr “cryptsetup benchmark” e consultar esta página para obter um bom entendimento e detalhes que garantam o máximo desempenho da sua configuração.

cryptsetup luksFormat /dev/sdX4

Introduza uma senha segura para a encriptação. Guarde-a num gestor de passwords ou anote-a. Se a esquecer, perderá acesso aos seus dados. Consulte esta documentação para mais informações. As instruções devem ser semelhantes no Debian. Pode optar por adicionar uma segunda senha e fazer um backup do cabeçalho LUKS posteriormente, mas não se esqueça disso. Se o cabeçalho ficar corrompido, os seus dados serão inacessíveis. Mas fez backups, certo?

Em seguida, abra a unidade recém-encriptada:

cryptsetup open /dev/sdX4 cryptlvm

Digite a senha e, se tiver sucesso, agora /dev/mapper/cryptlvm representa a sua partição encriptada.

Agora configuramos o LVM. Se a sua instalação não estiver a utilizar LVM, pode ignorar o restante desta secção, mas verifique se ajustou corretamente a sua tabela de partições. Não posso cobrir todos os casos aqui, mas assegure-se de que a) tem uma partição de boot separada e b) o resto está conforme a tabela de partições anterior, o que deverá estar correto. Para encriptar partições além de /, consulte a secção “Desencriptar outras unidades”.

pvcreate /dev/mapper/cryptlvm
vgcreate pve-new /dev/mapper/cryptlvm

Estes comandos criam um novo volume físico e adicionam-no a um novo grupo de volumes chamado pve-new (por agora). Em seguida, criamos duas partições: root e swap.

# Criar novas partições
lvcreate -L 30G pve-new -n root
lvcreate -L 8G pve-new -n swap
# Formatar swap
mkswap /dev/pve-new/swap
# Formatar a partição root
mkfs.ext4 /dev/pve-new/root

Pode ajustar os tamanhos conforme necessário; não vou entrar em detalhes aqui. Na minha instalação atual, uso cerca de 8G para a partição root.

Se tiver outras partições não relacionadas às VMs, pode criá-las agora também. Se não tiver a certeza, execute “lvs” e/ou “lvdisplay” para ver o que tem. Qualquer coisa que comece com vm-* não é importante agora. Além disso, se tiver um volume fino chamado, por exemplo, data, não se preocupe com isso, vamos lidar com isso mais tarde. Os volumes finos têm um atributo ‘t’ como o primeiro item quando executa “lvs” (onde a partição root deve ter apenas ‘-‘).

Copiar a instalação antiga para a nova partição encriptada

É altura de copiar o nosso sistema antigo para o novo. Se estiver no host Proxmox em execução, pode querer mudar para um disco live agora. Pode poupar tempo copiando os dados enquanto o sistema está em execução, mas realmente não recomendo isso.

Prepare-se para copiar dados:

1. **Criar diretórios para montar:**
   mkdir /mnt/{novo,antigo}

2. **Montar a partição root nova (note a referência LVM 'pve-novo'):**
   mount /dev/pve-novo/root /mnt/novo

3. **Criar um ponto de montagem para a nova partição boot:**
   mkdir /mnt/novo/boot

4. **Montar a partição formatada na pasta boot. Ajuste conforme necessário:**
   mount /dev/sdX3 /mnt/novo/boot

5. **Criar um ponto de montagem para a partição efi:**
   mkdir /mnt/novo/boot/efi

6. **Montar a partição efi para a nova instalação:**
   mount /dev/sdX2 /mnt/novo/boot/efi

7. **Montar o sistema antigo:**
   mount /dev/pve/raiz /mnt/antigo

8. **Montar a partição efi antiga:**
   mount /dev/sda2 /mnt/antigo/boot/efi

9. **Verificar se tudo está correto:**

   - Listar recursivamente o diretório da nova partição (deve parecer basicamente vazio):
     ls -lR /mnt/novo
  
   - Verificar se as montagens estão corretas para a nova partição (root, boot e efi nos caminhos corretos):
     mount | grep /mnt/novo

   - Verificar se as montagens estão corretas para a partição antiga (root e efi nos caminhos corretos):
     mount | grep /mnt/antigo

   - Listar conteúdo da instalação antiga:
     ls /mnt/antigo

   - Verificar se a partição EFI antiga está montada corretamente:
     ls /mnt/antigo/boot/efi
  
   - Exibir informações de uso de disco para verificar a sanidade das montagens:
     df -h

Se tudo estiver correto, estamos prontos para copiar alguns dados. É simples, mas pode levar tempo dependendo da sua instalação. Se tiver muitos discos de VMs, esta cópia incluirá VMs, backups, instantâneos e tudo mais.

rsync -av --progress /mnt/antigo/ /mnt/novo

Depois de terminar sem erros, execute df -h. Em geral, os tamanhos do antigo e do novo devem ser semelhantes, embora o novo seja ligeiramente menor devido ao /boot estar separado agora.

O próximo passo é migrar todos os dados LVM existentes que não tratamos anteriormente. No meu caso, tenho um pool fino chamado data e vários discos. Primeiro, precisamos recriar este pool. Se executar lvdisplay /dev/pve/data (ajustando o nome do pool), verá o tamanho que ele possui. No meu caso, optei por 500G e deixei o restante livre (não é possível diminuir um pool fino, mas é possível expandi-lo).

# -T cria um pool fino
lvcreate -T -L 500G pve-new -n data

Agora precisamos recriar e repopular todos os dados de cada disco que temos. Tecnicamente, poderíamos tentar uma técnica sofisticada abrindo cada um e migrando-os, mas decidi ser cauteloso e simplesmente espelhar tudo usando dd. Dependendo do tamanho dos discos, isso pode levar tempo, mas é a forma mais segura e menos complexa.

# --virtualsize é o tamanho do disco, escolhi 257G para deixar espaço extra para o meu volume de 256G

# -T identifica o pool fino que criamos anteriormente

# -n especifica o nome do disco

lvcreate --virtualsize 257G -T pve-new/data -n vm-101-disk-1

# if= é a origem dos dados

# of= é o destino

# conv=sparse pula valores que são 0 (ver abaixo)

dd if=/dev/pve/vm-101-disk-1 of=/dev/pve-new/vm-101-disk-1 status=progress conv=sparse

Se tiver um pool fino e verificar qualquer um dos seus discos, por exemplo, lvdisplay /dev/pve/vm-101-disk-1, verá que ele possui um valor de Utilização %, geralmente inferior a 100%. Este é o espaço que o disco realmente está usando agora. Se executar dd sem conv=sparse, verá que o disco de destino mostra 100% de Utilização. Não seria o fim do mundo, mas perderia o benefício dos pools finos. Com esse parâmetro, os bytes nulos (valores vazios) são ignorados e não ocupam espaço. Não sou um especialista, mas funcionou para mim.

Repita o processo acima para cada disco. O passo dd pode levar bastante tempo (mais chá?), pois é onde todos os dados são copiados (e encriptados no processo!). Depois de terminar com todos os discos, deverá ter basicamente uma cópia exata de tudo em pve-new.

Agora que terminámos, podemos desmontar tudo:

Certifique-se de que não está dentro de nenhum dos diretórios

cd /mnt
umount -R /mnt/old
umount -R /mnt/new

Tornar a nova instalação inicializável

Até este ponto, ainda deverá ser possível inicializar no Proxmox antigo. Se desejar, pode verificar se está tudo bem. Caso contrário, talvez seja uma boa altura para entrar em modo de recuperação e verificar o que correu mal. Uma nota importante: se adicionou um novo disco, pode interferir na ordem de inicialização (e, por vezes, até na nomenclatura dos dispositivos). Ao reiniciar, assegure-se de fazer backup e reinstalar os pacotes necessários, desbloquear a unidade encriptada e executar lvscan ou lvchange -ay para ativar os volumes LVM desencriptados.

Depois de seguir as instruções acima, perderá a capacidade de inicializar facilmente a sua instalação antiga, por pelo menos duas razões. Primeiro, iremos renomear o nosso grupo de volumes (para LVM) e, segundo, iremos mexer com o carregador de inicialização UEFI. Ambos os passos são reversíveis, por isso não está a destruir nada. Para o LVM, o Proxmox espera que o grupo de volumes tenha o nome pve (pelo menos para mim), por isso a nossa nova instalação precisa desse nome. Se quiser voltar atrás, basta desfazer o rename e a inicialização deve ocorrer novamente.

Certifique-se de que desmontou as unidades no passo anterior e, em seguida, renomeie ambos os grupos de volumes:

vgrename pve pve-old vgrename pve-new pve

Depois, montamos tudo novamente:

mount /dev/pve/root /mnt/new 
mount /dev/sdX3 /mnt/new/boot 
mount /dev/sdX2 /mnt/new/boot/efi

Agora é hora de configurar esta “nova” instalação para que seja realmente inicializável. Para isso, fazemos chroot, mas primeiro precisamos montar vários sistemas de arquivos API para que os comandos funcionem corretamente.

cd /mnt/new 
mount -t proc /proc proc/ 
mount -t sysfs /sys sys/ 
mount -o bind /dev dev/ 
mount -o bind /dev/pts dev/pts 
mount -o bind /sys/firmware/efi/efivars sys/firmware/efi/efivars/ 
chroot /mnt/new /bin/bash

Este processo deve configurar a sua nova instalação para ser inicializável e pronta para uso. Certifique-se de seguir cada passo com cuidado e ajustar os comandos conforme necessário para a sua configuração específica.

Após isso, o seu shell deve exibir / e deverá estar no diretório raiz da sua nova instalação do Proxmox. Primeiramente, instalamos os novos pacotes necessários. Note que agora estamos instalando pacotes dentro do Proxmox, então as nossas alterações aqui são persistentes. Para todos os efeitos, é como se estivéssemos dentro do sistema Proxmox em execução.

apt install cryptsetup cryptsetup-initramfs dropbear-initramfs

O pacote dropbear-initramfs é necessário posteriormente para o desbloqueio SSH. Se não precisar do desbloqueio remoto, pode ignorá-lo.

O pacote cryptsetup-initramfs também é crucial aqui. Por algum motivo, não consegui encontrá-lo documentado na maioria dos lugares que pesquisei, mas é ele que garante que será solicitada uma passphrase ao iniciar e que a desencriptação será feita. A documentação oficial está aqui, mas apenas menciona para verificar /usr/share/doc/cryptsetup-initramfs/README.initramfs.gz, sem mencionar a necessidade de instalação deste pacote. Portanto, assegure-se de tê-lo e, em seguida, todos os passos seguintes garantirão que tudo funcione corretamente.

Agora precisamos de configurar o Proxmox para inicializar corretamente. O primeiro passo é informar que queremos desencriptar a nossa partição raiz:

# Ajuste sdX4 conforme necessário novamente
echo "cryptlvm UUID=$(blkid -s UUID -o value /dev/sdX4 | tr -d '\n') none luks" >> /etc/crypttab

Isto adiciona instruções ao /etc/crypttab e identificamos a drive pelo UUID. Certifique-se de executar “cat /etc/crypttab” e que tudo parece correto. Especialmente, que há um UUID presente. Notei em alguns dos meus testes que blkid retornava um valor vazio aqui. Se for o seu caso, execute “ls -l /dev/disk/by-uuid” e encontre o UUID correto e substitua-o.

Agora precisamos de informar o Proxmox sobre os pontos de montagem. Como renomeamos o nosso novo grupo de volumes para pve, tanto /dev/pve/root como /dev/pve/swap continuarão a funcionar (depois de desencriptados). No entanto, precisamos de atualizar o UUID para /boot/efi e adicionar um novo ponto de montagem para /boot.

Nota: O seu /etc/fstab pode ser diferente. Tente manter o máximo possível. Só precisa de adicionar a nova mount /boot e depois atualizar todos os UUIDs para os novos valores.

Primeiro adicionamos novas linhas e depois corrigimos o ficheiro:

# Ajustar nomes das drives
echo "UUID=$(blkid -s UUID -o value /dev/sdX3 | tr -d '\n') /boot ext4 defaults 0 2" >> /etc/fstab
echo "UUID=$(blkid -s UUID -o value /dev/sdX2 | tr -d '\n') /boot/efi vfat defaults 0 1" >> /etc/fstab

Agora abra o /etc/fstab com vim ou nano e remova a linha antiga /boot/efi. Novamente, certifique-se de que os UUIDs estão lá (não se preocupe, o da FAT32 é realmente curto) e também certifique-se de que /boot vem primeiro, seguido de /boot/efi. Deverá já ser o caso se executou os comandos acima na ordem correta.

Antes de instalar o Grub no passo seguinte, verifique se tem um ficheiro chamado /etc/kernel/proxmox-boot-uuids. Se sim, não tenho a certeza se o seguinte vai causar problemas. Pode remover/fazer backup do ficheiro e tentar ou dar uma vista de olhos no script shell e perceber. Eu não tinha o ficheiro, então ignorei-o completamente, mas não tenho certeza se funciona bem. De acordo com esta página, porque estou a usar UEFI, mas não ZFS, escolhe Grub. No entanto, o script parece não considerar este caso, então provavelmente não é usado. Se o executar, provavelmente tentará usar systemd-boot em sistemas UEFI e não é isso o pretendido.

No meu caso, não tinha o ficheiro, então esse comando não fez nada. No entanto, se olhar para o script (é muito simples), acaba por executar um grub-install de qualquer forma. Ajustei ligeiramente os parâmetros para o que acho que faz mais sentido. Se estiver num sistema de 32 bits, use –target i386-pc em vez disso.

grub-install.real --efi-directory /boot/efi --target x86_64-efi --no-floppy --bootloader-id='proxmox' /dev/sdX

Vai notar que o Proxmox substituiu o grub-install original, por isso precisamos de chamar este alias.

Se não se importar nem com a desencriptação de outras drives nem com o desbloqueio remoto, pode executar os seguintes comandos para configurar o processo de inicialização. Se quiser esses componentes opcionais, salte este passo (não faz mal, mas teremos que o executar novamente mais tarde).

update-grub
update-initramfs -c -k all

Veja o final da secção SSH/desbloqueio remoto para uma explicação do porquê de executarmos estes dois comandos. (Continuação Parte 3)