Backups criptografados: seus arquivos são recuperáveis? (2026)

Uma nota sobre financiamento (setembro de 2026): o CypherpunkGuide não veicula publicidade de vigilância — redes de anúncios, pixels de rastreamento ou conteúdo patrocinado. Alguns artigos contêm links de afiliados claramente identificados, pelos quais podemos receber uma comissão. Este artigo não contém links de afiliados nem recomenda um fornecedor de armazenamento.

Fotos, correspondências e documentos podem continuar importantes muito depois de o computador que os criou deixar de funcionar. A criptografia ajuda a manter esses arquivos privados. Para recuperá-los no futuro, você também precisa ter acesso à cópia, conseguir desbloqueá-la, encontrar a versão certa e dispor de um programa capaz de ler o resultado.

Planejei um experimento de restauração com 12 arquivos artificiais e seis casos de teste, usando o restic, um programa de código aberto para backups criptografados. Em um dos casos, a verificação do repositório — a estrutura em que o programa guarda os backups —, a leitura completa dos dados e o comando de restauração terminaram com sucesso. Ainda assim, voltaram apenas 11 dos 12 arquivos que deveriam ter sido preservados. Em outro, os 12 arquivos foram restaurados e passaram nos testes de formato, mas um deles continha uma versão anterior.

A pergunta relevante é concreta: você consegue recuperar os documentos que pretendia guardar, na versão de que precisa, e usá-los? Este guia reúne um plano de backup pessoal, um experimento que pode ser reproduzido e um roteiro seguro para testar a restauração. O experimento usa arquivos gerados para o teste, sem dados de acervos pessoais. Ele não mede a vida útil de discos, a resistência de cópias em locais separados nem a recuperação de um computador inteiro.

Sincronização, backup e preservação têm funções diferentes

#

A sincronização mantém as cópias de trabalho alinhadas; o backup conserva cópias que você pode recuperar; a preservação de longo prazo também mantém os registros compreensíveis e legíveis quando aparelhos e programas mudam. Um serviço pode oferecer várias dessas funções, mas cada uma precisa ser verificada.

Um serviço de sincronização pode propagar uma exclusão e estar funcionando exatamente como previsto. A possibilidade de desfazê-la depende das versões retidas, das regras para arquivos excluídos e do acesso à conta. Já um disco desconectado pode guardar uma cópia valiosa sem conter nada do que foi produzido depois que você o desconectou. Defina a função de que precisa antes de escolher onde guardar os dados.

A CISA, agência de segurança cibernética e de infraestrutura dos Estados Unidos, descreve a regra 3-2-1 como três cópias no total, em dois tipos diferentes de mídia, com uma cópia em outro local. O guia da agência contra ransomware também recomenda backups criptografados e desconectados, além de testes periódicos de integridade e restauração. Guardar em outro local diz respeito à localização; manter desconectado diz respeito à conexão. Uma cópia remota que pode ser apagada pela mesma conta comprometida não se torna independente só por estar em outro prédio. Consulte as orientações de backup da CISA e o guia contra ransomware.

Para um acervo pessoal, liste situações específicas: furto do notebook, exclusão por engano, incêndio em casa, bloqueio de uma conta ou perda de uma forma de desbloqueio. Confira qual cópia continuaria utilizável em cada caso. É a mesma pergunta que orienta um conjunto pessoal de medidas de privacidade: que falha cada medida deve enfrentar?

Mantenha uma forma de recuperação fora do sistema que pode falhar

#

A criptografia protege o conteúdo do backup contra quem não dispõe de um meio válido de desbloqueio. Ela não guarda esse meio para você, não mantém uma conta acessível nem garante a disponibilidade das cópias. O plano de recuperação precisa cuidar de cada uma dessas condições.

Registre onde está o backup, qual programa e formato foram usados, como recuperar a conta, quando isso se aplica, e como uma pessoa autorizada obtém as informações necessárias para desbloqueá-lo. Proteja as credenciais. Não as publique em uma planilha nem as envie a um chatbot. Anotar “as instruções de recuperação estão no envelope lacrado” é diferente de expor o segredo.

