deja-dup все еще не работает

У меня такая же проблема и я не могу найти решение, как:

deja-dup-backup-tool-error

backup-failed-deja-dup

deja-dup-backup-fails

Установленные версии:

  • Duplicity 0.7.17

  • Python 2.7.17

  • deja-dup 37. 0

Я настроил deja-dup на:

  • ежедневное резервное копирование папки ~/Documents (du -sh 86GB)
  • на резервный сервер, доступный по LAN или OpenVPN
  • с более чем 7TB свободного места
  • используя sftp соединение

Он работал как шарм 4 года без каких-либо изменений. Он перестал работать после обновления apt, скорее всего 6.4.2020 (дд.мм.гггг) - дата последней резервной копии 6.4.2020

Теперь он пытается сделать "чистую резервную копию", но с хорошо известным результатом. Трассировка выглядит довольно схоже, похоже, что не удается выполнить инкрементное (как здесь backup-failed-deja-dup) и даже чистое резервное копирование по той же причине.

Traceback (innermost last):
  File "/usr/bin/duplicity", line 1555, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1541, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1393, in main
    do_backup(action)
  File "/usr/bin/duplicity", line 1414, in do_backup
    sync_archive()
  File "/usr/bin/duplicity", line 1204, in sync_archive
    copy_to_local(fn)
  File "/usr/bin/duplicity", line 1146, in copy_to_local
    fileobj = globals.backend.get_fileobj_read(fn)
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 676, in get_fileobj_read
    self.get(filename, tdp)
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 395, in inner_retry
    % (n, e.__class__.__name__, util.uexc(e)))
  File "/usr/lib/python2.7/dist-packages/duplicity/util.py", line 79, in uexc
    return ufn(unicode(e).encode('utf-8'))
 UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 19: ordinal not in range(128)

Я только что попробовал sudo apt install --reinstall duplicity deja-dup python-minimal

Что я могу попробовать дальше? Есть идеи?

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

0
задан 10 June 2020 в 12:30

1 ответ

Это сработало для меня: перепроверьте и восстановите владельца и права папки резервного копирования.

контекст: Я попытался переместить «старую» папку резервных копий и создать новую для новой резервной копии более месяца назад. Новая резервная копия работает как часы, но сегодня снова появилась точно такая же ошибка! Но сегодня я знаю, что я сделал некоторые изменения на сервере, и там был неправильно настроен владелец папки резервного копирования. Всякий раз, когда я «пережевывал» папку, резервное копирование снова работает.

Я переместил обратно "старую" папку бэкапа, которая не работала и не использовалась около 6 месяцев, и переустановил владельца/права. Резервная копия снова работает, и полная резервная копия создается прямо сейчас.

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

0
ответ дан 27 July 2020 в 06:20

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

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