Funcionalidades¶

O BombVault é simples por predefinição e profundo quando precisa. A interface mostra apenas o essencial até acionar o interruptor Vista simples / Vista avançada. Esta página agrupa o conjunto completo de funcionalidades.

Âmbito do backup¶

Os contentores, cada um com o seu interruptor de agendamento, ordem de cópia e histórico próprio.

Os contentores, cada um com o seu interruptor de agendamento, ordem de cópia e histórico próprio.

O quê	O que é guardado
Containers Docker	Diretório appdata mais a definição do container (imagem, variáveis de ambiente, portas, etiquetas, volumes). Por predefinição, o diretório appdata inteiro; Escolher pastas no container marca exatamente as pastas que o backup abrange, com uma contagem em tempo real dos caminhos, uma lista do que deixou de fora e um interruptor Ignorar pastas de cache por raiz (`CACHEDIR.TAG`).
VMs KVM / libvirt	Imagem(ns) de disco da VM, definição XML e NVRAM UEFI (encerramento ordenado ou instantâneo a quente, por SSH). Os instantâneos a quente recorrem automaticamente a um backup ordenado se o instantâneo não puder ser criado, de modo que um backup de VM nunca falha sem mais nem menos. Com Só blocos alterados ligado, uma VM em execução com discos qcow2 é lida através de checkpoints do libvirt, por isso um backup lê só os blocos escritos desde o anterior, e cada snapshot continua a restaurar sozinho o disco inteiro. Os discos em zvols ZFS são transmitidos com `zfs send` pela mesma ligação SSH, por isso uma VM cujos discos são zvols tem backup como uma só VM. O estado de um vTPM em passthrough é guardado junto da NVRAM quando o XML do domínio indica o seu caminho. Um vTPM emulado, que o TrueNAS configura para convidados Windows 11, não publica esse caminho, por isso tenha à mão a chave de recuperação de um convidado assim. Consulte o guia de backup de VMs.
Flash do Unraid	Toda a pen USB flash (`/boot`): SO, licença, configuração do array, partilhas, rede e configuração de plugins. O restauro é uma transferência `.zip` com um clique e nunca sobrescreve o flash em execução.
Configuração da aplicação	O próprio `/config` do BombVault (base de dados de definições, credenciais externas, par de chaves SSH do libvirt), capturado com `VACUUM INTO` do SQLite para que uma base de dados em modo WAL nunca seja capturada a meio de uma escrita. Restaurado através de um reinício automático, para que a base de dados em execução nunca seja sobrescrita sob um handle aberto.
Ficheiros e pastas	Conjuntos de ficheiros nomeados: qualquer pasta no servidor (uma partilha, os seus documentos, uma biblioteca de fotos), cada um com padrões de exclusão opcionais por conjunto. Paridade total com os outros domínios (agendamentos, retenção, cópia externa, verificações de integridade e ensaios de restauro).
Conjuntos de dados ZFS	Um conjunto de dados com todos os que estão abaixo dele, lido de um único instantâneo ZFS para que todos venham do mesmo instante, e guardado com o restic como uma pasta: deduplicado, navegável, com restauro de ficheiros individuais. Os novos conjuntos filhos entram sozinhos, pode deixar qualquer um de fora, e um que não se consegue ler é ignorado e indicado pelo nome. Opcionalmente, param-se containers ou corre-se um comando apenas no instante do instantâneo. Os volumes não estão incluídos: o volume de uma VM é copiado com a sua VM, um volume sem VM ainda não é copiado. Veja Conjuntos de dados ZFS.

Restauro¶

A recuperação guiada leva uma instalação nova pelo caso de desastre, tudo no mesmo sítio.

A recuperação guiada leva uma instalação nova pelo caso de desastre, tudo no mesmo sítio.