No restic, os dados do repositório são criptografados, e o acesso depende de chaves protegidas por senha. Um mesmo repositório pode ter várias dessas chaves. Perder uma senha não implica perda definitiva se outra chave válida e a respectiva senha continuarem disponíveis. Perder todas as formas utilizáveis de desbloqueio é outra situação. A documentação oficial sobre criação de repositórios explica esse funcionamento.

Evite uma dependência circular: a única cópia da senha do backup está dentro do próprio backup, ou as informações de recuperação do gerenciador de senhas estão apenas no notebook que você precisa substituir. Os guias de recuperação de passkeys e migração de gerenciadores de senhas tratam do mesmo problema pelo lado das contas.

A auto-hospedagem muda quem opera o sistema e deixa a recuperação sob a sua responsabilidade. Se um serviço auto-hospedado e seu único backup estão na mesma máquina, perder essa máquina ainda basta para perder os dois.

Saiba o que cada verificação comprova

#

Uma verificação de backup responde à pergunta para a qual foi criada. Conferir a consistência do repositório, ler os dados armazenados, recuperar os arquivos esperados, comparar seus bytes e interpretar os arquivos em seus respectivos formatos são testes distintos. O sucesso em um deles não comprova os demais.

Na documentação consultada em 3 de setembro de 2026, o restic distingue o check comum de check --read-data. A verificação comum examina a estrutura e a consistência do repositório; ela não lê nem verifica todo o conteúdo dos arquivos chamados packs, que contêm os dados do backup. Com --read-data, todos os packs são lidos. Isso pode consumir bastante tempo e tráfego de rede. A diferença está documentada em Working with repositories.

Um manifesto é uma lista dos arquivos esperados, que também pode incluir tamanhos e hashes. Um hash criptográfico, como o SHA-256, é um valor calculado a partir dos bytes de um arquivo para ajudar a detectar alterações. Prepare uma referência com os arquivos que você realmente pretende preservar e mantenha-a protegida. Uma lista criada apenas a partir do backup não revela um arquivo que nunca entrou nele. Os próprios nomes dos arquivos podem ser sensíveis; o manifesto também precisa fazer parte do seu plano de privacidade.

A Biblioteca do Congresso dos Estados Unidos distingue a preservação dos bits da preservação do acesso futuro em seu glossário de coleções digitais. Usei a versão arquivada de setembro de 2025 porque a página atual bloqueou o acesso durante esta revisão. Essa distinção orientou o experimento: a igualdade dos bytes é uma evidência valiosa, mas um arquivo que já tinha um formato inválido pode ser copiado sem nenhuma alteração.

Seis casos de restauração com arquivos artificiais

#

O experimento compara o sucesso dos comandos com o resultado que se pretendia obter. No restic 0.19.1 para Windows, a verificação do repositório, a leitura de todos os dados e a restauração terminaram com sucesso mesmo quando faltava um arquivo previsto ou havia uma revisão antiga. Uma referência independente revelou essas diferenças.

Preparei o conjunto de arquivos antes de aplicar qualquer exclusão. São 12 arquivos em sete grupos de formatos: texto UTF-8, JSON, CSV, XML, ZIP, WAV e TOML. Há anotações artificiais, registros estruturados, um arquivo ZIP e um tom de áudio gerado. A leitura dos formatos é testada por componentes da biblioteca padrão do Python. Não foram testadas as interfaces de um visualizador de fotos, de uma suíte de escritório ou de um reprodutor de áudio.

Cada caso usa um ID de snapshot específico — o identificador de uma versão salva do backup — e uma pasta de restauração nova e vazia. O registro separa a verificação comum, a leitura completa, a restauração, os caminhos esperados, os hashes e a leitura dos formatos. O código de saída 0 indica sucesso do comando; um valor diferente de zero indica um erro naquele comando. Esses códigos não são uma nota de qualidade para o acervo pessoal.

Os seis casos podem ser usados como um exercício reproduzível para conferir um objetivo de recuperação. Em cada caso, diferencie o sucesso de um comando da recuperação dos arquivos necessários, nas versões corretas e em formatos legíveis. A exclusão em S4 e a escolha de uma versão anterior em S5 são intencionais; o restic executa corretamente essas escolhas.

Resultados

#

