Резервное копирование на внешний диск не выполняется без видимой причины

Поддержка
1

Мы настроили автоматическое резервное копирование, а также переместили /var/discourse/shared/standalone/uploads и /var/discourse/shared/standalone/backups в соответствии с этим руководством на внешний диск. То есть у нас следующая конфигурация app.yml:

volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log
  - volume:
      host: /path/to/external/uploads
      guest: /shared/uploads
  - volume:
      host: /path/to/external/backups
      guest: /shared/backups

Администратор получает сообщение «Резервное копирование не удалось» со следующим логи, доступным в течение одного месяца здесь.

Это сообщение об ошибке появляется без видимой причины, так как резервная копия, похоже, создаётся. Вывод команды ls -la /path/to/external/backups/default/:

total 322618
drwxrwxrwx 2 root root         0 Sep 27  2019 .
drwxrwxrwx 2 root root         0 Jun 27  2019 ..
-rwxrwxrwx 1 root root 327798879 Mai  1 04:21 xxx-yyyy-2021-05-01-020805-v20210420015635.tar.gz

Есть ли у вас какие-либо идеи, что здесь может происходить? Наша версия Discourse — 2.7.0.beta8 (656b0ae39e). Наши настройки резервного копирования следующие:

backup_settings
backup_settings728×731 60 KB

2

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

3

Какую именно директорию вы имеете в виду? Та, которая содержит резервные копии (/path/to/external/backups/default), уже доступна для записи всем пользователям (см. вывод ls -la выше).

4

Оно завершается с ошибкой только через 44 секунды.

gzip создаёт второй файл и удаляет несжатый файл после завершения. Это означает, что у вас должно быть доступно как минимум 327 МБ дискового пространства. Сообщения об ошибках могут быть скрыты из-за того, что это внешний диск. Теория: возможно, у вас заканчивается место на диске?

5

Мы монтируем gocryptfs на SAMBA-раздел, и места должно быть достаточно. Вывод команды df -h:

Filesystem                            Size  Used Avail Use% Mounted on
udev                                  1,9G     0  1,9G   0% /dev
tmpfs                                 385M  1,5M  384M   1% /run
/dev/mapper/hermes--vg-root            36G   21G   14G  60% /
tmpfs                                 1,9G     0  1,9G   0% /dev/shm
tmpfs                                 5,0M     0  5,0M   0% /run/lock
tmpfs                                 1,9G     0  1,9G   0% /sys/fs/cgroup
/dev/sda1                             704M  215M  439M  33% /boot
//xxx.file.core.windows.net/storage2  5,0T  491M  5,0T   1% /mnt/storage2/cipher
/mnt/storage2/cipher                  5,0T  491M  5,0T   1% /mnt/storage2/plain
tmpfs                                 385M     0  385M   0% /run/user/1000
6

Стоит отметить, что ручное резервное копирование прошло успешно после выбора «Да (не включать загрузки)» — лог здесь. Таким образом, сбой действительно может быть связан с объёмом сжимаемых данных.

Затем я снова переместил резервные копии на внутренний диск, и теперь ручное резервное копирование также работает с включёнными загрузками — лог здесь.

Похоже, что проблема специфична для нашей конфигурации gocryptfs / SAMBA. Тем не менее, если у кого-то есть идеи, как исследовать это дальше, я с радостью их выслушаю. Например, что именно заставляет gzip выдавать ошибку «Операция не разрешена».