Externo e recuperação

Os backups locais protegem-no de um container perdido ou de uma atualização má. A replicação externa e um kit de recuperação testado protegem-no da máquina inteira, de ransomware, ou de um incêndio. Esta página cobre replicar para o externo, tornar essa cópia à prova de adulteração, provar que consegue restaurar, e recuperar quando o próprio BombVault desaparece.

Replicação externa

Mantenha o backup local rápido e adicione uma ou mais réplicas externas. Defina um repo por domínio no separador Definições, Externo. O BombVault replica novos instantâneos para lá com restic copy numa base de melhor esforço, por isso um percalço externo nunca faz o backup local falhar. O repo local mantém-se primário.

• Vários destinos externos por domínio. Cada domínio (containers, VMs, flash, config e conjuntos de ficheiros) pode replicar para vários destinos externos de uma só vez, não apenas um, para que possa manter, por exemplo, um rest-server na máquina de um amigo e um bucket S3 em paralelo. Adicione destinos extra em Definições, Externo, cada um com o seu próprio repositório, classe de armazenamento S3, flag append-only, retenção e orçamento de crescimento. Uma configuração externa única existente é transferida intacta como o primeiro destino, e cada destino de um domínio replica no agendamento externo desse domínio.
• Agendamento externo por domínio (editado ao lado de todos os outros agendamentos em Definições, Agendamentos): deixe-o em branco para replicar após cada backup local, ou defina uma cadência (por exemplo weekly Sun 03:00) para enviar para o externo com menos frequência do que faz backup localmente. Um botão Replicar agora cobre as execuções a pedido.
• A retenção externa vive em Definições, Externo para que possa manter as cópias externas por mais tempo como arquivo. Deixe a política toda a zero para nunca aparar automaticamente os instantâneos externos.
• Os limites de largura de banda (Definições, Externo) limitam a taxa de envio/receção do restic para que a replicação não sature a sua WAN.
• Um indicador de replicação mostra qual o domínio que está a replicar enquanto corre (na sua página e no Painel). É um indicador ativo, não uma barra de percentagem, porque o restic copy não expõe nenhum progresso legível por máquina.

Restaurar diretamente do externo

Cada navegador de backups tem um interruptor Local / Externo, por isso, se um repo local se perder ou corromper, pode listar e restaurar diretamente a partir da réplica externa. A eliminação é por origem: remover um backup afeta apenas a cópia que está a ver.

Externo imutável (append-only)

Marque um repo externo como append-only para que ransomware, ou um host comprometido, não possa eliminar ou reescrever os seus backups. O lado remoto (um restic/rest-server a correr em modo --append-only) impõe-no. O BombVault apenas o verifica e nunca mostra verde só com base numa afirmação de configuração.

O assistente de configuração guiada do externo acompanha-o desde a escolha do backend (rest-server / rclone / S3), passando por um snippet de implementação de rest-server pronto a colar, um teste de ligação, o interruptor de imutabilidade (que corre o teste de adulteração de imediato) e uma estratégia de retenção, para que o externo append-only seja alcançável sem editar configs à mão.

Os repos imutáveis nunca são podados a partir desta máquina

Um externo imutável deliberadamente nunca poda instantâneos antigos. Defina um alarme de orçamento de crescimento para ele para ser alertado antes de o tamanho do repo descontrolar.

Teste de adulteração

O BombVault prova periodicamente a garantia append-only tentando de facto uma eliminação contra o repo externo, dirigida a um objeto inexistente:

• Recusada significa protegido.
• Aceite significa não protegido.
• Um resultado inconclusivo (servidor inacessível, erro de autenticação) nunca inverte o veredicto guardado.

Uma inversão real de protegido-para-desprotegido dispara um único alerta.

Ensaios de DR

O BombVault oferece dois níveis de prova de que os seus backups são de facto restauráveis, não apenas presentes.

• Ensaios de verificação de restauro (local). O BombVault corre periodicamente restic check --read-data-subset (limitado, nunca um restauro completo que enche o disco) e mostra um selo último verificado como restaurável por domínio. A cadência vive em Definições, Agendamentos; o selo em Definições, Integridade.
• Ensaios de DR (externo). O BombVault restaura um alvo real do repo externo para uma sandbox descartável, verifica-o ficheiro a ficheiro e byte a byte, e depois limpa. Isto prova que consegue recuperar do externo, não apenas que o repo responde.

