Início / unix / Perguntas / 424553
Accepted
Sompom
Asked: 2018-02-17 00:22:53 +0800 CST

Como verificar um backup deja-dup usando duplicidade

  • 772

Esta noite, tive que desligar meu computador após algum tipo de kernel panic.

Quando reiniciei, notei que meu ~/.ssh/id_rsahavia sido substituído por um arquivo vazio.

Reiniciar em um USB e executar fsckem minha partição inicial relatou que o sistema de arquivos estava em boas condições.

Isso por si só não é um problema. Eu acesso a chave original. No entanto, estou preocupado que outros arquivos possam ter sido truncados de forma semelhante.

Meu último backup, usando deja-dup, foi há três dias, então eu poderia fazer uma reversão completa, mas prefiro apenas perguntar deja-dupquais arquivos foram alterados desde então e procurar por arquivos "suspeitos".

Este parece ser exatamente o propósito de duplicity verify, então, depois de algumas páginas do manual, tentei:

duplicity verify --verbosity 4 --no-encryption file:///path/to/backup/ /home/${USER}

que correu até a conclusão sem relatar alterações. No mínimo, esperava que meu ~/.ssh/id_rsafosse detectado, mas adicionei, removi e alterei outros arquivos.

Minha próxima tentativa foi a mesma, mas com a --compare-databandeira:

duplicity verify --verbosity 4 --no-encryption file:///path/to/backup/ /home/${USER}

O que parece relatar que todos os arquivos em minha pasta pessoal são novos, começando assim:

Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Fri Dec 15 11:43:22 2017
Difference found: File . has permissions 1000:1001 700, expected 0:0 555
Difference found: New file .AndroidStudio2.3
Difference found: New file .AndroidStudio2.3/config
Difference found: New file .AndroidStudio2.3/config/inspection
Difference found: New file .AndroidStudio2.3/config/inspection/Default.xml

Eu tenho o Android Studio instalado há meses, então certamente estava no meu backup de três dias atrás, e lsrelatórios que Default.xmlainda existem e têm 108 bytes de comprimento.

Como esforço final, alterei o diretório de destino para /, pois parecia ser a raiz ao usar duplicity list-current-files, o que exigia a adição de algumas expressões regulares para limitar a duplicidade de considerar apenas minha pasta pessoal:

duplicity verify --verbosity 4 --compare-data --no-encryption --include-regexp ".*home/${USER}/\.ssh.*" --exclude-regexp ".*" file:///path/to/backup/ /

O que teve o efeito interessante de relatar que minha pasta pessoal não existe:

Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Fri Dec 15 11:43:22 2017
Difference found: File home is missing
Difference found: File home/${USER} is missing
Difference found: File home/${USER}/.AndroidStudio2.3 is missing
Difference found: File home/${USER}/.AndroidStudio2.3/config is missing
Difference found: File home/${USER}/.AndroidStudio2.3/config/inspection is missing
Difference found: File home/${USER}/.AndroidStudio2.3/config/inspection/Default.xml is missing

Neste ponto, certamente estou apenas entendendo mal como devo usar a duplicidade. Como posso verificar um backup gerado por deja-dup?

duplicity list-current-filestem saída começando:

Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Fri Dec 15 11:43:22 2017
Tue Feb  6 19:36:56 2018 .
Wed Aug  2 17:32:09 2017 home
Tue Feb  6 00:38:20 2018 home/${USER}
Sat May 13 18:49:24 2017 home/${USER}/.AndroidStudio2.3
Thu Jun 22 19:42:14 2017 home/${USER}/.AndroidStudio2.3/config
Sat May 13 18:57:45 2017 home/${USER}/.AndroidStudio2.3/config/inspection
Sat May 13 18:57:45 2017 home/${USER}/.AndroidStudio2.3/config/inspection/Default.xml
fedora duplicity

1 respostas

  1. Best Answer

    @ede e eu encontramos a mesma solução ao mesmo tempo, no meu caso na lista de mala direta duplicidade

    a verificação de duplicidade precisa do --compare-datasinalizador para verificar os arquivos em disco e precisa do --file-to-restoresinalizador para procurar no diretório adequado; portanto, o comando final que resolveu meu problema é:

    duplicity verify --verbosity 4 --compare-data --file-to-restore=/home/${USER} --no-encryption file:///path/to/backup/ /home/${USER}/

    Infelizmente, isso ainda não detecta que ~/.ssh/id_rsafoi danificado. Ao mesmo tempo, tentar restaurar a partir do backup restaurou um arquivo de 0 byte... É bem possível que algo tenha acontecido com meu arquivo semanas atrás.

    • 4

relate perguntas