Olá,
Estou tentando me livrar de uma situação complicada.
Algumas semanas atrás, interrompi violentamente um backup borg. O repositório entrou em um estado em que tive que fazer vários reparos de borg para tornar o backup funcional novamente.
Mas, apesar de todo o esforço, não consigo eliminar meus backups antigos. Ao tentar, recebo vários erros como os seguintes:
Remoto: Borg 1.0.10: exceção na chamada RPC:
Remoto: Traceback (última chamada mais recente):
Remoto: Arquivo "borg / remote.py", linha 145, no servidor
Remoto: Arquivo "borg / repository.py", linha 550, em deletar
Remoto: borg.repository.Repository.ObjectNotFound: Objeto com chave b'xfdx8dx96xd0axdfox85xf6xeexc5xb6xb6 & x15x92rtxe2x8b * Ux96D + dx8axa6Jxe5x14x0e 'não encontrado no repositório / cliente / nasvs.
Remoto: Plataforma: Linux FOO.BAR.fr 3.10.0-514.10.2.el7.x86_64 # 1 SMP Sex, 3 de março 00:04:05 UTC 2017 x86_64 x86_64
Remoto: Linux: CentOS Linux 7.3.1611 Core
Remoto: Borg: 1.0.10 Python: CPython 3.5.3
Remoto: PID: 11395 CWD: / srv / nas / CLIENTE
Remoto: sys.argv: ['/usr/bin/borg1.0.10', 'servir', '--restrict-to-path', '/ srv / nas / CUSTOMER /']
Remoto: SSH_ORIGINAL_COMMAND: '/usr/bin/borg1.0.10 serve --umask = 077 --info'
borg check --repair está, na verdade, esvaziando alguns pedaços, mas não consegue tornar meu backup gerenciável
Obrigado pela ajuda,
Atenciosamente
A exceção ObjectNotFound aqui significa que ele tentou excluir uma chave do índice repo - mas a chave não estava no índice. A operação de exclusão provavelmente é chamada do cliente borg porque você está removendo.
Portanto, ou seu repositório está corrompido (== o armazenamento de dados realmente não contém coisas que deveriam estar lá) ou pelo menos os índices estão de alguma forma inconsistentes com o repositório.
O que você pode tentar ( no seu risco - se for importante, faça todos os experimentos em uma CÓPIA do repo ):
borg delete --cache-only repo
Se isso ainda gerar o mesmo erro / semelhante, há uma pequena chance de que o índice do repo esteja corrompido, mas os dados no repo estão corretos. Então você pode tentar:
borg check --repair repo
para reconstruir o índice.BTW, normalmente interromper o borg não deve deixar um repo em um estado tão miserável. Se houver apenas algumas coisas não confirmadas, isso geralmente será revertido automaticamente quando você usar o repo na próxima vez.
Portanto, talvez considere outros motivos, como problemas de hardware - verifique seu sistema de arquivos, seu (s) disco (s) (valores SMART) e sua RAM.
Obrigado pelo feedback rápido, vou tentar isso esta noite.
Pode ser possível que o repo esteja nesse estado por causa de 2 backups borg simultâneos em execução
Thomas,
Segui suas instruções com sucesso. Tive que fazer todo o processo, incluindo "matar" o índice e os arquivos de dicas no repo e, em seguida, reparar.
Consegui, então, podar com sucesso backups mais antigos.
Todo o processo (eliminar o cache local, tentar podar, eliminar dicas remotas e arquivo de índice, reparar, podar --keep-daily20 e depois prune --keep-daily 7) levou cerca de 120 minutos. O tamanho dos dados é de 40 GB, o repo é remoto.
Obrigado pelo feedback rápido e eficaz.
Mantenha o bom trabalho
Talvez a mensagem de erro imprima algo como "Tentando executar verificação de borg"?
Comentários muito úteis
A exceção ObjectNotFound aqui significa que ele tentou excluir uma chave do índice repo - mas a chave não estava no índice. A operação de exclusão provavelmente é chamada do cliente borg porque você está removendo.
Portanto, ou seu repositório está corrompido (== o armazenamento de dados realmente não contém coisas que deveriam estar lá) ou pelo menos os índices estão de alguma forma inconsistentes com o repositório.
O que você pode tentar ( no seu risco - se for importante, faça todos os experimentos em uma CÓPIA do repo ):
borg delete --cache-only repo
Se isso ainda gerar o mesmo erro / semelhante, há uma pequena chance de que o índice do repo esteja corrompido, mas os dados no repo estão corretos. Então você pode tentar:
borg check --repair repo
para reconstruir o índice.Se seu repo for grande e você trabalhar remotamente, isso pode levar muito tempo. Mas depois disso, SE os dados em seu repo ainda estiverem corretos, seu índice de repo será consistente com os dados. Se o reparo falhar / não for bem-sucedido, os dados em seu repo estão corrompidos.