O que garantem realmente os modos vzdump do Proxmox

O Proxmox oferece três modos de cópia de segurança na mesma lista pendente, o que os faz parecer três velocidades da mesma coisa. Não são. Diferem naquilo que acontece ao convidado em execução e, por isso, naquilo de que o arquivo é de facto uma cópia.

A versão curta, e depois a longa:

A palavra que faz todo o trabalho nessa tabela é crash-consistent. Quer dizer que o arquivo é aquilo que o disco seria se alguém tivesse puxado o cabo de alimentação naquele instante. Um sistema de ficheiros com journal recupera disso. Uma base de dados com uma transação a meio pode não recuperar, e uma aplicação que guarda estado em dois ficheiros não vai saber que um deles é mais antigo do que o outro.

snapshot não quer dizer sistema de ficheiros em repouso

O snapshot é o modo predefinido e é o único que não interrompe nada. O Proxmox tira uma imagem instantânea ao nível do armazenamento e lê a cópia a partir dela, pelo que o convidado continua a escrever no volume em direto durante todo o tempo.

Há uma forma de tornar esse arquivo melhor: o agente convidado do QEMU pode congelar o sistema de ficheiros dentro do convidado no momento em que a imagem instantânea é tirada, o que descarrega as escritas pendentes e produz um arquivo que o próprio convidado considera limpo. Se o agente convidado estiver instalado, a correr e a responder, é isso que acontece.

A armadilha está nesse «se». Nada no resultado da API lhe diz se o congelamento aconteceu. A tarefa vzdump devolve um identificador de tarefa e, quando termina, um estado. Se o qemu-guest-agent respondeu ao pedido de congelamento é uma linha no registo da tarefa, não um campo que se possa ler de volta.

Este é um ponto de decisão para quem automatiza por cima disto, e vale a pena ser deliberado. Quando construímos o caminho das cópias de segurança para a nossa integração com o Proxmox, acabámos por registar a consistência como aquilo que aconteceu, nunca como aquilo que foi pedido: uma cópia em stop fica registada como consistente, e tanto o snapshot como o suspend ficam registados como crash-consistent, ponto final. Existe no nosso esquema um valor para «o convidado foi posto em repouso» e o agente nunca o emite, porque emiti-lo seria afirmar que conhecemos um congelamento que não conseguimos verificar pela API.

Um arquivo descrito como um pouco pior do que é não lhe custa nada. Um arquivo descrito como melhor do que é custa-lhe o único restauro que interessa.

O suspend põe o convidado em pausa, e não é um meio-termo

O suspend lê-se melhor do que se comporta. As pessoas partem do princípio de que é «snapshot, mas mais seguro», um compromisso entre nenhuma paragem e a paragem completa. O que faz na realidade é pôr o convidado em pausa enquanto os dados são lidos.

Dá-lhe a mesma garantia de crash-consistency que o snapshot, porque pôr uma máquina em pausa não é o mesmo que deixá-la descarregar o que tem pendente e assentar. Fica com uma interrupção e sem promessa mais forte. O caso a favor é estreito: um armazenamento que não consegue tirar imagens instantâneas de todo, onde o modo snapshot não tem nada de onde partir.

O stop é a única garantia honesta

O stop desliga o convidado, faz a cópia e volta a iniciá-lo. É a interrupção mais longa e o único modo em que o arquivo é, sem ambiguidade, a cópia de um sistema de ficheiros onde ninguém estava a escrever.

Para um servidor de base de dados que alguém vai restaurar sob pressão às três da manhã, esse preço não é pesado. Para um parque de servidores web é um preço que ninguém paga todas as noites. As duas são respostas certas a perguntas diferentes, e é por isso que o modo pertence à política e não a uma única definição global.

Um pormenor de implementação conta aqui. Como o stop e o suspend interrompem ambos uma máquina em funcionamento, um valor de modo em falta ou desconhecido nunca pode cair num deles. No nosso esquema de comandos, o modo viaja como a palavra literal do Proxmox (snapshot, suspend, stop) e não como vocabulário nosso, e um valor por definir resolve-se em snapshot. Uma tabela de tradução entre as nossas palavras e as deles poria uma tradução errada exatamente onde uma tradução errada desliga a máquina de um cliente.

Os parâmetros que decidem se o trabalho chega a correr

Antes da consistência há uma pergunta mais aborrecida: o vzdump chega sequer a arrancar? Quatro coisas no pedido decidem isso, e três delas falham de maneiras difíceis de ler.

O armazenamento de destino tem de aceitar cópias de segurança. O armazenamento do Proxmox tem uma lista content, e só um armazenamento cuja lista inclua backup pode receber um vzdump. Isto não é um conselho. Envie o trabalho para um armazenamento que só guarda imagens de disco e o Proxmox recusa-o com uma mensagem do género storage 'x' does not support vzdump backups. Exata, e sem significado nenhum para o cliente que carregou no botão. Vale a pena verificar antes de submeter, para que a recusa possa antes dizer «este armazenamento não aceita cópias de segurança».

Um caso aparentado: um armazenamento que aparece na lista de recursos do cluster com o estado unknown está configurado mas não responde. Uma partilha NFS em baixo parece exatamente um destino válido até ao instante em que o trabalho falha.

