Porque é que um repositório de cópias de segurança deduplicadas fica em modo só de leitura após uma limpeza interrompida?

Um repositório pode ficar apenas para leitura após um prune interrompido, quando um bloqueio exclusivo, um erro de armazenamento, um back-end imutável ou um estado de manutenção incompleto impede alterações.

“Apenas para leitura” pode ser uma resposta de segurança do cliente de cópias de segurança, e não o modo de montagem real do sistema de ficheiros. Um prune cancelado pode deixar um bloqueio exclusivo, operações de pack ou índice inacabadas, espaço de trabalho de limpeza insuficiente ou operações do back-end que permitem leituras, mas rejeitam eliminações. Em separado, o sistema operativo pode voltar a montar o sistema de ficheiros do repositório como apenas para leitura após erros de E/S ou de consistência. Identifique que camada rejeita a primeira escrita antes de remover bloqueios ou voltar a executar o prune.

Registe a primeira operação que indica que está apenas para leitura

Execute um comando para listar o repositório, depois uma verificação não destrutiva, e guarde o primeiro erro proveniente dos registos do cliente, do back-end e do sistema operativo.

A documentação do Restic explica que o prune reescreve os dados do repositório e necessita de acesso exclusivo, pois remove conteúdo não referenciado e pode reorganizar ficheiros parcialmente utilizados.

Se a listagem funcionar, mas todas as operações que criam um bloqueio ou escrevem metadados falharem, distinga entre um bloqueio obsoleto, permissões de escrita no back-end e retenção de objetos.

Verifique se o prune interrompido deixou um bloqueio exclusivo

Liste os bloqueios do repositório através da ferramenta de cópias de segurança e identifique o anfitrião, o processo, a hora de criação e o comando que detém cada bloqueio.

O Borg documenta que os comandos que alteram o repositório utilizam bloqueios do repositório para impedir escritores simultâneos e avisa que quebrar um bloqueio ativo pode danificar o estado do repositório.

Remova um bloqueio obsoleto apenas através do comando suportado e somente depois de provar que o proprietário já não está em execução.

Determine se o sistema de ficheiros foi remontado como apenas para leitura

Verifique a tabela de montagens, o registo do kernel, o estado do sistema de ficheiros, o estado do conjunto de armazenamento e erros recentes de USB, SATA, rede ou do controlador.

A documentação do Linux ext4 indica que errors=remount-ro é uma política de segurança, mostrando como uma falha de armazenamento pode tornar o repositório genuinamente apenas para leitura.

Não force uma remontagem com permissões de leitura e escrita enquanto os erros de hardware ou do sistema de ficheiros continuarem. Preserve os registos e repare primeiro o armazenamento.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Inspecione o estado parcial do prune, compact ou do índice

Determine que fase foi interrompida: seleção de instantâneos expirados, eliminação de referências, reorganização de dados, reconstrução de um índice ou confirmação de metadados.

A referência do Borg para o prune indica que prune e compact são passos separados, pelo que os arquivos podem continuar válidos enquanto a recuperação de espaço permanece incompleta.

Utilize o comando de verificação do repositório antes de executar novamente uma operação destrutiva. Nunca elimine packs, índices ou segmentos manualmente.

Verifique o bloqueio de objetos, a imutabilidade e as credenciais do back-end

Para repositórios na nuvem, inspecione a retenção de objetos, a retenção legal, a política do bucket, o controlo de versões, as permissões de eliminação e a rotação de credenciais.

A AWS afirma que o S3 Object Lock impede a eliminação ou substituição durante um período de retenção protegido, permitindo leituras enquanto o prune falha.

Não enfraqueça a retenção imutável apenas para que o prune seja concluído. Utilize um desenho de repositório suportado pela ferramenta de cópias de segurança.

Verifique o espaço livre, os inodes e o espaço de trabalho do prune

Verifique os bytes e os inodes do sistema de ficheiros, as quotas, as reservas de instantâneos, os diretórios temporários, os limites do armazenamento de objetos e o espaço da cache local.

O GNU Coreutils explica que o df pode apresentar a utilização de blocos e inodes, distinguindo um sistema de ficheiros cheio de uma falha de bloqueio ou de permissões ao nível do repositório.

Se o sistema de ficheiros estiver cheio, adicione capacidade temporária ou remova dados não relacionados e já verificados, em vez de eliminar objetos do repositório.

Recupere com check, unlock e uma única execução de manutenção controlada

Proteja os últimos pontos de restauro conhecidos como bons, pare os agendamentos, execute uma verificação suportada, limpe apenas um bloqueio comprovadamente obsoleto e faça uma única execução de manutenção com registo.

O guia da ZimaSpace sobre recuperar um destino de cópias de segurança cheio fornece a regra adjacente: trate um repositório como uma estrutura gerida, não como ficheiros independentes.

O problema está resolvido quando a listagem, a verificação, a cópia de segurança, a retenção e um restauro de teste forem concluídos com êxito, sem desbloqueios forçados ou eliminações manuais.

Perguntas frequentes

Posso eliminar manualmente o ficheiro de bloqueio?

Não como primeiro passo. Confirme que nenhum processo o detém e utilize a operação de desbloqueio suportada pela ferramenta de cópias de segurança.

Devo executar novamente o prune imediatamente após uma falha?

Não. Verifique o estado do repositório, do índice, do sistema de ficheiros e do back-end antes de outra passagem de manutenção destrutiva.

O comportamento de apenas para leitura significa que os dados da cópia de segurança estão seguros?

Não necessariamente. Packs em falta, erros de armazenamento, objetos imutáveis ou índices incompletos podem continuar a impedir os restauros.