As contagens de caminhos e hashes usam os 12 arquivos pretendidos como denominador. Já os testes de formato contam apenas os arquivos restaurados que foram efetivamente testados: não há bytes restaurados para interpretar quando um arquivo está ausente. Em S5, os hashes são comparados com a revisão atual necessária, registrada de forma independente, e não com uma lista extraída do snapshot antigo. Em S6, a referência registra a entrada que já era inválida, para manter separadas a preservação dos bytes e a leitura do formato.

Os três comandos do restic terminam com sucesso em S4–S6: o arquivo excluído de propósito não volta, a versão antiga escolhida é restaurada e o JSON que já era inválido é copiado fielmente. A figura usa rótulos em inglês; as quantidades e os denominadores estão na tabela acima.

Baixe a figura em SVG ou PNG; o código de geração também está disponível.

Como interpretar as falhas

#

S2 testa o acesso com uma senha incorreta. O resultado mostra que aquela senha foi recusada. Não demonstra que seria impossível recuperar os dados com outra chave válida. A senha publicada serve apenas como dado artificial de teste e nunca deve proteger um backup real.

S3 altera os dados armazenados sem modificar a estrutura ao redor deles no repositório. A verificação comum terminou com sucesso; a leitura completa e a restauração detectaram o problema. Essa observação vale para a corrupção introduzida no teste. Ela não significa que a verificação comum deixa passar qualquer tipo de dano, nem que um repositório real danificado sempre perde exatamente um arquivo. Mantive os resultados dos comandos separados porque reuni-los sob o rótulo “falha do backup” esconderia a diferença que o teste revelou.

S4 é um erro na seleção dos arquivos. O programa salvou corretamente os arquivos selecionados. A lista do que se pretendia preservar também incluía documents/contacts.csv, que o experimento excluiu de propósito. O programa não tem como deduzir que uma regra de exclusão válida contraria a sua intenção. Revise as regras de seleção e exclusão como parte do backup; a documentação do restic sobre backup descreve essas opções.

S5 é um erro de escolha da versão. O documents/status.json antigo continuava sendo um JSON válido e foi restaurado corretamente. Seu hash, porém, era diferente do hash da revisão atual necessária. Contar arquivos ou conseguir interpretar seus formatos não comprova que estejam atualizados. Um snapshot anterior pode ser exatamente o que você procura após uma exclusão acidental. O problema surge quando ele não corresponde ao objetivo da recuperação.

S6 preserva fielmente uma entrada inválida. O experimento cria um documents/records.json com JSON inválido antes do backup. As três operações do restic têm sucesso, e os 12 hashes restaurados coincidem com as referências de origem. Mesmo assim, o componente que lê JSON rejeita esse arquivo tanto antes quanto depois do backup. O defeito já estava no arquivo original; não foi causado pela restauração. Os outros 11 arquivos passam nos testes de formato.

Como reproduzir o experimento

#

O script do experimento aceita somente o ZIP oficial do restic 0.19.1 para Windows amd64, a versão fixada para este teste. Ele confere os hashes do ZIP e do executável, gera seus próprios arquivos artificiais e repositórios descartáveis e recusa locais de origem ou restauração já existentes. A alteração que danifica dados é intencional e ocorre em uma cópia criada dentro do experimento. O script não aceita o repositório do seu backup real.

Consulte o método e suas limitações, a tabela de resultados, os resultados detalhados, os manifestos dos arquivos artificiais e o registro de comandos com identificadores ocultados. Esses arquivos documentam apenas os dados gerados. No registro de comandos, locais e identificadores específicos do computador foram substituídos; ele não é uma transcrição integral e sem edição do terminal.

Leia o script antes de executá-lo. Use Python 3.11 ou posterior em uma pasta de trabalho vazia e descartável. Baixe o ZIP correspondente na página oficial do restic 0.19.1 e compare seu hash com a lista oficial de hashes dessa versão. Depois, execute:

python restore-lab.py --restic-zip restic_0.19.1_windows_amd64.zip

Para comparar uma nova execução com o registro publicado, salve o script de comparação e os resultados publicados na mesma pasta de trabalho. Mantenha o results.json baixado sem alterações, pois ele será a referência. Depois de executar restore-lab.py conforme as instruções acima, substitua c07-restore-lab-REPLACE-ME pelo nome da pasta de teste exibido pelo programa. Execute o comando a partir da pasta de trabalho:

