Uma cópia que nunca foi restaurada não é cópia

Toda a gente concorda com o título. Quase nenhum painel o reflete.

A razão não é preguiça. É que três peças de prova genuinamente diferentes chegam pelo mesmo cano, ficam guardadas em colunas vizinhas e acabam desenhadas como um único visto verde. Assim que são um só visto, a afirmação mais forte do grupo pede emprestada, em silêncio, a credibilidade da mais barata, e um cliente lê «protegido» quando o que aconteceu de facto foi um trabalho ter terminado com zero.

Passámos uma ronda a separar essas três coisas no nosso próprio esquema, e uma segunda ronda a medir um Proxmox Backup Server real para descobrir qual delas nos consegue dar de facto. Foi nisto que ficámos.

Três provas, e não são intermutáveis

A primeira é a mais barata e é a que todos os produtos mostram. Vale exatamente o que diz: um processo terminou. As garantias por trás de cada modo do vzdump dizem respeito ao que esse processo podia e não podia prometer sobre o estado do convidado, e nenhuma dessas garantias sobrevive ao contacto com um depósito de blocos corrompido depois disso.

A segunda é prova a sério e é fácil de ler a mais. Mais sobre isso abaixo.

A terceira é a única que responde à pergunta que o cliente está de facto a fazer, e é a única que exige que construa alguma coisa em vez de ler alguma coisa. Essa assimetria é a razão pela qual costuma faltar.

O que uma verificação verde afirma de facto

O Proxmox Backup Server consegue verificar um snapshot: relê os blocos e confronta-os com o manifesto. Quando isso aconteceu, a listagem de snapshots transporta um objeto verification com um estado lá dentro.

Isso é genuinamente útil de saber, e é mais estreito do que parece. Diz que os bytes naquele repositório de dados são os bytes que foram escritos. Não diz que a máquina vai arrancar. Não diz que a aplicação lá dentro vai iniciar. Não diz que a base de dados estava num estado consistente no momento do snapshot. E se a cópia estiver cifrada do lado do cliente, não diz que alguém ainda tem a chave: uma verificação de integridade sobre texto cifrado passa perfeitamente bem quando a chave desapareceu.

Portanto o estado vive na sua própria coluna no nosso esquema, e está documentado no código como pertencendo à prova dois, para nunca ser misturado com «restauro provado». A prova três terá a sua própria tabela no dia em que alguém a construir. Acrescentar um quarto valor a uma enumeração existente teria dado meio dia de trabalho e uma fonte permanente de confusão.

Um campo em falta não é uma falha

A nossa coluna tem três valores: ok, falhado e desconhecido. O do meio não é o interessante.

Medido contra um Proxmox Backup Server 4.2 vivo com snapshots reais: um snapshot que nunca passou por uma tarefa de verificação simplesmente não tem chave verification. O campo está ausente. Isso é uma coisa diferente de uma verificação que correu e falhou, e juntá-las custa-lhe nas duas direções. Assuma ok por omissão e todos os snapshots por verificar passam a verificados. Assuma falhado e todos os snapshots históricos na sua base de dados estão de repente a arder. O terceiro valor existe para dizer a única coisa verdadeira: nada se sabe.

Um armazenamento simples do Proxmox nunca preenche a coluna de todo, porque a sua listagem de conteúdo não transporta conceito nenhum de verificação. Isso não é uma lacuna na nossa integração. É a resposta.

Mais um pormenor honesto, porque é do tipo que se arredonda. O objeto verification que medimos transporta um estado e um identificador de tarefa, e nenhuma marca temporal. Portanto o momento «verificado em» que registamos é o momento em que nós vimos esse estado pela primeira vez, o que é uma pergunta diferente de «quando é que o armazenamento verificou isto». Responde a «desde quando sabemos isto». Se uma versão futura expuser a hora verdadeira, a coluna deve passar a transportá-la e o comentário que explica tudo isto deve ser apagado.

Vazio tem de significar vazio

Eis a regra mais afiada de toda esta área, e não tem nada que ver com verificação.

Qualquer sistema que liste pontos de restauro periodicamente acaba por derivar alguma coisa da ausência de um snapshot: estava aqui na semana passada, não está aqui agora, logo foi podado ou eliminado. Essa inferência sustenta peso, e só é válida se uma listagem vazia bem-sucedida for genuinamente vazia.

Por isso medimos o que um servidor de cópias responde de facto quando uma listagem corre mal, porque «um vetor vazio» e «um erro que se parece com um vetor vazio» têm de ser distinguíveis. Quatro casos, todos medidos contra essa mesma instância 4.2 viva:

• um espaço de nomes vazio responde 200 com um vetor vazio;
• um espaço de nomes que não existe responde 400 com um erro de não encontrado, e não uma lista vazia;
• um repositório de dados que o token não pode auditar responde 403;
• um token inválido responde 401.

