Esta noche, tuve que apagar mi computadora después de algún tipo de pánico en el kernel.
Cuando reinicié, noté mi ~/.ssh/id_rsa había sido reemplazado con un archivo vacío.
Reiniciando a un USB y ejecutando fsck en mi partición de inicio informó que el sistema de archivos estaba en buen estado.
Esto solo no es un problema. Accedo a la clave original. Sin embargo, me preocupa que otros archivos se hayan truncado de manera similar.
Mi última copia de seguridad, usando deja-dup , fue hace tres días, así que podría hacer una reversión completa, pero preferiría preguntar deja-dup qué archivos han cambiado desde entonces y busque archivos "sospechosos".
Este parece ser exactamente el propósito de duplicity verify , así que después de hojear la página del manual, intenté:
duplicity verify --verbosity 4 --no-encryption file:///path/to/backup/ /home/${USER}
que corrió hasta su finalización sin informar cambios. Como mínimo, esperaba mi ~/.ssh/id_rsa para ser detectado, pero agregué, eliminé y modifiqué otros archivos.
Mi siguiente intento fue el mismo, pero con --compare-data bandera:
duplicity verify --verbosity 4 --no-encryption file:///path/to/backup/ /home/${USER}
Lo que parece informar que cada archivo en mi carpeta de inicio es nuevo, comenzando así:
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
He instalado Android Studio durante meses, por lo que seguramente estaba en mi copia de seguridad de hace tres días, y ls informa que Default.xml todavía existe y tiene una longitud de 108 bytes.
Como esfuerzo final, cambié el directorio de destino a / , ya que esa parecía ser la raíz al usar duplicity list-current-files , que requirió agregar algunas expresiones regulares para limitar la duplicidad para considerar solo mi carpeta de inicio:
duplicity verify --verbosity 4 --compare-data --no-encryption --include-regexp ".*home/${USER}/.ssh.*" --exclude-regexp ".*" file:///path/to/backup/ /
Lo que tuvo el efecto interesante de informar que mi carpeta de inicio no 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
En este punto, ciertamente estoy malinterpretando cómo debo usar la duplicidad. ¿Cómo puedo verificar una copia de seguridad generada por deja-dup? ?
duplicity list-current-files tiene una salida que comienza:
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
Respuesta aceptada:
@ede y yo encontramos la misma solución al mismo tiempo, en mi caso en la lista de correo de duplicidad
Relacionado:¿Problema extraño de copia de seguridad y alertas?
la verificación de duplicidad necesita --compare-data bandera para verificar los archivos en el disco, y necesita el --file-to-restore flag para buscar en el directorio adecuado, por lo que el comando final que resolvió mi problema es:
duplicity verify --verbosity 4 --compare-data --file-to-restore=/home/${USER} --no-encryption file:///path/to/backup/ /home/${USER}/
Desafortunadamente, esto todavía no detecta que ~/.ssh/id_rsa fue dañado. Al mismo tiempo, intentar restaurar desde la copia de seguridad restauró un archivo de 0 bytes... Es muy posible que le haya pasado algo a mi archivo hace semanas.