O scorecard de proteção contra ransomware no Painel resume isto numa postura verde / âmbar / vermelha por domínio, com uma checklist com marca de idade (externo configurado, append-only verificado, replicação atual, ensaio de restauro passado, encriptação ligada, estratégia de poda definida). Cada linha vermelha liga diretamente à correção, e o cartão só fica verde com factos verificados.

Painel recetor (o lado que recebe)

Tudo acima é o lado emissor. Na máquina que recebe cópias externas imutáveis de outro BombVault, o painel Recetor dá-lhe monitorização independente e só de leitura desses repositórios no hardware recetor, para que uma falha silenciosa no lado remoto não passe despercebida.

Ligue o interruptor Recetor em Definições para revelar um separador Recetor. Está desligado por predefinição; ative-o apenas numa máquina que de facto recebe backups externos imutáveis. Depois registe um repositório recebido (só de leitura, aberto com a chave da instância emissora) para obter:

• Um inventário de instantâneos agrupado por origem, para que possa ver exatamente quais containers, VMs e conjuntos de ficheiros aterraram.
• Último recebido por origem, para que saiba quão fresco cada um é.
• Um restic check independente corrido no hardware recetor, para que a integridade seja verificada onde os dados de facto residem, não apenas no emissor.
• Um interruptor de homem-morto: um alerta quando uma origem deixa de enviar dentro de uma janela que definir.
• Alertas de integridade: um alerta quando uma verificação no lado recetor falha.

O Recetor é estritamente só de leitura. Nunca escreve no repositório recebido, por isso nunca pode quebrar a garantia append-only da qual o emissor depende.

Recuperação guiada

Um separador Recuperação dedicado acompanha uma instalação de raiz ou reconstruída pelo caso de desastre, num só lugar:

1. Restaura primeiro as próprias definições do BombVault, para que os caminhos de backup, os destinos externos e as credenciais de que o resto do fluxo precisa venham pré-preenchidos (aplicado através de um reinício automático sobre o socket Docker, para que a base de dados de definições em execução nunca seja sobrescrita sob um handle aberto).
2. Verifica que o BombVault consegue ler os seus backups (o senão da chave de encriptação logo à partida).
3. Deixa-o apontar para o seu repo existente (local ou externo).
4. Descobre os containers, VMs e conjuntos de ficheiros nele armazenados.
5. Restaura-os todos (deixados parados, para que os inicie deliberadamente), com o seu kit de recuperação a um clique de distância.

Migração planeada versus desastre

A recuperação guiada restaura as próprias definições do BombVault a partir de um backup. Para uma mudança planeada para uma máquina nova, pode em vez disso levar a sua configuração consigo diretamente com o cartão Exportar e importar definições (um ficheiro JSON portátil). Consulte Configuração.

Restaurar a partir de outro repo BombVault

Um cartão separado no separador Recuperação abre o repo de uma instância BombVault diferente (uma partilha montada sob /mnt, ou um URL remoto) com a APP_KEY dessa instância, numa sessão pontual e só de leitura. Navegue pelos containers, VMs e conjuntos de ficheiros lá armazenados, escolha um instantâneo e restaure-o, e o objeto restaurado torna-se um container, VM ou conjunto de ficheiros local normal. Nada é alguma vez escrito no outro repo, e as suas próprias definições de backup ficam intactas (a sessão vive em memória e expira por si própria). Mover um container do servidor A para o servidor B deixa de significar reapontar as suas definições de repo e revertê-las depois. A federação ao vivo servidor-a-servidor está explicitamente fora de âmbito; isto é um puxão pontual deliberado.

Kit de recuperação da chave de encriptação

Esta é a peça que torna a recuperação de desastres possível mesmo quando não existe um BombVault em execução.

Um clique transfere a chave mestra, a palavra-passe restic derivada, e as localizações e comandos exatos do repo, para que possa restaurar diretamente com a CLI do restic em qualquer máquina. Um lembrete no Painel insiste até o ter guardado.

Guarde o kit de recuperação fora do servidor

O kit contém o segredo que decifra os seus backups. Guarde-o num local seguro e separado do servidor (um gestor de palavras-passe, uma cópia impressa num cofre). Se perder ambos o BombVault e a APP_KEY sem kit de recuperação, os seus backups encriptados não podem ser recuperados.

Como as definições de recuperação vivem dentro de cada repo (<repo>/def, <repo>/vm-def), uma pasta de repo copiada é totalmente autossuficiente, por isso o kit mais o repo é tudo o que um restauro em bare-metal precisa.