python .\compare-results.py --results .\c07-restore-lab-REPLACE-ME\results.json

O argumento --results indica o registro gerado pela nova execução. A comparação se limita aos resultados registrados desses seis casos com restic 0.19.1 no Windows. Ela não recalcula os hashes dos arquivos, não avalia a segurança de um backup real nem comprova que outra pessoa tenha repetido o experimento de forma independente. Consulte o método e suas limitações.

A pasta do teste permanece no disco para inspeção. A execução registrada usou Python 3.12.10. O experimento demonstra mecanismos com um conjunto pequeno de arquivos e falhas definidas; não estima taxas de falha nem compara produtos de backup. Permissões, sistemas operacionais inteiros, interrupções de rede, locais independentes, envelhecimento do hardware e comportamento completo de aplicativos ficam fora do escopo.

Teste seu próprio backup sem sobrescrever os originais

#

Restaure em uma pasta nova e vazia e confira o resultado antes de alterar qualquer original. Escolha a versão que atende ao objetivo da recuperação, compare arquivos e conteúdos esperados de forma independente e abra uma seleção representativa nos aplicativos adequados. Uma amostra pequena fornece evidência limitada, sem aprovar o acervo inteiro.

A documentação de restauração do restic avisa que, por padrão, a restauração sobrescreve arquivos existentes. Outros programas têm suas próprias regras. Leia as instruções da versão instalada e confirme o destino antes de começar. Não use a pasta dos seus documentos de trabalho como destino de um teste.

1. Defina o que precisa recuperar. Por exemplo: “as correspondências e fotos até o último backup concluído” ou “a versão anterior à exclusão de ontem”. Anote quais pastas e datas devem estar incluídas. Se os arquivos de origem ainda existem, prepare a lista esperada independentemente da seleção feita pelo backup e associe-a à versão desejada. Um arquivo de trabalho alterado depois do backup será diferente daquele snapshot; a diferença, por si só, não indica dano causado pela restauração.
2. Confirme o acesso e o espaço disponível. Localize o backup e uma forma válida de desbloqueá-lo. Escolha um computador confiável e uma pasta separada e vazia, com espaço livre suficiente. Os arquivos restaurados podem ficar legíveis, sem a criptografia do backup. Proteja o destino e evite sincronização ou compartilhamento não desejados.
3. Escolha uma versão salva específica. Registre seu identificador e a data relevante. “Mais recente” descreve uma regra de ordenação; não comprova que o snapshot contenha as alterações esperadas.
4. Execute as verificações e a restauração conforme a documentação. Diferencie uma verificação rápida da estrutura de uma leitura completa dos dados. Examine avisos e erros, inclusive os da execução que criou o backup. A existência de um snapshot não prova que todos os arquivos de origem foram lidos.
5. Compare o resultado com o objetivo. Confira os caminhos esperados, conteúdos e versões de arquivos representativos e, quando disponíveis, hashes de referência confiáveis. Abra documentos, examine fotos, reproduza gravações e teste as funções dos aplicativos que tornam esses registros úteis. Anote o que foi testado e o que continua sem teste.
6. Mantenha as cópias utilizáveis até verificar o resultado. Um teste bem-sucedido não justifica apagar a única outra cópia que funciona. Após a verificação, proteja ou remova os arquivos do teste conforme a sua política de retenção. Evite uma limpeza destrutiva enquanto investiga uma divergência.

Se o tempo ou o espaço impedirem uma restauração completa, comece por uma seleção limitada e registre esse limite. Amplie a cobertura ao longo do tempo. Caso a origem já tenha desaparecido e não exista uma lista independente, registre que a completude é desconhecida. Contar o que restou no backup não resolve essa dúvida.

Preserve a leitura, além do armazenamento

#

A preservação de longo prazo exige verificações periódicas das mídias, conexões, programas de leitura, formatos e meios de recuperação. Uma estimativa de vida útil para um material de armazenamento não garante que o acervo inteiro continuará recuperável durante esse período.

A orientação da Biblioteca do Congresso sobre registros pessoais recomenda verificar os arquivos salvos pelo menos uma vez por ano e criar cópias em novas mídias a cada cinco anos ou quando necessário. A nota da instituição sobre durabilidade das mídias explica a incerteza dessas estimativas. Use o calendário como orientação de manutenção, sem presumir que um disco sobreviverá até a próxima data. Faça nova verificação também após uma migração, uma mudança no método de desbloqueio ou uma suspeita de falha.

