Ошибка резервного копирования Deja-Dup - неверные данные - несоответствие SHA 1 для файла

В моем последнем еженедельном резервном копировании сегодня Дежа-Дуп дал мне маленькую записку о любви:

Ошибка резервного копирования

Неверные данные - несоответствие SHA1 для файла:
duplicity-inc.20130124T230054Z. m работает 12.10 и еженедельно выполняет резервное копирование deja-dup с момента его установки.

Из прочтения других потоков я понимаю, что это известная программная ошибка, которая возникает при прерывании двуличия, но большинство других потоков - это люди, пытающиеся восстановить данные из этих поврежденных резервных копий.

Я попытался удалить и записать соответствующий файл, чтобы повторить попытку, но я получаю сообщение об ошибке, в котором говорится, что файл не найден.

Мой вопрос: что это значит для моих резервных копий в будущем? Работало ли резервное копирование на этой неделе? Будет ли на следующей неделе? Если нет, как я могу устранить эту ошибку?

Я не слишком обеспокоен старыми версиями моих файлов, и даже если они понадобятся мне в будущем, у меня будут сохранены некоторые образы дисков, которые я смогу восстановить от. Так я должен просто удалить все и начать deja-dup с нуля?

Любой совет приветствуется.

3
задан 7 February 2013 в 09:01

1 ответ

У меня недавно была эта проблема. Я не нашел «идеального» решения. Самый безопасный вариант - отменить ошибочную резервную копию и запустить новую, как вы упомянули в своем комментарии.

В других ответах на аналогичные проблемы предлагаются обходные пути для восстановления файлов с использованием предыдущих резервных копий или игнорирования файлов в поврежденном томе, но это явно неоптимально, не говоря уже о том, чтобы достичь его на практике. Однако это не поможет неудачному резервному копированию.

Попытка принудительно выполнить полное резервное копирование файлов в томе, в котором произошел сбой, неэффективна, поскольку следующая инкрементная резервная копия огромна и охватывает все остальные файлы; Вы также можете удалить сбойную резервную копию и начать заново.

Я нашел способ реализовать исправление неисправной части резервной копии. Вот рецепт:

  1. Найдите затронутые файлы, отметив номер тома, а затем проверьте номер тома в файле манифеста.
  2. Коснитесь затронутых файлов (touch -m /name/of/file).
  3. Сделать инкрементное резервное копирование.

Инкрементная резервная копия будет содержать затронутые файл (ы), а также любые другие файлы, которые были изменены в промежуточный период, и об ошибке SHA1 больше не сообщается ... за исключением проверки (см. Ниже).

Я проверил это, используя двуличность напрямую, а не графический интерфейс deja-dup, потому что это позволило мне получить немного больше контроля и выполнять дополнительные действия, такие как проверка резервной копии (duplicity verify /target/directory url:///for/backup/archive). Он не устраняет исходную проблему SHA1, но смягчает ее, предоставляя способ восстановления файлов в предположительно поврежденных резервных томах.

Точно так же, я думаю, что если вы серьезно относитесь к резервным копиям, вам нужно забыть о deja-dup и напрямую использовать двуединство, потому что резервные копии без проверки ничего не стоят. Я обнаружил, что трудный путь, использовав deja-dup в течение почти двух лет, прежде чем неудачное резервное копирование, заставил меня понять, что на самом деле мой график резервного копирования был домом, построенным на песке; когда я проверял используемый внешний диск, около 5% всех файлов резервных копий были нечитаемыми. С тех пор я обнаружил, что использование сценариев оболочки с двуличностью не так сложно, и как только он настроен, это очень легко.

0
ответ дан 7 February 2013 в 09:01

Другие вопросы по тегам:

Похожие вопросы: