Ir para o conteúdo

Resolução de problemas

Um FAQ curto. Para a tabela completa de resolução de problemas do lado do host do backup de VM por SSH (permissão negada, verificação da chave do host, variáveis de template em falta e mais), consulte o guia de backup de VM por SSH no GitHub.

Alguma coisa não está corretamente ligada

Abra /spike na interface web. A verificação de integração com o host sonda cada montagem e CLI (socket Docker, libvirt, restic, qemu-img, rclone) e reporta quaisquer peças em falta. Comece por aqui antes de assumir um bug: uma montagem em falta ou um host inacessível aparece de imediato.

Não consigo alcançar a interface web

O BombVault serve HTTPS logo de início na porta 3443 (certificado autoassinado), por isso abra https://<your-unraid-ip>:3443. Aceite o aviso do certificado autoassinado, ou coloque o BombVault por trás de um proxy reverso com o seu próprio certificado. Se correr com HTTP_ONLY=true, serve HTTP simples na porta 3000 em vez disso (destinado a uso por trás de um proxy que termina o TLS).

Perdi a minha APP_KEY

A APP_KEY deriva a palavra-passe do repositório restic. Sem ela (e sem o kit de recuperação da chave de encriptação), os backups encriptados não podem ser recuperados. É por isso que o Painel insiste para que transfira o kit de recuperação. Consulte Externo e recuperação. Gere uma chave com openssl rand -hex 32 e guarde-a fora do servidor antes de depender de qualquer backup.

O backup de VM não se liga

O backup de VM comunica com o libvirt por SSH, nunca por uma montagem.

  • Confirme que o SSH está ativado no host e que a chave pública do BombVault está autorizada em /root/.ssh/authorized_keys (Definições, Integrações, SSH do anfitrião mostra a chave e um botão Testar ligação).
  • Numa rede br0.x personalizada, defina LIBVIRT_HOST para o IP LAN do seu Unraid (o container não consegue alcançar o host via host.docker.internal aí). Ative Settings, Docker, Host access to custom networks.
  • Se alterou a porta SSH do Unraid, defina LIBVIRT_SSH_PORT para corresponder.
  • O diagnóstico completo passo a passo (teste de alcance, encaminhamento de VLAN, Permission denied (publickey), Host key verification failed) está no guia de backup de VM por SSH.

Um instantâneo a quente de VM não correu

Os instantâneos a quente precisam do agente convidado qemu instalado na VM e do disco em /mnt/cache (ou /mnt/diskX), não em /mnt/user. Numa VM desligada, o a quente recorre automaticamente ao ordenado. Um backup ordenado desliga a VM, faz backup dos discos, e depois reinicia-a, por isso é sempre consistente.

Um backup falhou com "repository is already locked"

Isto é geralmente um bloqueio restic órfão deixado para trás quando o container foi atualizado ou reiniciado a meio de uma operação. O BombVault deteta um bloqueio comprovadamente órfão, força a sua limpeza e reexperimenta uma vez, automaticamente. Se persistir, use Definições, Integridade, Desbloquear para o domínio afetado para limpar um bloqueio preso à mão. Um problema genuíno continua a vir ao de cima em vez de ser escondido. Depois de um reinício, o BombVault espera até esse bloqueio passar dez minutos sem ser renovado. Um restic ainda em execução, por exemplo num segundo BombVault no mesmo repositório, renova o bloqueio a cada cinco minutos.

A minha cópia externa não aconteceu após um backup

A replicação externa é de melhor esforço por conceção, por isso um percalço externo nunca faz o backup local falhar. Verifique o agendamento externo para esse domínio (Definições, Agendamentos): um agendamento em branco replica após cada backup local, enquanto uma cadência envia com menos frequência. Use Replicar agora na página Externo para uma execução a pedido, e observe o indicador de replicação no Painel.

Um restauro abortou antes de começar

Antes de qualquer coisa ser parada ou removida, o restauro corre uma verificação de conflitos pré-voo: verifica que o IP estático do container e as portas do host publicadas estão livres. Se outro container já detém uma, aborta com uma mensagem clara e acionável em vez de deixar um restauro a meio. Liberte a porta ou o IP em conflito, e depois reexperimente.

Uma exportação simples falhou em vez de escrever um ficheiro

Se a encriptação age estiver ligada (Definições) mas não estiver definido nenhum destinatário válido, uma exportação falha com um erro claro em vez de escrever texto simples. Adicione um destinatário válido (uma chave pública age ou uma chave pública SSH), ou desligue a encriptação se pretender que a exportação seja texto simples. Consulte Funcionalidades.

Um dump de base de dados falhou

