Ошибка резервного копирования Deja-Dup - неверные данные - несоответствие SHA 1 для файла
На моей последней еженедельной резервной копии сегодня, Дежа-Дуп дал мне эту маленькую записку о любви:
Ошибка резервного копирования
Неверные данные - несоответствие SHA1 для файла:
двуличие-inc.20130124T230054Z.to.20130201T225108Z.vol1.difftar.gpgРасчетный хеш: 7726f55012e1e26cc762c9982e7c6c54ca7bb303
Хэш манифеста: 205ecad0a91f8a11967b70d2d3fbc8e4d06231f5
Я использую 12.10 и выполняю еженедельное резервное копирование deja-dup с момента его установки.
Читая другие темы, я понимаю, что это известная программная ошибка, которая возникает при прерывании дублирования, но большинство других потоков - это люди, которые пытаются восстановить данные из этих поврежденных резервных копий.
Я попытался удалить и запустить файл, о котором идет речь, чтобы повторить попытку, но я получаю сообщение об ошибке, в котором говорится, что файл не найден.
Мой вопрос: что это означает для моих резервных копий, идущих вперед? Работало ли резервное копирование на этой неделе? Будет ли на следующей неделе? Если нет, как я могу устранить эту ошибку?
Я не слишком обеспокоен старыми версиями моих файлов, и даже если они понадобятся мне в будущем, у меня сохранятся некоторые образы дисков, которые я смогу восстановить. Так я должен просто удалить все и начать deja-dup с нуля?
Любой совет приветствуется.
1 ответ
У меня недавно была эта проблема. Я не нашел "идеального" решения. Самый безопасный вариант - отменить ошибочную резервную копию и запустить новую, как вы упоминаете в своем комментарии.
Другие ответы на аналогичные проблемы предлагают обходные пути для восстановления файлов с использованием предыдущих резервных копий или игнорирования файлов в поврежденном томе, но это явно неоптимально, а на практике это трудно сказать. Тем не менее, это не поможет сбой резервного копирования.
Попытка принудительно создать полную резервную копию файлов в томе, в котором произошел сбой, неэффективна, поскольку следующая инкрементная резервная копия огромна и охватывает все остальные файлы; Вы также можете удалить сбойную резервную копию и начать заново.
Я нашел способ реализовать исправление неисправной части резервной копии. Вот рецепт:
- Найдите затронутые файлы, отметив номер тома, а затем сравните его с номером тома в файле манифеста.
- Нажмите на затронутые файлы (
touch -m /name/of/file). - Сделать инкрементное резервное копирование.
Инкрементная резервная копия будет содержать затронутые файл (ы), а также любые другие файлы, которые были изменены в промежуточный период, и об ошибке SHA1 больше не сообщается... за исключением проверки (см. Ниже).
Я проверил это напрямую, используя duplicity, а не графический интерфейс deja-dup, потому что он позволил мне получить немного больше контроля и выполнять дополнительные действия, такие как проверка резервной копии (duplicity verify /target/directory url:///for/backup/archive). Он не устраняет исходную проблему SHA1, но смягчает ее, предоставляя способ восстановления файлов в предположительно поврежденных томах резервных копий.
Кроме того, я думаю, что если вы серьезно относитесь к резервным копиям, вам нужно забыть о deja-dup и использовать вместо этого дублирование, потому что резервные копии без проверки ничего не стоят. Я обнаружил, что трудный путь, использовав deja-dup в течение почти двух лет, прежде чем неудачное резервное копирование, заставил меня понять, что на самом деле мой график резервного копирования был домом, построенным на песке; когда я проверял используемый внешний диск, около 5% всех файлов резервных копий были нечитаемыми. С тех пор я обнаружил, что использование сценариев оболочки с дублированием не так сложно, и как только оно будет настроено, это очень просто.