Pritunl: estado de controlo versus perfil gerado

Um arquivo restaura uma implementação Pritunl funcional; o outro restaura uma imagem dela. Um perfil de cliente, uma cópia da configuração do anfitrião e um tarball do diretório de estado parecem todos cópias de segurança, e nenhum deles sozinho devolve as organizações, os utilizadores e as definições de servidor que o Pritunl gere. A diferença está na propriedade: parte do estado pertence a uma base de dados, parte ao anfitrião e parte é saída regenerada. Escolha a camada errada e a restauração produz um servidor que arranca, escuta e não sabe nada. Esta comparação separa as três camadas para que o arquivo que guarda corresponda à falha de que está a recuperar.

Dois objetos parecem cópias de segurança e só um restaura o serviço

Um perfil de cliente descarregado contém um certificado, uma chave e um endpoint. Está completo para esse dispositivo e é inútil como registo da implementação: não transporta organizações, nem utilizadores desativados, nem rotas de servidor, nem contas administrativas. Restaurar a partir de uma pasta de perfis dá clientes que não conseguem autenticar-se contra nada.

Uma cópia da configuração do anfitrião é igualmente parcial. /etc/pritunl.conf contém definições ao nível do anfitrião, incluindo como chegar à base de dados, e não contém os próprios objetos VPN.

O que a base de dados possui e o que o anfitrião possui

O Pritunl guarda definições de servidor, utilizadores, organizações e chaves no MongoDB. Essa base de dados é o plano de controlo autoritativo, e cada ficheiro OpenVPN gerado no disco é saída derivada dela. Uma alteração feita diretamente num ficheiro gerado sobrevive até à regeneração seguinte e depois desaparece, e é por isso que editar ficheiros de execução não é uma correção duradoura. A mesma regra aplica-se a rotas e interfaces efetivas: descrevem o que o plano de controlo produziu, não o que deveria produzir.

O anfitrião contribui com um conjunto de valores mais pequeno mas não transferível. Um deles é /var/lib/pritunl/pritunl.uuid, a identidade desse nó em particular.

Essa identidade importa sobretudo num cluster. Um anfitrião de substituição precisa do seu próprio registo em vez de um clone do UUID de um nó ativo, ou os dois disputam a mesma identidade. Registe a correspondência entre cada anfitrião, o seu UUID e a base de dados para a qual aponta, porque um único dump da base de dados não descreve que definições do anfitrião pertenciam a que máquina. Versões de software e nomes de endpoints públicos pertencem ao mesmo registo.

Faça um dump consistente, não uma cópia de diretório

Copiar o diretório de dados do MongoDB enquanto o serviço escreve produz ficheiros que podem não formar uma base de dados utilizável. Use, em vez disso, o caminho de dump suportado pela base de dados, executado contra a topologia que realmente tem:

mongodump --uri="mongodb://127.0.0.1:27017/pritunl" --out=/var/backups/pritunl/db
sudo tar czf /var/backups/pritunl/host.tgz /etc/pritunl.conf /var/lib/pritunl/pritunl.uuid

Um anfitrião autónomo tolera essa forma simples. Um conjunto de réplicas precisa de um ponto no tempo consistente, e um dump baseado em oplog tem requisitos que um dump simples não tem. O procedimento suportado depende da sua versão e topologia do MongoDB, por isso não o infira da presença de um diretório de dados. Arquive a camada do anfitrião ao lado do dump, na mesma execução e com o mesmo carimbo temporal.

Ensaie a restauração antes de precisar dela

Uma cópia de segurança que ninguém restaurou é uma hipótese. Construa o serviço numa rede isolada, restaure o dump e reponha os ficheiros do anfitrião:

mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /

Depois verifique os objetos em vez do processo: inicie sessão, confirme que as organizações e os utilizadores estão presentes e arranque um cliente de teste contra uma definição de servidor que reconheça. Evite que o anfitrião restaurado anuncie o endpoint de produção ou aceite ligações reais até que endereços e identidades sejam deliberados. É também aqui que descobre que o arquivo precisa de credenciais que viviam apenas na máquina avariada, por isso guarde as credenciais de recuperação num local independente. Uma restauração que depende do anfitrião que acabou de perder não é um plano de restauração.

Por fim, lembre-se de que um instantâneo antigo restaura decisões antigas. Se um administrador desativou uma identidade depois de o dump ter sido tirado, a restauração volta a ativá-la. A reconciliação após a recuperação pertence ao procedimento, não ao remendo posterior.