Três desses quatro têm de passar a erros específicos em vez de resultados. Se algum deles puder chegar à sua lógica de reconciliação como «a listagem teve sucesso e não há nada ali», então um erro de escrita no nome de um espaço de nomes marca todo o histórico de cópias de um cliente como desaparecido. O modo de falha não é uma indisponibilidade. É um ecrã que discretamente deixa de mencionar que existem cópias.

Esta é a mesma classe de armadilha que um hipervisor a responder 200 antes de o trabalho ter começado: o código de resposta está bem, e não é a resposta à sua pergunta.

A credencial não deve conseguir estragar nada

A decisão de segurança mais útil aqui é também a mais aborrecida.

O token que um cliente cria para um destino de cópias precisa de ler snapshots e o estado do repositório de dados. Não precisa de eliminar, esquecer, podar nem verificar. Essas são operações separadas que pertencem a quem é dono do armazenamento, no seu próprio horário, com a sua própria identidade.

Construímos a integração sem comando de escrita nenhum, o que torna a afirmação estrutural em vez de aspiracional, e depois verificámo-la do outro lado: com um token que detém apenas direitos de auditoria, uma eliminação sobre um snapshot responde 403. É essa a forma a que se deve apontar. Uma integração só de leitura cuja credencial é capaz de podar é uma integração só de leitura exatamente até alguém escrever um ciclo com um erro de uma unidade.

Há um corolário que os fornecedores de alojamento erram na direção oposta. Se a sua plataforma eliminar um servidor, a questão da retenção é uma decisão que o cliente tem de tomar, não uma predefinição que o seu código escolhe. Remover a única cópia restante dos dados de alguém como efeito secundário de arrumar uma linha é uma coisa que aconteceu a empresas reais.

O que um teste de restauro tem de ser, se construir um

A prova três é onde está o trabalho, e vale a pena escrever as restrições antes de escrever o código, porque quase todas dizem respeito a não provocar um incidente com o seu teste.

Um teste de restauro precisa de um sítio isolado para onde restaurar: uma rede sem rota para produção, identificadores temporários, endereços temporários, endereços de hardware temporários. Nunca o endereço de produção, e nunca o endereço de hardware de produção, porque um duplicado numa rede viva é uma indisponibilidade que causou enquanto verificava que conseguia recuperar de uma indisponibilidade. Precisa de quotas estritas, porque restaurar a maior máquina de uma frota para um conjunto de teste é um acontecimento de capacidade. Precisa de um prazo e de uma limpeza garantida, já que a máquina por vezes não vai chegar a arrancar e alguma coisa tem de a remover à mesma. E precisa de não enviar notificações, porque um alerta de monitorização vindo de uma cópia de teste que finge ser o sistema verdadeiro vai acordar alguém.

Precisa também de uma política de conclusão explícita, e é aqui que a coisa toda merece o seu nome. Arrancada é um nível. Alcançável é outro. Agente convidado a responder é outro. Sistemas de ficheiros montados é outro. Uma aplicação a responder a uma verificação de saúde definida pelo cliente é o nível que corresponde ao que um cliente quer dizer com «recuperável». Escolha um, registe qual escolheu ao lado do resultado, e nunca deixe um nível mais baixo ser apresentado com o rótulo de um mais alto.

Só então é que um servidor pode mostrar «restauro provado», e deve transportar a data, o ponto de restauro exato, o ambiente em que correu, as verificações que passaram e durante quanto tempo a prova é guardada. Menos do que isso e a expressão é decoração.

O que escreveríamos

1. 01Nomeie as três provas separadamente no seu esquema, antes de ter as três. As nossas são colunas separadas e uma tabela que ainda não existe, o que é mais fácil de ler do que uma coluna com um comentário a pedir desculpa.
2. 02Guarde «desconhecido» como um valor a sério. Qualquer predefinição que não seja «desconhecido» é uma mentira acerca de pelo menos uma das suas linhas.
3. 03Faça uma listagem vazia provar que está vazia, e transforme todas as outras respostas num erro distinto antes de chegarem a seja o que for que reconcilie.
4. 04Dê à integração uma credencial que não consiga eliminar, e depois verifique de fora que não consegue.
5. 05Escreva o que «restauro» teria de significar para si, a que nível de conclusão, antes de alguém pôr um visto verde ao lado.

O nosso próprio estado, dito com clareza: as duas primeiras provas estão construídas e medidas, e não temos teste de restauro. A funcionalidade de cópias está atrás de um interruptor e não está à venda. É essa a diferença entre um plano e uma afirmação, e é a mesma diferença de que trata este artigo inteiro.

A integração por trás destas medições foi construída para o Provibr. A questão relacionada do tempo, o que acontece quando uma cópia demora mais do que o prazo que lhe deu, está em um prazo não é um botão de paragem; o lado dos contentores nas cópias do Proxmox está em VM ou contentor no Proxmox.