Como verificar um backup de deja-dup usando duplicidade

2

Esta noite, tive que desligar meu computador depois de algum tipo de pânico no kernel.

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

A reinicialização para um USB e a execução do fsck em minha partição inicial relataram que o sistema de arquivos estava em boa forma.

Isso sozinho não é um problema. Eu acesso a chave original. No entanto, estou preocupado que outros arquivos possam ter sido truncados da mesma forma.

Meu último backup, usando o deja-dup, foi há três dias, então eu poderia fazer um rollback completo, mas eu preferiria apenas perguntar ao deja-dup quais 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 alguns skins de páginas man, tentei:

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

que foi concluído sem relatar alterações. No mínimo, eu esperava que meu ~ / .ssh / id_rsa fosse detectado, mas eu adicionei, removi e alterei outros arquivos

Minha próxima tentativa foi a mesma, mas com o sinal --compare-data :

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

O que parece indicar que todos os arquivos da 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, por isso foi certamente no meu backup de três dias atrás, e ls informa que o Default.xml ainda existe e tem 108 bytes de comprimento

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

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

que teve o efeito interessante de informar 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, estou certamente entendendo mal como devo usar a duplicidade. Como posso verificar um backup gerado pelo deja-dup?

duplicity list-current-files tem saída iniciada:

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

    
por Sompom 16.02.2018 / 09:22

1 resposta

2

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

A verificação de duplicidade precisa do --compare-data flag para verificar os arquivos em disco, e precisa do --file-to-resore flag para procurar no diretório correto, então o comando final que resolveu o 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_rsa foi danificado. Ao mesmo tempo, tentando restaurar a partir do backup restaurado um arquivo de 0 bytes ... É bem possível que algo aconteceu com o meu arquivo semanas atrás.

    
por 18.02.2018 / 05:21