Se o arquivo de configuração de uma máquina quebrar: onde fica a versão antiga

Cada máquina virtual e cada contêiner tem um pequeno arquivo de texto. Quantos núcleos, quanta memória, qual disco, qual rede: está tudo ali, escrito de um jeito que um humano consegue ler.

O que acontece se esse arquivo quebrar, onde fica a versão antiga, e a que você precisa prestar atenção se editar à mão?

Primeiro a boa notícia: um arquivo quebrado só afeta a própria máquina

Cada máquina tem seu próprio arquivo. Um erro de digitação em um deles não derruba o painel, não para as outras máquinas, não afeta o servidor.

O sintoma costuma ser este: aquela máquina deixa de aparecer na lista, ou se recusa a iniciar. Todo o resto continua funcionando normalmente. Saiba disso antes de entrar em pânico, porque a primeira impressão costuma ser "o sistema quebrou" e não é o caso.

Como ele quebra

Edição à mão. É a causa mais comum. Uma vírgula, uma aspa, um nome de chave escrito errado.

Edição com a máquina ligada. Mesmo que o arquivo não quebre, acontece algo que você não espera: sua mudança passa a valer no próximo início enquanto você acha que valeu na hora. Ou o sistema atualiza o arquivo por conta própria e sobrescreve o que você escreveu.

Uma escrita interrompida no meio. A energia cai, o disco enche, o processo é morto. O arquivo fica pela metade.

O terceiro é o mais traiçoeiro e merece um título próprio.

Um arquivo escrito pela metade é pior que nenhum arquivo

Se um arquivo não existe, esse é um estado óbvio. Um programa olha, não encontra, diz "não tem" e segue com os padrões. Esse estado se trata com facilidade.

Um arquivo escrito pela metade não é assim. Ele parece um arquivo. O programa checa se existe, encontra, confia, e tenta trabalhar com os dados incompletos que estão dentro. O problema não aparece na hora da leitura, mas depois.

A solução é simples e vale para toda escrita: não sobrescreva o arquivo diretamente. Escreva primeiro com um nome temporário e depois mova para o lugar. Uma movimentação acontece por inteiro ou não acontece; não existe meio-termo. Assim o conteúdo do arquivo é o antigo ou o novo, nunca a metade.

Se você está escrevendo um script que mexe na configuração do Proxmox, esse único hábito vale mais do que todo o resto do código que você vai escrever.

A versão antiga fica em dois lugares

Dentro do backup. O backup de uma máquina leva não só o disco mas também o arquivo de configuração como ele estava naquele momento. Quando você restaura o backup, a configuração volta junto. A maioria pensa em backup só como dados e nunca percebe que tem nas mãos um caminho de recuperação.

Dentro do instantâneo. Quando você tira um instantâneo, a configuração daquele momento é gravada em uma seção nomeada do mesmo arquivo. Ou seja, o arquivo carrega dentro de si parte da própria história.

Mas esses dois não substituem um ao outro, e a diferença importa: o registro do instantâneo fica dentro do mesmo arquivo. Se o arquivo em si for destruído, aquele registro vai junto. Um backup está em outro lugar. O caminho real de recuperação é o backup; um instantâneo é apenas um ponto ao qual você talvez queira voltar.

Se for editar à mão

Pare a máquina primeiro.

Faça uma cópia antes de editar, e coloque essa cópia em outro lugar. O lugar onde a configuração vive foi projetado para configuração; não deixe backups ali.

Depois da mudança, inicie a máquina e veja que ela realmente funciona. Não deixe para o próximo reinício e esqueça; uma edição pela metade esquecida volta meses depois como um defeito que ninguém liga a nada.

A regra geral: "arquivo ausente" e "arquivo quebrado" são estados distintos

O caminho de recuperação de um programa costuma ser escrito pensando no estado "arquivo ausente", porque é o primeiro que vem à cabeça. O estado "o arquivo existe mas o conteúdo está quebrado" não vem à cabeça.

E é justamente o segundo que é perigoso de verdade, exatamente por não ter sido pensado. E os dois têm cara diferente: um arquivo ausente carrega uma marca, um conteúdo quebrado não.

O que o Atlas faz

O Atlas mantém alguns arquivos de ajustes próprios, e aqui há várias coisas a contar com honestidade, porque todas foram encontradas medindo.

Dois arquivos irmãos se comportavam de formas diferentes. Um se reparava sozinho quando seu arquivo estava corrompido: colocava o quebrado de lado e começava limpo. O outro não: levantava um erro e parava ali, ou seja, aquele recurso ficava permanentemente inutilizável e o usuário não tinha como consertar pelo produto.

A causa era exatamente a regra acima: o ramo de recuperação foi escrito para o estado "arquivo ausente". Um erro de conteúdo quebrado não carrega essa marca, então o ramo não pegava e o erro escapava para cima.

As cópias colocadas de lado nunca eram limpas. Cada evento de corrupção deixava um arquivo permanente, sem teto de quantidade. Medido em uma máquina em serviço: duas estavam lá havia meses. É a mesma regra escrita em outras partes desta wiki: tudo que escreve precisa de um teto.

Duas colocações de lado no mesmo instante produziam o mesmo nome e a segunda cópia sobrescrevia a primeira, de modo que uma versão quebrada sumia em silêncio.

Tudo foi corrigido, e ao próprio passo de colocar de lado foi imposta uma regra: ele nunca levanta um erro, em nenhuma circunstância. Colocar de lado é um passo de recuperação, e um passo de recuperação não pode virar uma nova fonte de defeito. Essa frase parece pequena, mas é a que qualquer um que escreva código de recuperação deveria pendurar na parede.