A compressão tem um valor que não é a palavra que se espera.

O Proxmox escreve «sem compressão» como 0 e não como none. Enviar none é o tipo de erro que produz uma recusa silenciosa em vez de uma recusa clara, e é a razão pela qual a nossa bateria de testes verifica a cadeia exata que sai do agente, em vez de verificar apenas que a chamada teve êxito.

A notificação por correio vem barulhenta por omissão, e para a pessoa errada. Sem um mailnotification=failure explícito, o Proxmox envia correio a root@pam depois de cada cópia. Numa máquina gerida a partir de uma plataforma, isso é correio para o fornecedor sobre algo que o cliente fez.

Dois campos opcionais que vale a pena conhecer. O notes-template anexa uma nota ao arquivo, e o Proxmox expande lá dentro os seus próprios marcadores, como {{guestname}}. O protected=1 marca um arquivo como protegido, e o Proxmox passa a recusar-se a purgá-lo. É esse o mecanismo que quer para a cópia que alguém tira antes de uma alteração arriscada, e exatamente o valor errado por omissão para um trabalho noturno.

A retenção não é um parâmetro do vzdump

Não existe uma definição de retenção no pedido de cópia. A purga é configurada no armazenamento, dentro do Proxmox, e é o dono do armazenamento que decide quanto tempo vivem as cópias.

Isso tem uma consequência de conceção para quem constrói por cima: um painel que ofereça um campo «guardar 7 cópias» ou vai mexer na configuração do armazenamento ou apaga arquivos por si próprio. Não escolhemos nenhuma das duas, e dizemo-lo, em vez de sugerir o contrário com um campo que não faz nada.

Esgotar o tempo não é o mesmo que falhar

Um vzdump de uma máquina grande pode sobreviver a qualquer tempo-limite de pedido razoável. Quando isso acontece, o importante a perceber é que nada foi cancelado: o trabalho continua a correr no hipervisor e vai terminar ou falhar no seu próprio calendário.

Portanto, um tempo-limite é uma afirmação sobre a sua ligação, não sobre a cópia. A execução continua aberta, o identificador da tarefa continua válido, e o que uma interface honesta faz é dizer «ainda a correr» e reconciliar mais tarde. A alternativa, marcá-la como falhada e deixar que alguém comece uma segunda, põe dois trabalhos de vzdump no mesmo armazenamento para a mesma máquina.

Enquanto corre, o progresso verdadeiro está disponível: o vzdump escreve linhas como 12% (1.2 GiB of 10.0 GiB) no registo da tarefa. Uma barra de progresso alimentada por aí é honesta. Uma barra de progresso alimentada por uma estimativa é um palpite com um sinal de percentagem ao lado.

Restaurar é outra pergunta, e o unique é decisivo

A questão do modo termina quando o arquivo existe. O restauro tem a sua própria armadilha, e é de rede.

Restaure um arquivo para uma máquina nova sem pedir identificadores novos e a máquina nova herda os endereços MAC do original. Se o original ainda está a correr, passa a ter duas máquinas com o mesmo MAC na mesma bridge, e o sintoma não é «o restauro falhou» mas «a rede da máquina de produção ficou estranha». O indicador unique na chamada de restauro é o que evita isso, e numa plataforma que restaura ao lado de um original em funcionamento não é uma opção mas uma condição prévia.

Mais duas coisas que vale a pena saber antes do primeiro restauro:

• O storage significa aqui outra coisa. Na cópia é onde o arquivo fica, e precisa de backup na sua lista de conteúdos. No restauro é onde aterram os discos restaurados, e precisa de images. O mesmo nome de campo, outro requisito.
• Só os discos voltam. Uma máquina restaurada é uma máquina com os discos e o hardware do arquivo. As atribuições de endereços, as regras de firewall e a automatização que estivesse ligada ao original vivem nos seus próprios sistemas, não no ficheiro vzdump, e não viajam com ele.

O que não está medido aqui

Tudo o que está acima sobre a forma das chamadas vem do esquema da API do Proxmox e de construir contra ele; a semântica dos modos é do próprio Proxmox, descrita na sua documentação.

O que deliberadamente não afirmamos é quanto custa cada modo em tempo. Não temos duração de pausa medida para o suspend nem paragem medida para o stop: isso depende do convidado, do armazenamento e da quantidade de memória suja, e um número medido numa máquina seria citado como um número geral. Esses têm de vir do seu próprio hardware.

Mais duas lacunas que vale a pena nomear. Tudo aqui diz respeito a convidados QEMU; as cópias de contentores têm as suas próprias regras à volta dos pontos de montagem e das montagens bind, e não as medimos. E não há caminho incremental em nada disto: um vzdump para um armazenamento simples escreve um arquivo completo de cada vez. É para a cópia incremental que serve o Proxmox Backup Server, e esse é outro software com outro conjunto de promessas.

Isto saiu da construção do caminho das cópias de segurança do Proxmox para o Provibr, um painel de gestão de servidores para alojadores, onde uma cópia descrita como melhor do que é seria o pior erro possível. As notas de configuração do lado do hipervisor estão na documentação do Proxmox, e a página da integração com o Proxmox cobre o que o agente consegue fazer.