В моем последнем еженедельном резервном копировании сегодня Дежа-Дуп дал мне маленькую записку о любви:
Ошибка резервного копирования
Неверные данные - несоответствие SHA1 для файла:
duplicity-inc.20130124T230054Z. m работает 12.10 и еженедельно выполняет резервное копирование deja-dup с момента его установки.
Из прочтения других потоков я понимаю, что это известная программная ошибка, которая возникает при прерывании двуличия, но большинство других потоков - это люди, пытающиеся восстановить данные из этих поврежденных резервных копий.
Я попытался удалить и записать соответствующий файл, чтобы повторить попытку, но я получаю сообщение об ошибке, в котором говорится, что файл не найден.
Мой вопрос: что это значит для моих резервных копий в будущем? Работало ли резервное копирование на этой неделе? Будет ли на следующей неделе? Если нет, как я могу устранить эту ошибку?
Я не слишком обеспокоен старыми версиями моих файлов, и даже если они понадобятся мне в будущем, у меня будут сохранены некоторые образы дисков, которые я смогу восстановить от. Так я должен просто удалить все и начать deja-dup с нуля?
Любой совет приветствуется.
У меня недавно была эта проблема. Я не нашел «идеального» решения. Самый безопасный вариант - отменить ошибочную резервную копию и запустить новую, как вы упомянули в своем комментарии.
В других ответах на аналогичные проблемы предлагаются обходные пути для восстановления файлов с использованием предыдущих резервных копий или игнорирования файлов в поврежденном томе, но это явно неоптимально, не говоря уже о том, чтобы достичь его на практике. Однако это не поможет неудачному резервному копированию.
Попытка принудительно выполнить полное резервное копирование файлов в томе, в котором произошел сбой, неэффективна, поскольку следующая инкрементная резервная копия огромна и охватывает все остальные файлы; Вы также можете удалить сбойную резервную копию и начать заново.
Я нашел способ реализовать исправление неисправной части резервной копии. Вот рецепт:
touch -m /name/of/file
). Инкрементная резервная копия будет содержать затронутые файл (ы), а также любые другие файлы, которые были изменены в промежуточный период, и об ошибке SHA1 больше не сообщается ... за исключением проверки (см. Ниже).
Я проверил это, используя двуличность напрямую, а не графический интерфейс deja-dup, потому что это позволило мне получить немного больше контроля и выполнять дополнительные действия, такие как проверка резервной копии (duplicity verify /target/directory url:///for/backup/archive
). Он не устраняет исходную проблему SHA1, но смягчает ее, предоставляя способ восстановления файлов в предположительно поврежденных резервных томах.
Точно так же, я думаю, что если вы серьезно относитесь к резервным копиям, вам нужно забыть о deja-dup и напрямую использовать двуединство, потому что резервные копии без проверки ничего не стоят. Я обнаружил, что трудный путь, использовав deja-dup в течение почти двух лет, прежде чем неудачное резервное копирование, заставил меня понять, что на самом деле мой график резервного копирования был домом, построенным на песке; когда я проверял используемый внешний диск, около 5% всех файлов резервных копий были нечитаемыми. С тех пор я обнаружил, что использование сценариев оболочки с двуличностью не так сложно, и как только он настроен, это очень легко.