Blogue ·
O que uma cópia de segurança não contém
A mesma opção ausente significa sim numa máquina virtual e não num contentor. Eis como a cobertura do Proxmox foi medida em vez de simplesmente prometida.
Por Provibr
Se perguntar a um painel de gestão se uma máquina tem cópia de segurança, a resposta é normalmente sim. A pergunta interessante é mais estreita e bem mais difícil: que partes estão no arquivo e quais não estão. Um contentor com uma montagem ligada a uma pasta do anfitrião tem dados que nenhum vzdump alguma vez tocará, e um painel que sobre essa configuração diz «com cópia» não está a ser otimista, está a fazer uma promessa em nome do software de outra pessoa.
Deixámos por isso de prometer e começámos a medir. Cada cópia e cada ponto de reposição leva agora uma observação de como o convidado estava nesse momento, e o painel deduz a cobertura dessa observação e não do facto de uma cópia ter terminado bem.
A mesma ausência, dois sentidos opostos
A razão pela qual isto se mede e não se raciocina é uma regra de comportamento do Proxmox que segue exatamente o sentido contrário para os dois tipos de convidado.
Num contentor, um ponto de montagem só está no arquivo quando lá consta backup=1. A documentação é explícita: para incluir um ponto de montagem nas cópias, é preciso ativar a respetiva opção. A ausência significa não.
Numa máquina virtual, um disco está no arquivo a menos que lá conste backup=0. Isso não aparece nesses termos no manual; aparece na função que entrega ao vzdump a sua lista, onde o valor é lido como a marca de cópia do disco com um por omissão. A ausência significa sim.
| Linha de configuração | No arquivo? |
|---|---|
rootfs: local-lvm:vm-101-disk-0,size=8G | sim, sempre; a raiz nem sequer conhece o campo de cópia |
mp0: local-lvm:vm-101-disk-1,mp=/data,backup=1 | sim |
mp0: local-lvm:vm-101-disk-1,mp=/data | não |
mp0: /srv/data,mp=/data (montagem ligada) | não; o conteúdo das montagens ligadas não é copiado |
mp0: /dev/sdb1,mp=/disk (montagem de dispositivo) | não; o mesmo vale para montagens de dispositivo |
scsi0: local-lvm:vm-100-disk-0,size=32G | sim |
scsi1: local-lvm:vm-100-disk-1,backup=0 | não |
ide2: local:iso/debian.iso,media=cdrom | não aplicável |
efidisk0: … com bios: ovmf | sim |
efidisk0: … sem bios: ovmf | não |
tpmstate0: … | sim |
scsi2: /dev/sdb (passagem direta) | sim |
unused0: local-lvm:vm-100-disk-4 | não |
virtiofs0: dataset-a | não |
As duas linhas a negrito são a mesma ausência. Se as dobrar numa só frase, um dos dois ecrãs mente, e nenhum dos dois assinala um erro.
Ler a fonte, não a intuição
Três dessas linhas saíram diferentes do que o plano deste trabalho supunha, e as três foram resolvidas lendo o Proxmox em vez de discutir.
De um disco em passagem direta supôs-se que era dado do anfitrião que fica para trás, por analogia com a montagem de dispositivo de um contentor. Não é assim. A função que constrói a lista de cópia nunca olha para o caminho, e o passo de preparação transforma um identificador de volume sem armazenamento por trás num dispositivo de blocos e inclui-o. Errar no sentido que parece prudente diria aos clientes que há dados fora do seu arquivo quando na verdade estão lá dentro, o que soa inofensivo até se notar que obriga a um reconhecimento em cada reposição e ensina assim as pessoas a passar por cima dos reconhecimentos.
Os discos desligados e as pastas partilhadas do anfitrião faltavam simplesmente no plano. Um unusedN é dado real do cliente que está no armazenamento sem barramento ligado, e o vzdump regista que o salta. Um virtiofsN é uma pasta do anfitrião e nunca um volume, o que faz dele o equivalente da montagem ligada numa máquina virtual. Ambos são buracos reais de cobertura e ambos teriam contado como completos.
Os prefixos das chaves de disco e as suas quantidades vêm do mesmo sítio: quatro lugares IDE, seis SATA, trinta e um SCSI, dezasseis virtio, um disco EFI, um estado TPM, duzentos e cinquenta e seis lugares não usados, dez virtiofs. Uma chave fora desses intervalos não é um disco para o Proxmox, pelo que também não pode tornar-se um aqui em silêncio. E virtiofs é verificado antes de virtio, porque virtiofs0 começa por virtio: ao contrário, uma pasta partilhada do anfitrião seria lida como disco e comunicada como copiada.
Desconhecido nunca se chama completo
As palavras no ecrã para um convidado não medido são «não estabelecido», por extenso: o que uma cópia contém não foi estabelecido. Nunca «completa», nunca «fora da cópia». Há três formas de lá chegar e as três são reais: o convidado é de um tipo que o agente não sabe ler, o agente é anterior à versão que lê configurações, ou o agente tentou e não conseguiu aceder.
Esse último caso é a razão de a observação levar uma marca explícita a dizer que a configuração foi lida. Sem ela, uma lista vazia de pontos de montagem não se distingue de um contentor sem montagens adicionais, exceto que o segundo não existe: há sempre uma raiz. Um agente que não conseguiu ver leria-se de outro modo como um convidado sem nada fora do arquivo, que é exatamente a falha que este trabalho existe para evitar.
Duas regras empurram no mesmo sentido. Uma configuração de contentor que foi lida mas não contém raiz é desconhecida e não completa, porque terá sido lido algo que não era uma configuração de contentor. E uma configuração de máquina virtual em que nada levanta uma pergunta de cobertura, nada ou apenas leitores óticos, é desconhecida pela mesma razão: completa significa que está tudo lá, e dizê-lo de zero coisas é uma afirmação sem medição por baixo. O preço é conhecido e aceite, e é que uma máquina realmente sem discos passa a ler-se como não estabelecida e pede um reconhecimento ao repor. É o lado em que errar não custa nada.
O veredicto está também ordenado de propósito: comprovadamente fora vence não medido. Um contentor com uma montagem ligada e uma linha ilegível é parcial e não desconhecido, porque a parte que importa está provada. A linha ilegível não desaparece; conserva a sua própria linha com a sua própria palavra.
Não aplicável não é o mesmo que excluído
Um leitor ótico recebe um estado de cobertura próprio, e a distinção não é preciosismo mas a ação que dela decorre.
Excluído significa que há dados do cliente fora do arquivo e que existe uma caixa no Proxmox que muda isso. Um leitor ótico não leva dados desta máquina: é uma imagem de uma biblioteca, ou o disco de inicialização refeito a cada arranque, e o Proxmox salta-o antes de avaliar qualquer outra coisa. Se um leitor ótico se chamasse excluído, toda a máquina com uma imagem no leitor seria parcial e toda a reposição pediria um reconhecimento sobre um leitor onde não há nada. As pessoas aprenderiam que o reconhecimento não significa nada, e então não significaria nada.
A linha aparece na mesma na tabela, com a sua própria palavra. Uma linha ausente levanta a dúvida de se sequer se olhou, e é justamente a ambiguidade que a marca de leitura elimina.
O reconhecimento falha para o lado seguro
Repor um arquivo cuja cobertura seja algo diferente de um «completa» medido exige assinalar uma caixa que nomeia o que ficou de fora. Também com desconhecida, e essa é a parte deliberada: um ponto de reposição antigo, ou um arquivo criado por outra pessoa, bem pode não ter dados do anfitrião, e a caixa é onde o cliente aprende a verificá-lo por sua conta. Só uma cobertura completa e medida a salta, porque então não há mesmo nada a reconhecer.
A mesma frase guarda duas portas, o ponto de entrada e a função por trás, porque um ecrã não é uma fronteira. E o botão de confirmação não é desativado enquanto o painel está aberto: um elemento desativado não consegue reter o foco, pelo que uma caixa de diálogo que desativa quem a abriu não consegue devolver o foco ao fechar e quem navega com teclado acaba no corpo do documento. Um estado de ocupado e um escurecimento fazem o mesmo trabalho sem quebrar isso.
O que ficou fora do arquivo é ainda escrito como evento sobre a reposição, ao nível de aviso, com os pontos de montagem nos seus dados. Uma reposição que correu bem em silêncio deixando três pastas para trás deve continuar a poder ser encontrada um mês depois por alguém que não esteve presente.
O que deixaríamos escrito
- Meça a cobertura, não a deduza. «A cópia correu bem» e «os seus dados estão na cópia» são duas afirmações sobre coisas diferentes.
- Verifique se um valor por omissão é o mesmo dos dois lados da sua abstração. Aqui uma opção ausente significa sim para um tipo de convidado e não para o outro, e uma frase partilhada é falsa em exatamente um ecrã sem erro em lado nenhum.
- Leia o código que constrói a lista a sério, não apenas o manual. Três das nossas regras estavam erradas até o fazermos, e uma delas no sentido que parece prudente.
- Dê ao que não foi medido uma palavra própria e nunca a deixe confundir-se com o sim ou com o não.
- Dê também uma palavra própria ao que não levanta pergunta. Um estado que obriga a uma confirmação sem sentido ensina a ignorar confirmações.
- Separe a observação do juízo. O agente relata o que viu; uma função decide o que isso significa, com testes ao lado e sem que quem relata possa afirmar uma completude.
Para que fique claro o que isto é: as cópias de cliente estão por trás de um interruptor de lançamento desligado por omissão, nada disto é comprável hoje, e as regras foram verificadas contra a documentação e o código do Proxmox e não contra um hipervisor próprio em funcionamento. Três coisas ficam por provar ou deliberadamente fora de âmbito. A cobertura de um ponto de reposição concreto é herdada da execução que o produziu em vez de lida do arquivo. Os discos de máquina virtual com backup=0 veem-se nesta tabela e em mais nenhum sítio do produto. E uma máquina realmente sem discos lê-se como não estabelecida, um preço preferido à alternativa.
Do trabalho de cópias de segurança em Provibr. Porque é que uma reposição nunca testada não é uma cópia está em uma cópia que nunca foi reposta, e o que os três modos do vzdump garantem realmente está em modos vzdump no Proxmox: o que garantem.