Não escolha um disco com base em uma regra universal como “HD dura X anos” ou “SSD dura Y anos”. Da mesma forma, a afirmação da Verbatim sobre a longevidade do M-DISC se refere a um produto de armazenamento óptico. Ela não garante acesso futuro a uma unidade de leitura compatível, a informações de desbloqueio intactas ou a formatos legíveis. O Arquivo Nacional dos Estados Unidos descreve a incerteza da vida útil e as condições de armazenamento de mídias de vídeo, incluindo discos ópticos. Essas limitações tampouco demonstram que todo disco óptico falhará.

Se um formato ou aplicativo está ficando difícil de usar, produza uma cópia para consulta, documente a conversão e mantenha o original. Converter um documento complexo pode eliminar elementos do layout ou funções. O hash da nova cópia também será diferente, porque a conversão altera os bytes. Confira o que importa naquele registro, identifique a cópia convertida e crie uma nova referência para ela. Não sobrescreva o original só para deixar a pasta organizada.

Comparei os casos registrando a lista pretendida, a versão necessária e os testes de leitura ao lado do resultado de cada comando. Use essas informações separadas para decidir o que corrigir. Um arquivo ausente exige revisar a seleção; uma revisão antiga exige escolher a versão adequada; um original ilegível exige trabalho de preservação. Comprar outro disco, por si só, não resolve essas questões.

Perguntas frequentes

#

Sincronizar arquivos na nuvem conta como backup?

#

O serviço pode oferecer algumas funções de recuperação se conservar versões anteriores e arquivos excluídos por um período adequado. Confira essas regras e os requisitos para recuperar a conta. A sincronização, sozinha, não comprova que você poderá desfazer uma alteração indesejada, recuperar uma exclusão ou superar a perda de acesso à conta.

Se o restic check tem sucesso, todos os arquivos estão seguros?

#

Não. A verificação comum não lê o conteúdo de todos os packs armazenados. Mesmo a leitura completa não comprova que todos os arquivos pretendidos foram incluídos, que você escolheu a versão necessária ou que os aplicativos conseguem ler os arquivos restaurados.

Posso recuperar um backup criptografado se esquecer a senha?

#

Depende da ferramenta e das formas de desbloqueio que ainda estão disponíveis. O restic pode ter várias chaves protegidas por senha. Outra chave válida, acompanhada da respectiva senha, pode continuar funcionando. Não presuma que o provedor de armazenamento consegue descriptografar o backup nem que uma tentativa com senha incorreta prova a perda de todas as formas de recuperação.

Com que frequência devo testar um acervo pessoal?

#

A Biblioteca do Congresso recomenda verificar os arquivos salvos pelo menos uma vez por ano. Adapte a frequência às mudanças nos seus registros importantes e teste após alterações significativas no armazenamento, nos programas ou nos meios de recuperação. Anote se examinou uma amostra ou o conjunto inteiro. Nem uma data no calendário nem uma pequena amostra garantem que os dados continuarão recuperáveis.

Que mídia preserva arquivos por décadas?

#

Nenhuma mídia dispensa cópias independentes, inspeções e migrações. Considere as condições de armazenamento e o acesso a unidades de leitura compatíveis, além da mídia em si. A disponibilidade de longo prazo também depende dos formatos, dos programas e das informações de desbloqueio. Mantenha os originais verificados ao criar novas cópias para consulta.

Fontes e registro de reprodução

#

As fontes primárias foram verificadas em 3 de setembro de 2026. Os resultados do experimento se aplicam ao ambiente informado e às entradas artificiais usadas. As versões arquivadas preservam o histórico das fontes e podem ser anteriores à página atual consultada para uma afirmação.

Cora Aegis

Cora Aegis escreve sobre privacidade e autonomia digital no CypherpunkGuide. Para este guia, planejou e revisou um experimento de restauração de backups criptografados com dados artificiais e comparou os resultados com a documentação oficial do restic e orientações de preservação. Nenhum dado de backup pessoal foi usado.

Mais sobre Cora Aegis ->