Restauro completo com um clique. Escolha um instantâneo, clique em Restaurar. Feito.
Uma linha do tempo por item. Containers, VMs, conjuntos de ficheiros, a flash e a configuração da aplicação listam os seus backups como uma única linha do tempo por todos os locais onde se encontram, o repositório onde são escritos e cada destino externo. Um backup copiado para o externo aparece uma vez, marcado com cada local. Os locais externos são lidos quando os abre, e eliminar num local diz se era a última cópia.
Os containers são reinstalados automaticamente. A definição do container é reproduzida contra a Docker API, para que o container reapareça no separador Docker do Unraid exatamente como estava.
A GPU, os limites e as ligações voltam. Um container restaurado recupera os seus limites de recursos, o driver de registos, as definições de DNS, as ligações antigas e a sua GPU ou runtime (--gpus, --runtime=nvidia). Num host sem esse driver de GPU ou runtime, o restauro diz isso e oferece Restaurar sem GPU e runtime, também depois de restaurar vários containers ou uma stack. Uma ligação a um container que falta, ou que está parado quando o restaurado arranca, fica de fora, e o histórico de execuções indica-o.
As VMs são recriadas automaticamente. O XML é reimportado por SSH para que a VM reapareça no VM Manager com o seu disco e a NVRAM UEFI reanexados, mesmo depois de a VM ter sido eliminada. Descobrir backups reconstrói uma entrada que desapareceu por completo (por exemplo, depois de uma instalação de raiz).
Restauro individual. Restaure um container, uma VM ou um conjunto de ficheiros sem tocar nos outros.
O restauro do flash é uma transferência .zip. Transmite para o seu browser como flash-<id>.zip, pronto a largar no criador de USB do Unraid. O /boot em execução nunca é tocado.
Um plugin de cada vez. A página Flash lista os plugins de cada cópia do flash com versão e tamanho, e repõe um único plugin na pen em uso: o ficheiro .plg, a pasta em config/plugins e os ficheiros de pacote que a cópia contém. Nada mais muda na pen. O Unraid instala o plugin no próximo arranque, ou logo em Plugins, Install Plugin.
Exportação zip agendada do flash. Depois de cada backup do flash, opcionalmente escreva o instantâneo como um .zip simples para uma pasta que escolher (um único flash-latest.zip sobrescrito ou um histórico rotativo). Aponte-o para uma pasta Syncthing ou rclone para que o seu backup do USB de arranque saia do servidor automaticamente.
Verificação de conflitos pré-voo. Antes de qualquer coisa ser parada ou removida, o restauro verifica que o IP estático do container e as portas do host publicadas estão livres, e aborta com uma mensagem clara em vez de deixar um restauro a meio.
Verificações antes do restauro. Cada janela de restauro verifica primeiro se o repositório responde, se a chave guardada o abre, se o ponto de restauro existe e se o destino tem espaço para o que o restauro grava. Iniciar fica bloqueado enquanto uma verificação falhar, e o (i) do botão diz qual.
Plano de restauro. Antes de confirmar, a janela mostra o que o restauro faz em relação ao que existe agora: arquivos novos, substituídos e inalterados, com a lista a pedido, e os arquivos do destino que não estão no backup e ficam onde estão. Para containers e VMs compara também as configurações recriadas com as que estão rodando: imagem e tag, portas, nomes de variáveis e volumes, ou memória, vCPUs, discos e rede. O restic calcula isso como uma simulação por tamanho e data de modificação, sem ler os arquivos; uma árvore muito grande para após 30 segundos e avisa. Um restauro de stack verifica e planeja cada membro e nomeia o que o bloqueia.
Pastas compartilhadas. Um restauro no local nomeia cada outro container, rodando ou não, cuja montagem alcança uma pasta em que ele grava, por exemplo "este caminho também é usado por nextcloud-db". Avisa e não bloqueia.
Restauro ao nível do ficheiro. Expanda os Ficheiros de um instantâneo de container, filtre, marque qualquer número de ficheiros e pastas e depois restaure a seleção no local ou para uma pasta que escolher.
Restauro de conjunto de ficheiros. Restaure um instantâneo de conjunto de ficheiros no local (após uma confirmação explícita) ou para uma pasta que escolher, nunca em silêncio. O restauro seletivo também funciona aqui.
Restauro de conjuntos de dados ZFS. Restaure um conjunto de dados de um item no seu lugar (depois de um instantâneo ZFS de segurança que fica até o apagar), numa pasta ou só os ficheiros que escolher, ou todos os conjuntos de uma cópia numa pasta. Um conjunto de dados nunca é revertido nem substituído.
O restauro mantém o estado de execução. Um container ou VM que estava em execução quando foi copiado volta em execução; um que estava parado permanece parado. Marque Deixar parado após o restauro para recriar sem iniciar.
Restaurar uma stack inteira. Os containers do mesmo projeto Docker Compose são agrupados num painel Stacks. Restaurar stack… reconstrói cada membro a partir do seu último backup, deixando-o parado, e depois, opcionalmente, inicia-os por ordem depends_on.
Progresso ao vivo, cancelamento e feedback de ocupação. Um restauro longo mostra uma barra de percentagem ao vivo e pode ser cancelado com uma confirmação sensível ao tipo. Um restauro cancelado é registado como cancelado, não falhado.
Recuperação guiada. Um separador Recuperação dedicado acompanha uma instalação de raiz pelo caso de desastre. Consulte Externo e recuperação.
Restaurar a partir de outro repo BombVault. Uma sessão pontual e só de leitura abre o repo de uma instância BombVault diferente com a APP_KEY dessa instância, para que possa puxar um container do servidor A para o servidor B sem tocar nas suas próprias definições. Consulte Externo e recuperação.
As propriedades ZFS voltam. Cada cópia ZFS guarda as propriedades definidas localmente de cada conjunto de dados, como compressão, tamanho de registo, quota e sensibilidade a maiúsculas. Um restauro para um conjunto de dados novo cria-o com elas, e um restauro para um existente mostra-as e só as define se o pedir. Veja Conjuntos de dados ZFS.
Importar do plugin Appdata.Backup. Na página Recuperação, indique ao BombVault a pasta de cópias do plugin. Cada arquivo de contentor torna-se um ponto de restauro do seu contentor, com a data em que o plugin o criou. Os arquivos já importados são ignorados, e os próprios arquivos só são lidos. O contentor precisa antes de uma cópia no BombVault, para que o restauro tenha a sua definição. A retenção não mexe nos pontos de restauro importados, por isso apague manualmente os que já não forem precisos.

Armazenamento e agendamento¶