Um dump falhado nunca faz falhar o backup à volta dele; fica registado como uma execução falhada própria, e o motivo diz o que corrigir.

  • Entrada recusada. O dump entra com as variáveis de palavra-passe do próprio container (POSTGRES_PASSWORD, MARIADB_ROOT_PASSWORD, MYSQL_ROOT_PASSWORD ou as versões _FILE). Confirma-as no container da base de dados. Uma variável _FILE que aponta para um segredo que o utilizador do container não consegue ler falha da mesma maneira.
  • Privilégios em falta. Com uma palavra-passe de root aleatória, o dump só consegue entrar como utilizador da aplicação, pelo que contém apenas aquela base, e o MySQL 8.4 e mais recentes podem recusá-lo de todo. Dá ao container uma palavra-passe de root a sério, ou desliga-lhe o dump.
  • As tabelas de sistema precisam de atualização. O MariaDB recusa o dump quando as suas tabelas de sistema vêm de uma versão mais antiga (erro 1558). Acrescenta a variável MARIADB_AUTO_UPGRADE=1 e reinicia o container, ou corre mariadb-upgrade lá dentro uma vez.
  • Sem ferramenta de dump. Uma imagem enxuta ou feita à mão sem pg_dump, mysqldump ou mariadb-dump não pode ser despejada. Usa a imagem oficial, ou desliga o dump.
  • Um limite de tempo. Um dump tem DB_DUMP_MAX_HOURS (6 por omissão), o backup à volta tem BACKUP_MAX_HOURS, e um dump que deixa de avançar é cortado ao fim de BACKUP_STALL_HOURS. Este último caso vem quase sempre de um bloqueio que a aplicação mantém. Sobe o limite que disparou, ou faz o dump enquanto a aplicação está sossegada.
  • O container está em pausa ou a reiniciar. O dump fala com o servidor em funcionamento. Se o container reinicia sem parar, o seu próprio registo diz porquê.
  • Um dump danificado não pôde ser removido. Um dump que o BombVault não conseguiu terminar é apagado. Quando esse apagamento falha, o dump fica na lista marcado como danificado e podes eliminá-lo aí.

Uma importação falhou

Uma importação para o container, põe a pasta de dados de lado e deixa a imagem criar uma vazia no lugar. Se falhar um passo antes da importação em si, a pasta antiga volta sozinha ao sítio. Se falhar a importação, o container fica com a pasta nova e a antiga permanece ao lado como <pasta de dados>.bombvault-before-import-<data e hora>; a mensagem de erro da execução indica o caminho exato.

Para a repor à mão: para o container, muda o nome da pasta de dados atual para a tirar do caminho, muda o nome da pasta guardada de volta ao original e arranca o container. No Unraid, o gestor de ficheiros no separador Shares faz isto.

Uma cópia de um conjunto de dados ZFS falhou ou ignorou um conjunto

Cada problema tem um código de motivo entre parênteses retos, e a página Conjuntos de dados ZFS lista-os todos com a solução. Os três mais comuns:

  • snapshot-loop: o instantâneo não chegou ao BombVault porque o Host Data não passa as novas montagens. Edite o container, ponha o Access Mode do Host Data em Read/Write - Slave e reinicie o BombVault.
  • key-not-loaded: um conjunto cifrado cuja chave não está carregada é ignorado. Carregue a chave com zfs load-key e monte o conjunto; a próxima cópia inclui-o.
  • ssh-auth: o servidor recusou a chave do BombVault. O cartão de ligação da página ZFS mostra o comando que a autoriza; execute-o uma vez no servidor.

Um elemento fica em "A aprender N/10"

A maioria das verificações de anomalias começa após 10 backups bem-sucedidos de um elemento, e a contagem recomeça após Marcar como esperada e depois de a seleção do elemento mudar. Um elemento sem agendamento não aprende, e um contentor sem appdata não tem com que aprender, como indica o seu distintivo.

A retenção deixou de apagar os backups antigos de um elemento

Uma anomalia crítica aberta está a segurá-los: a origem do elemento está quase vazia, encolheu muito, ou um backup voltou a guardar a maior parte dos dados. Abra a anomalia a partir do distintivo do elemento. Se faltarem dados ou tiverem sido cifrados, restaure primeiro a partir do último backup bom indicado. Depois confirme a anomalia, ou marque-a como esperada se a alteração foi sua, e a execução seguinte limpa como de costume. A pré-visualização da retenção assinala esse elemento como mantido. Num elemento ZFS só o conjunto de dados indicado na anomalia mantém os backups antigos; os outros conjuntos da árvore são limpos como de costume.

A limpeza manual diz que alguns elementos foram mantidos

A mesma causa: a limpeza deixa em paz os backups antigos de um elemento com uma anomalia destas e indica-o na sua mensagem. Tudo o resto é limpo como de costume.

A importação do histórico diz que um repositório não pôde ser lido

Depois da atualização, o BombVault lê uma vez o tamanho dos backups anteriores de cada repositório. Um repositório que não estava acessível nesse momento, como um destino externo em baixo ou uma partilha não montada, aparece no cartão Anomalias em Definições, Integridade e é tentado de novo uma vez por dia. Entretanto, os seus elementos aprendem com os backups novos.

O aviso de espaço em disco não coincide com o painel do Unraid

Na partilha de utilizador do Unraid (/mnt/user) o espaço livre é o de todo o array, não o de um disco. Os repositórios remotos só são medidos através de remotes rclone que indicam o seu espaço livre; os repositórios S3, B2, REST e SFTP não têm valor e aparecem como não medidos no cartão Anomalias.

Um assistente de IA não consegue ligar-se

A página Servidor MCP explica o que significa cada código de estado e cada recusa do ponto de ligação MCP, e o que fazer.

O container continua a reiniciar ou parece não-saudável

O BombVault reporta saudável/não-saudável a partir do seu próprio /api/health. Uma ferramenta de auto-recuperação (como o Autoheal) pode reiniciá-lo automaticamente se o motor alguma vez encravar. Verifique o registo do container e o relatório /spike para a causa subjacente.

Ainda preso?