Backups incrementais e deduplicados via restic, para que até discos grandes de VM não inchem o repo.
Destinos: um caminho local, ou externo. Partilhas SMB e servidores WebDAV (Nextcloud, ownCloud, SharePoint) diretamente a partir de um formulário em Definições, Acesso à nuvem, rclone, sem montagem no host; NFS (monte o export no Unraid e aponte-lhe um Caminho de backup); backends restic nativos sem rclone (s3:..., rest:http://host:8000/repo, sftp:user@host:/repo), ou qualquer remoto rclone via rclone:<remote>:<bucket>/path. Todas as credenciais são guardadas encriptadas.
Os destinos SSH não precisam de nada instalado do outro lado. O sftp: só requer um servidor SSH, por isso um simples Raspberry Pi (sem Docker, sem restic) funciona como destino externo. As chaves de host são fixadas automaticamente no primeiro contacto.
Cópia externa (local + remota). Mantenha o backup local rápido e adicione uma ou mais réplicas externas, replicadas com restic copy numa base de melhor esforço (um percalço externo nunca faz o backup local falhar). Cada domínio tem o seu próprio agendamento externo, mais um botão Replicar agora.
Vários destinos externos por domínio. Cada domínio (containers, VMs, flash, config, conjuntos de ficheiros e conjuntos de dados ZFS) pode replicar para vários destinos externos de uma só vez, não apenas um. Adicione destinos extra na página Externo, cada um com o seu próprio repositório, classe de armazenamento S3, flag append-only, retenção e orçamento de crescimento. A sua cópia externa existente é transferida como o primeiro destino, por isso nada muda até adicionar um segundo, e cada destino de um domínio replica no agendamento externo desse domínio.
Repositórios com nome. Registe uma única vez os seus locais de backup em Definições, Armazenamento, Repositórios, um caminho local ou qualquer remoto restic com o seu próprio conjunto de credenciais, e depois escolha um deles como localização de um item no respetivo cartão. Cada linha mostra quantos itens apontam para esse repositório, e um repositório usado por um item ou por uma localização padrão não pode ser movido nem eliminado, porque o BombVault nunca move um backup que já foi escrito.
Vários conjuntos de credenciais de nuvem. As credenciais de nuvem partilhadas aplicam-se em todo o lado por predefinição, mas qualquer destino pode escolher em vez delas um conjunto de credenciais com nome (Definições, Acesso à nuvem, Conjuntos de credenciais adicionais), por isso um bucket S3 da Hetzner e um servidor Garage local podem funcionar lado a lado, cada um com a sua chave. Isto inclui os destinos externos e um caminho de backup que seja ele próprio um repositório remoto.
Destinos. Um destino externo é configurado uma só vez, através de um assistente que lista serviços de armazenamento S3, o seu próprio servidor S3, o seu próprio servidor e partilhas, e todo o armazenamento na nuvem que o rclone suporta, com o início de sessão, um teste de ligação, um seletor de pastas e uma palavra honesta sobre a proteção contra eliminação. Aparece depois como um botão em cada domínio e item. Consulte Destinos.
Localização por item. Cada cartão de container, VM e conjunto de ficheiros tem uma linha de botões, Local e um por destino externo, e os acesos recebem os seus backups. Uma partilha que já está num NAS deixa de ter de ir também para o B2. A localização fica fixa desde o primeiro backup, as cópias podem mudar a qualquer momento, e o cartão diz quantos locais guardam o item e se o 3-2-1 é cumprido. Consulte Localização por item.
Localizações padrão. Uma linha por domínio define onde os itens novos são escritos e para que destinos são copiados os itens sem escolha própria. Alterá-la não move nenhum backup e diz de antemão que destinos ganham ou perdem itens.
Ordem de backup manual. Defina a ordem exata pela qual os seus containers são copiados a partir do painel de ordem de backup na página Containers. As execuções agendadas e de seleção múltipla seguem-na; qualquer container que deixe sem ordem mantém o comportamento anterior de mais-em-atraso-primeiro, e um backup de um único container não muda.
Retenção configurável: keep-last / diária / semanal / mensal / anual, podada automaticamente após cada backup, definida por origem (tanto a local como a externa em Definições, Retenção, para que possa manter as cópias externas por mais tempo como arquivo). Cada origem pode também seguir regras próprias, em local e no externo (Regras de retenção por origem), por exemplo 7 cópias diárias de contentores que mudam todos os dias e menos de VMs que raramente mudam.
Compressão por repositório: Desligado, Automático (o padrão do restic) ou Máximo, definida em Definições, Armazenamento para cada caminho de backup e cada repositório com nome, e em Definições, Externo para cada destino externo. Os backups, as cópias externas e a poda escrevem com ela, e o kit de recuperação indica-a, para que o restic simples possa continuar a escrever da mesma forma.
Agendamento por domínio (diário / semanal, incluindo conjuntos de vários dias / a cada N dias / cron em bruto), tudo editado num só lugar em Definições, Agendamentos. Um único container, VM, conjunto de ficheiros ou item ZFS pode ter uma cadência própria, e A cada N dias também funciona para o ensaio de restauro, o teste de adulteração e o resumo semanal.
Esperar até a app estar inativa. Um contentor pode fazer a sua cópia programada esperar enquanto a app está ocupada, no máximo as horas que definires, e começá-la assim que a app fica inativa. Um servidor multimédia está inativo quando não faz streaming; qualquer outro contentor, quando a CPU e o tráfego ficam alguns minutos abaixo dos limites em Definições, Agendamentos (na rede do anfitrião só conta a CPU). A cópia em espera aparece no registo de atividade e no contentor com o motivo e o prazo. Não segura nenhum bloqueio, por isso os outros contentores avançam. As cópias manuais nunca esperam. Os membros de um stack de compose que calham na mesma execução esperam juntos, e uma espera continua com o seu prazo depois de um reinício. Desligar os contentores descarta todas as cópias em espera, e desligar o agendamento deles descarta as que as suas execuções retiveram. Baixar as horas também encurta uma espera que já começou.
Limites de largura de banda externa. Limite a taxa de envio/receção do restic para que a replicação não sature a sua WAN.
Primeiro o streaming. Enquanto um servidor multimédia como Plex, Jellyfin ou Emby faz streaming, as cópias externas enviam com um limite mais baixo e voltam ao normal alguns minutos depois do fim do stream. O BombVault lê do Docker o tráfego de saída dos servidores multimédia. REST, S3, B2, Azure, Google Cloud, Swift e rclone por HTTP abrandam a meio da cópia; SFTP e pastas locais ou montadas recebem o limite baixo no próximo passo de cópia. Um servidor multimédia na rede do anfitrião não pode ser medido. Em Definições, Externo.
Classe de armazenamento fria e de arquivo (S3). Para um repo externo S3 nativo pode escolher a classe de armazenamento, restringida a níveis legíveis para restauro (Standard, Standard-IA, One Zone-IA, Intelligent-Tiering, Glacier Instant Retrieval) para que os preços de arquivo nunca quebrem um restauro em silêncio. Os níveis de arquivo profundo que primeiro precisam de um degelo assíncrono (Glacier Flexible, Deep Archive) são deixados de fora intencionalmente. Apenas backends S3 nativos; os remotos rclone definem a sua classe na configuração do rclone.
As pastas de backup permanecem copiáveis para fora da máquina. Depois de cada backup, o BombVault relaxa a árvore do repo local para diretórios 0755 / ficheiros 0644 (os repos são encriptados, por isso nada fica exposto) para que um utilizador de sincronização não-root por SMB não fique bloqueado. As definições de recuperação vivem dentro de cada repo, por isso uma pasta de repo copiada é totalmente autossuficiente.

Perceção, verificação e monitorização¶

Pausa a partir do cartão. Cada cartão de container, VM e conjunto de pastas tem Pausar agendamento, que tira o item do agendamento e do Backup total, e Retomar agendamento para o repor. Define o mesmo interruptor que Incluir no agendamento, por isso os dois concordam sempre. Um item em pausa mostra um emblema cinzento Agendamento em pausa, e Fazer backup agora continua a funcionar.
Estado de proteção (RPO). O Painel mostra um indicador verde / âmbar / vermelho por domínio, comparando o último backup bem-sucedido com o seu agendamento, para que um backup em atraso fique vermelho em vez de se esconder num registo.
Mapa de calor da saúde dos backups. Um calendário ao estilo das contribuições do GitHub dos resultados de backup por dia e por domínio, com um alternador Containers / VMs / Flash / Auto-backup / Pastas.
Cronometragem das execuções em toda a parte. Cada entrada do histórico de execuções lê início, fim (duração), e cada container e VM tem a sua própria lista Execuções recentes na sua página.
Um painel que pode reorganizar. Ative o modo de personalização para arrastar os cartões para a sua ordem e ocultar os de que não precisa. O esquema é guardado por navegador.
Tendência de tamanho do repositório e de deduplicação. Tamanho atual do repo, rácio de deduplicação e contagem de instantâneos por domínio, com um sparkline do crescimento do armazenamento.
Ensaios de verificação de restauro. O BombVault prova periodicamente que os seus backups são restauráveis (restic check --read-data-subset, limitado) e mostra um selo Restaurabilidade verificada por domínio.
Verificação de restauro após o primeiro backup. Quando o primeiro backup de um item termina, o BombVault restaura uma amostra (até 100 ficheiros e 256 MiB) numa pasta temporária dentro da pasta de restauro, faz o restic reler cada ficheiro contra os seus hashes e compara os tamanhos com o backup. Num ficheiro grande demais para a amostra, como um disco de VM, são relidos em vez disso os primeiros 64 MiB. O cartão do item mostra o resultado, uma falha chega como notificação e Verificar restauro executa a mesma verificação no backup mais recente quando quiser. Os backups seguintes não a repetem.
Teste de arranque. Bytes corretos não provam que a aplicação volta a funcionar. Teste de arranque no cartão de um contentor restaura o backup mais recente numa cópia isolada e arranca-a: um nome que começa por bombvault-test-, uma rede Docker interna própria sem portas publicadas nem acesso à LAN, 1 CPU e 2 GiB de memória, e os dados numa pasta temporária dentro da pasta de restauro. O teste passa quando o healthcheck do contentor reporta saudável, sem ele quando a primeira porta exposta responde de dentro dessa rede, e sem nenhum dos dois quando continua a correr. O contentor original nunca é parado nem alterado, e a cópia, a rede e os dados são removidos depois, também se o BombVault reiniciar a meio de um teste. Contentores na rede do anfitrião, privilegiados, com dispositivos ou que precisam de outro contentor aparecem como não testáveis. Ative Teste de arranque nas verificações de restauro agendadas para testar um contentor por execução, começando pelo testado há mais tempo. O resultado aparece no cartão e no painel. A cópia não leva nenhuma etiqueta do original e corre sem as capabilities, opções de segurança, sysctls e cgroup parent que o original acrescenta. Um contentor que precise delas falha o teste, e o resultado diz sem o que a cópia correu.
Operações de auto-recuperação. Um bloqueio restic comprovadamente órfão (deixado por um reinício a meio de uma operação) é forçado a limpar e reexperimentado uma vez, automaticamente. A retenção é estável na identidade (podada por item, imune a alterações de caminho ou de host) e uma falha de retenção envia uma notificação.
Avisos que a análise de pastas não consegue ver. O assistente de exclusões responde a uma questão de tamanho. Alguns dos erros de backup mais caros não são questões de tamanho, por isso ele traz também avisos específicos de cada aplicação sobre a forma como guarda os seus dados. Aquele para o qual existe: o Immich guarda os álbuns, os rostos e as datas de cada foto numa base de dados PostgreSQL que corre num contentor separado, por isso um backup ao nível de ficheiros do contentor do Immich restaura as imagens sem nada disso, e o restauro parece ter funcionado. O aviso aparece quer seja oferecida alguma exclusão quer não, também num contentor sem nada selecionado para analisar, porque o aviso é verdadeiro em qualquer caso.
Sem backup (cobertura). Um cartão do Painel que nomeia tudo o que no servidor não está coberto por nenhum backup automático, com o motivo de cada um: nunca adicionado ao BombVault, presente mas não incluído no agendamento, com o seu próprio agendamento desligado, ou nenhum agendamento ligado em lado nenhum. O indicador de proteção acima responde a outra pergunta, nomeadamente se os backups que estão agendados correram a tempo, e não consegue ver o contentor que ninguém configurou: esse está ausente de todas as listas e de todos os erros, por isso nada fica âmbar por causa dele. Os contentores são lidos da lista do Docker em tempo real e não das linhas do próprio BombVault, porque um elemento sem linha é precisamente o que precisa de ser nomeado. Um tipo de backup que desligou fica totalmente fora da contagem, já que foi escolha sua.
Pré-visualização da retenção. O painel ao lado das definições de retenção mostra o que a próxima execução vai eliminar, antes de acontecer: por repositório e por elemento, com os pontos de restauro nomeados. Não bloqueia o repositório nem altera nada, por isso responde mesmo enquanto um backup está a correr. Uma retenção desligada di-lo em vez de mostrar uma lista vazia, um repositório append-only é assinalado como tal (a retenção nunca corre lá), e um repositório que não pôde ser contactado é nomeado em vez de faltar em silêncio. Em Definições, Retenção para a política local e para a externa, cada uma com a sua própria pré-visualização.
Anomalias. Cada backup de um contentor, de uma VM, de um conjunto de pastas, de um dump de base de dados, da pen flash e do auto-backup é comparado com o histórico próprio desse elemento. As verificações olham para os dados novos de uma execução, face às maiores quantidades habituais dos backups recentes e ao ritmo habitual por hora; para um backup que voltou a guardar a maior parte dos dados, incluindo ficheiros renomeados e reescritos; para o tamanho da origem e o número de ficheiros que o restic indica para cada elemento e cada dump; para o tempo de backup do próprio restic; para sequências de falhas e falhas intermitentes; para verificações de restauro que deixaram de passar; e para o espaço livre dos repositórios locais, SFTP e rclone, projetado a partir do crescimento do repositório. Um elemento aprende com os seus primeiros 10 backups, enquanto uma origem quase vazia, a reescrita da maior parte dos dados e as falhas são verificadas desde o início. Na atualização, o histórico é lido uma vez a partir dos resumos de snapshots que o restic 0.17 guarda, por isso uma instalação existente não começa do zero. A sensibilidade (Rigorosa, Equilibrada, Permissiva) e a gravidade mínima que envia uma notificação definem-se globalmente em Definições, Integridade e podem ser alteradas por elemento. Os avisos fecham-se sozinhos quando a causa desaparece; as deteções críticas de perda de dados e de disco a encher ficam até as confirmar, e uma deteção confirmada só volta a ser comunicada depois de a sua causa ter desaparecido uma vez. Marcar como esperada torna normal um novo nível após 10 backups, mas nunca desliga a verificação de origem quase vazia, e uma seleção alterada faz o histórico do elemento recomeçar por si. Enquanto uma origem estiver quase vazia, tiver encolhido muito ou um backup tiver voltado a guardar a maior parte dos dados, a retenção mantém os backups antigos desse elemento até confirmar a deteção ou a marcar como esperada, e a deteção aponta para o último backup bom. É enviada uma notificação por episódio, e as falhas e verificações de restauro que já notificam não são comunicadas duas vezes. O que não faz: os repositórios S3, B2 e REST não têm valor de espaço livre, na partilha de utilizador do Unraid o espaço livre é o de todo o array, e os backups anteriores ao restic 0.17 não têm histórico de tamanho. Os elementos ZFS também são verificados, conjunto de dados a conjunto de dados: cada conjunto de dados de uma árvore tem o seu próprio histórico, um que foi esvaziado ou já não pôde ser lido conta como perda de dados, e só os backups antigos desse conjunto são mantidos. A forma como um elemento ZFS é vigiado conjunto a conjunto está descrita em Conjuntos de dados ZFS, e um assistente pode ler as anomalias em aberto através do servidor MCP. Uma deteção sobre o tamanho ou o número de ficheiros de uma origem é datada do primeiro backup em que apareceu, e Comparar com o backup anterior lista as pastas onde ficheiros desapareceram, chegaram ou mudaram, com uma nota quando quase tudo está num índice de pesquisa, numa cache ou em miniaturas que a aplicação reconstrói sozinha.
Exclusões recomendadas por aplicação. Para imagens conhecidas (Plex, Jellyfin, Emby, Sonarr, Radarr, Lidarr, Readarr, Prowlarr, Immich, Nextcloud, PhotoPrism e Tautulli, de linuxserver, hotio, binhex ou do editor oficial), o Assistente de exclusão propõe as pastas que a aplicação volta a encher sozinha: caches, registos, imagens de pré-visualização e pósteres. Cada entrada diz o que contém, qualquer uma pode ser desligada e nada é excluído até carregar em Excluir seleção.
Pacote de suporte. Um ZIP expurgado, com um clique, para um relatório de erro: a verificação da integração com o host, a sua configuração sem nenhum segredo, as execuções recentes, o que está agendado a seguir e o registo recente. Inclui também como correu o último dump de cada base de dados, os elementos ZFS com as montagens que o contentor vê, as anomalias em aberto e quantas chaves MCP existem (nunca os seus nomes). Palavras-passe, tokens, a configuração do rclone, as credenciais de notificação e qualquer palavra-passe embutida na localização de um repositório são removidos, e o pacote di-lo no seu próprio manifesto, porque um ficheiro de suporte nunca deve ser confundido com um backup da configuração. Exige uma palavra-passe de início de sessão pela mesma razão que o kit de recuperação. O registo que traz é a saída deste contentor desde o último arranque; para uma falha que reiniciou o contentor, o sítio onde procurar continua a ser docker logs.
Kit de recuperação da chave de encriptação. Transferência com um clique da chave mestra, da palavra-passe restic derivada e das localizações e comandos exatos do repo, para que possa restaurar sem um BombVault em execução. Consulte Externo e recuperação.
Exportar e importar as suas definições. Um cartão Exportar / importar configurações na página Definições, Sistema escreve toda a sua configuração (definições de domínio, destinos externos, agendamentos, retenção, notificações) para um ficheiro JSON portátil, para que mudar para uma máquina nova ou clonar uma configuração não signifique reintroduzir tudo à mão. Escolhe se inclui as credenciais externas e de notificação; com elas, o ficheiro é tão sensível como o seu kit de recuperação. A importação mostra uma pré-visualização e pede confirmação, e nunca toca nos seus dados ou histórico de backup.
Notificações. Webhook (Discord / Slack / Gotify / ntfy), Matrix, Healthchecks.io, e-mail (SMTP), um servidor Apprise API self-hosted, e o sistema de notificações nativo do Unraid. Política por backup: nunca / em caso de falha / sempre. Uma execução agendada de muitos itens pode enviar um resumo N de M com sucesso. O Healthchecks recebe o ciclo de vida completo (/start, depois sucesso ou /fail) sempre que um URL estiver definido.
Resumo semanal. Uma mensagem por semana pelos mesmos canais: número de execuções, quantos dados de backup novos chegaram, se o externo está em dia e as principais falhas. Desligado por predefinição, com cadência própria em Definições, Notificações, para que uma semana sem incidentes também seja comunicada.
/metrics do Prometheus. Por opção (desligado por predefinição, token bearer opcional) para Grafana ou Uptime Kuma. Expõe estado, tamanhos e marcas temporais dos backups, sem segredos ou caminhos nas etiquetas.
API HTTP, Home Assistant e mDNS. Scripts e painéis têm uma API em /api/v1 com tokens com nome, só de leitura ou autorizados a iniciar backups. O Home Assistant encontra o BombVault através da descoberta MQTT, como um dispositivo com sensores e, se o permitir, um botão de backup por domínio. Além disso, o BombVault anuncia-se na rede como bombvault.local. Consulte API e integrações.
Espaço livre e semanas até encher. Os repositórios locais, os repositórios SFTP e os destinos SMB ou WebDAV que o indicam mostram o seu espaço livre e quantas semanas faltam ao ritmo de crescimento atual. Os repositórios S3, B2 e REST indicam "Espaço livre desconhecido", porque esses backends não o comunicam.
Tamanho por pasta. Na secção Backups de um contêiner, de uma VM ou de um conjunto de pastas, Tamanho por pasta mostra que pastas e arquivos ocupam espaço no backup mais recente e quanto disso o último backup trouxe como novo ou alterado, um nível de cada vez. O BombVault lê isso do índice do repositório sem ler os arquivos e, depois de o abrir uma vez, atualiza-o após cada backup.
Porque é que um backup foi lento. Enquanto um backup corre, o BombVault observa quão ocupados estão a CPU, os discos e a rede. Quando um backup demora muito mais do que o normal e uma única coisa estava claramente no limite, a execução di-lo, por exemplo "O disco de destino disk1 esteve ocupado a 98%" ou "O BombVault usou 100% do limite de CPU do seu contêiner". Caso contrário, não diz nada.
Alterado desde o último backup. Um contêiner recriado com outra imagem, outras portas, variáveis ou volumes desde o último backup recebe uma marca ao lado do nome. O seu (i) lista o que mudou, as variáveis só pelo nome. É apenas uma nota e desaparece com o backup seguinte.

Proteção contra ransomware¶

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 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.
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 nunca inverte o veredicto guardado.
Configuração guiada do externo. Um assistente acompanha-o desde a escolha do backend até um snippet de implementação de rest-server pronto a colar, um teste de ligação, o interruptor de imutabilidade e uma estratégia de retenção.
Ensaios de DR (externo). Restaure um alvo real do repo externo para uma sandbox descartável, verifique-o ficheiro a ficheiro e byte a byte, e depois limpe. Consulte Externo e recuperação.
Scorecard de proteção contra ransomware. Um cartão do Painel com uma postura verde / âmbar / vermelha por domínio e uma checklist com marca de idade; cada linha vermelha liga diretamente à correção. Só fica verde com factos verificados.
Alarme de orçamento de crescimento. Para um externo imutável (onde os instantâneos antigos são deliberadamente nunca podados), defina um orçamento de tamanho e seja alertado antes de descontrolar.
Emparelhamento por frase. As instâncias juntam-se a um grupo com doze palavras: cria a frase numa, escreve-a na seguinte. Os membros na mesma rede falam diretamente entre si, os outros através de um retransmissor (o retransmissor do projeto, um próprio, ou nenhum), e cada chamada entre eles é encriptada de ponta a ponta. O grupo transporta os scorecards da página Instâncias, as ofertas do Mesh para off-site e o que um recetor ou uma origem de recolha precisa, nunca dados de backup e nunca a APP_KEY. Consulte Externo e recuperação.
Página Instâncias. Ative Instâncias nas Definições para ter uma página com um cartão para cada instância do seu grupo, incluindo esta: o endereço, se está ligada e o estado de proteção de cada domínio com o seu último backup, no mesmo vermelho, âmbar e verde que o Painel local mostra. Verificar agora pede a um membro que verifique o repositório de um domínio. Nada nesta página consegue iniciar um backup, restaurar ou eliminar o que quer que seja noutra máquina.
Mesh externo. Um membro pode oferecer o seu próprio armazenamento externo a outro membro através do grupo. O administrador do outro lado vê a oferta na página Instâncias e aceita-a ou recusa-a; aceitar cria um conjunto de credenciais e um destino externo normais. Por esta via só passam dados de ligação, nunca dados de backup.
Painel recetor (lado que recebe). Na máquina que recebe cópias externas imutáveis de outro BombVault, ligue o interruptor Recetor (Definições) para revelar um separador Recetor. Registe um repositório recebido só de leitura (aberto com a palavra-passe restic da instância emissora, que chega através do grupo de emparelhamento) para ver o seu inventário de instantâneos agrupado por origem, quando cada origem chegou pela última vez, e correr um restic check independente no hardware recetor. Alerta-o quando uma origem deixa de enviar dentro de uma janela que definir (um interruptor de homem-morto) ou quando uma verificação de integridade falha. Estritamente só de leitura, por isso nunca escreve no repositório recebido, e desligado por predefinição. Consulte Externo e recuperação.
Recolha a partir de outra instância (lado que recolhe). A imagem espelhada da replicação externa: em vez de esta máquina enviar os seus instantâneos para fora, vai buscar os de outra. Ligue o interruptor Recolha (Definições) para revelar o separador Recolha da página Instâncias, escolha a outra instância do seu grupo de emparelhamento e a localização do repositório dela, e depois que tipo de backup contém e com que frequência o recolher. A palavra-passe restic dela chega pelo grupo, nunca a APP_KEY dela. O outro lado não configura mais nada e não precisa de estar a correr. O repositório de origem é apenas lido: é aberto para verificar a palavra-passe, listado e indicado como origem da cópia, e nunca inicializado, desbloqueado, podado nem escrito. Cada lado guarda as suas próprias credenciais, e uma origem rclone: é recusada porque o rclone chegaria a ela com os remotos desta instância. Consulte Externo e recuperação.

Exportações simples¶

Exportação simples de container. Um botão Exportar (tar simples) por container escreve uma cópia navegável e sem ferramentas junto ao repo: <name>.tar.gz das pastas de backup mais o template Unraid <name>.xml. O restic continua a ser o motor; esta é uma cópia de conveniência extra.
Exportação simples de VM. As VMs têm a mesma Exportação (tar simples): <name>.tar.gz da(s) imagem(ns) de disco mais <name>.xml, restaurável com virsh define mais o disco, sem BombVault ou restic necessários.
Encriptar as exportações simples (age). As exportações ficam fora do restic, por isso são texto simples por predefinição. Ative a encriptação age em Definições e adicione um ou mais destinatários (uma chave pública age ou uma chave pública SSH). Cada exportação (o .tar.gz de container e VM, os seus ficheiros .xml associados e o ZIP do flash) fica então selada para esses destinatários, e decifra-a mais tarde fora da máquina com a chave privada correspondente. Como regra de segurança, com a encriptação ligada e sem nenhum destinatário válido definido, uma exportação falha com um erro claro em vez de alguma vez escrever texto simples.
O kit de recuperação também é selado. Com a mesma definição ligada, o kit é transferido como bombvault-recovery-kit.md.age. Está em ASCII armor e não em binário, por isso continua a ser texto legível: pode continuar a colá-lo num gestor de palavras-passe ou imprimi-lo, que é para isso que o kit serve. Aplica-se a mesma regra de segurança: com a encriptação ligada e nenhum destinatário utilizável, a transferência é recusada em vez de entregar a chave mestra em claro. Uma coisa a acertar quando liga isto: precisa da sua chave privada age para abrir o kit, por isso guarde essa chave num sítio que não dependa do próprio kit.

Assistentes de IA (MCP)¶

O BombVault traz um servidor MCP com o qual um assistente como o Claude Code ou o Claude Desktop pode ler o estado das cópias, a cobertura, o histórico de execuções, os pontos de restauro e a atividade em curso. Com uma chave que o permita, o assistente também pode iniciar a cópia de um elemento, de um domínio ou de tudo, e cancelar as cópias que iniciou. Restauros, eliminações, prune e definições ficam na interface web. Cada cliente recebe a sua própria chave em Definições, Integrações, Servidor MCP; uma chave aparece uma única vez, só é guardada como impressão digital e pode ser renomeada, substituída ou revogada a qualquer momento. Os inícios são limitados por hora e por elemento, e uma proteção da retenção impede que as cópias de um assistente façam sair os seus próprios pontos de restauro de uma política "manter os últimos N". Cada execução iniciada por um assistente fica marcada "via MCP" com o nome da chave. Ver Servidor MCP. Os dumps de base de dados e os conjuntos de dados ZFS estão entre os elementos e pontos de restauro que lê, e pode listar as anomalias que o BombVault detetou.

Aplicações e complementos¶

Aplicação Android. Todos os servidores do seu grupo no telemóvel, com o registo de atividade de todos eles num só ecrã. Emparelha-se com o seu grupo por código QR e abre cada servidor já com sessão iniciada. Consulte Aplicação Android.
Servidor recetor. A máquina que recebe as cópias externas pode iniciar com um clique um rest-server append-only e oferecê-lo às outras instâncias do seu grupo, cada uma com um início de sessão próprio. Veja Servidor recetor.
Definições, Aplicações. Uma página que começa com a aplicação Android, o seu APK para a versão que o servidor executa e um código QR para ele, seguida de um cartão para cada complemento. O cartão do ParleyPort oferece o seu template Unraid, copia o comando Docker que o inicia e leva ao seu repositório e às definições do retransmissor em Emparelhamento. O cartão do BombVault Widget oferece o seu template e o seu repositório, e instala ou remove o plugin através da ligação SSH ao host.
BombVault Widget. Um mosaico no Dashboard do Unraid com o registo de atividade do BombVault e a próxima execução agendada. Sem ligação SSH ao host, o cartão dá-lhe o endereço .plg para instalar em Plugins, Install Plugin, e o plugin pode ser removido aí como qualquer outro.
Registo de atividade incorporável. Gere um token só de leitura em Definições, Integrações e obtém um endereço para qualquer painel que mostre um iframe, como Homepage, Organizr ou Heimdall: uma pequena página só com o registo de atividade em tempo real. O token dá acesso a esse registo e a mais nada, e Desativar revoga-o de imediato. A página incorporada só existe em inglês.

Outros¶

Parar um backup em curso. Cada cartão que pode iniciar um backup tem um botão Cancelar cópia junto à barra de progresso enquanto a execução está ativa. A execução fica registada como cancelada, não como falhada. Parar é seguro, porque o restic escreve o snapshot em último lugar, por isso uma execução interrompida deixa dados não referenciados e nenhum snapshot.
Fazer backup de muitos de uma só vez. Selecione vários containers e clique em Fazer backup da seleção. O lote corre no lado do servidor, por isso continua mesmo que feche o separador ou perca a ligação. O BombVault nunca faz backup (e por isso nunca para) do seu próprio container.
Navegador de instantâneos com uma lista de pontos de restauro, eliminação por instantâneo, e uma árvore de pastas recolhível para restauro ao nível do ficheiro.
Manutenção do repositório por domínio: Verificar (restic check), Desbloquear (limpar um bloqueio preso), e Podar (aplica a política de retenção a pedido quando está definida uma, caso contrário uma simples recuperação de espaço).
Progresso da verificação, das verificações de restauro e da limpeza. Enquanto uma delas corre, o registo de atividade e o cartão de integridade mostram até onde o restic contou, por exemplo 12 de 47 packs, com o tempo que falta nesse passo assim que houver dados suficientes para o estimar. Aqui o restic conta packs, snapshots e ficheiros de índice, não bytes, e é isso que a barra mostra; antes da primeira contagem avança sem número.
Dumps automáticos de base de dados. Os containers PostgreSQL, MySQL e MariaDB reconhecidos (as imagens oficiais, PostGIS, TimescaleDB, pgvector, pgautoupgrade, as imagens de base de dados do Immich, linuxserver, yobasystems e jc21 MariaDB, e o mysql-server da Oracle) são despejados antes de cada backup, a partir do servidor em funcionamento. Os containers que apenas se parecem com uma base de dados recebem a mesma opção no seu cartão, desligada até que a escolhas. O dump segue direto para o repositório e torna-se ali um ponto de restauro próprio, ao lado do backup de ficheiros; nunca é escrito num disco. As credenciais vêm das variáveis do próprio container, incluindo os segredos *_FILE, e não saem dele. Cada cartão mostra se a pasta de dados da base é guardada com o container parado, copiada em funcionamento, ou não guardada de todo. Um dump falhado não faz o backup falhar: aparece como uma execução falhada com o seu motivo e uma pista para o resolver, e envia uma notificação. Os dumps nunca são recarregados sozinhos. Descarrega um (simples ou comprimido), guarda-o numa pasta, importa-o com um clique para uma base acabada de arrancar, ou vai buscá-lo com a CLI do restic. Podes desligá-lo por container, com a etiqueta bombvault.dbdump=false, ou para todos os containers nas Definições. A deteção de anomalias também vigia o tamanho de cada dump, e um assistente pode listar os dumps de um contentor através do servidor MCP.
Hooks pré/pós-backup por container. Comandos de shell corridos dentro do container (por exemplo, despejar uma cache para disco); um pré-hook com falha aborta o backup. As bases de dados reconhecidas são despejadas automaticamente e não precisam de hook nenhum.
Parar outros containers durante o backup, com um reinício condicionado à saúde. Nomeie containers dependentes (por exemplo uma base de dados) para parar enquanto este é copiado. Depois o BombVault traz-nos de volta pela ordem depends_on do Compose e, por predefinição, espera que cada um reporte saudável (ou em execução, se não tiver healthcheck) antes de iniciar os containers que dependem dele, para que uma dependência como o Pi-hole, uma base de dados ou um gateway VPN esteja de facto disponível antes dos serviços que precisam dela, em vez de estes voltarem a um connection refused. A espera é limitada por um timeout por container (120 segundos por predefinição) para que um container lento ou nunca-saudável nunca possa travar a execução; tanto a espera como o timeout vivem em Definições, Containers (desligue a espera para o anterior reinício todos-de-uma-vez). O mesmo reinício ordenado e condicionado à saúde envolve também a atualização de imagem pós-backup, por isso, num dia em que chega uma atualização, os dependentes são mantidos em baixo durante a recriação e só são trazidos de volta, condicionados à saúde, quando esta estiver concluída.
Padrões de exclusão por container. Liste subdiretórios a saltar dentro de um volume copiado, um por linha. Escreva os caminhos como os vê dentro do container; uma pré-visualização ao vivo mostra a que cada linha corresponde e avisa quando uma linha não excluiria nada.
Atualizar após um backup bem-sucedido (avançado, desligado por predefinição). Ative isto num container e o BombVault puxa a imagem mais recente e recria-o, mas apenas quando existe de facto uma imagem mais recente, para que exista sempre primeiro um ponto de restauro fresco. Extras opcionais: uma notificação por container atualizado e limpeza de imagens (uma imagem base partilhada por outros containers nunca é eliminada). Depois da atualização, o BombVault também pede ao Unraid para reverificar o estado de atualização desse container, para que o banner obsoleto de update available do separador Docker se limpe a si próprio em vez de ficar por lá (as atualizações do Unraid passam diretamente pela Docker API, por isso o seu estado em cache, e nalgumas versões um digest em cache, continuariam de outro modo a mostrar o banner). É de melhor esforço, nunca afeta o backup, ligado por predefinição e tem um interruptor em Definições.
Restaurar para uma pasta alternativa para clonagem ou inspeção.
Diff de instantâneos e etiquetas. Compare dois instantâneos para ver o que mudou, e etiquete instantâneos para os filtrar.
Novidades após uma atualização. As notas de lançamento aparecem uma vez por nova versão, servidas a partir de notas incorporadas no binário, para que a caixa de diálogo funcione offline.
HTTPS logo de início (autoassinado, ou traga o seu próprio certificado por trás de um proxy reverso).
Healthcheck do Docker. O container reporta saudável/não-saudável a partir do seu próprio /api/health, para que uma ferramenta de auto-recuperação o possa reiniciar se o motor alguma vez encravar.
Interface escura/clara em 42 idiomas com um seletor de bandeiras.
As definições guardam-se sozinhas. Mude um interruptor ou saia de um campo e a alteração é escrita de imediato, com um breve brilho no controlo e um abanão se o servidor a recusar. Três sítios mantêm um botão Guardar, porque guardá-los a meio seria inseguro: a caixa de configuração do rclone, o editor de conjuntos de credenciais e a palavra-passe de início de sessão.
Mensagens pop-up discretas. Em Definições, Geral pode silenciar as confirmações de rotina, para que só as falhas continuem a interrompê-lo. Vale por browser e não mexe nas notificações que o BombVault envia.
À sua maneira. Definições, Aspeto define as cores (uma só cor de destaque, ou o Modo arco-íris com uma paleta de oito), os cantos (arredondados, suaves ou quadrados) e a animação (desativado, subtil, selvagem ou furioso), memorizados por browser. Quando o seu sistema pede menos movimento, é isso que prevalece sempre.