Sauvegarde sur disque externe échoue sans raison apparente

Soutien
1

Nous avons configuré des sauvegardes automatiques et avons également déplacé /var/discourse/shared/standalone/uploads et /var/discourse/shared/standalone/backups vers un disque externe conformément à ce guide. Notre fichier app.yml est donc configuré comme suit :

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

L’administrateur reçoit le message « Échec de la sauvegarde » accompagné du journal suivant, disponible pendant un mois ici.

Ce message d’erreur apparaît sans raison apparente, car la sauvegarde semble avoir été créée. Voici la sortie de 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

Auriez-vous une idée de ce qui pourrait se passer ici ? Notre version de Discourse est la 2.7.0.beta8 (656b0ae39e). Nos paramètres de sauvegarde sont les suivants :

backup_settings
backup_settings728×731 60 KB

2

Il pourrait s’agir d’un problème d’autorisations. Essayez de rendre le dossier accessible en écriture pour tous.

3

De quel répertoire parlez-vous ? Celui qui contient la sauvegarde (/path/to/external/backups/default) est déjà accessible en écriture par tout le monde (voir la sortie de ls -la ci-dessus).

4

L’échec ne se produit qu’après 44 secondes.

gzip crée un deuxième fichier et supprime le fichier non compressé une fois terminé. Cela signifie que vous devez disposer d’au moins 327 Mo d’espace disque disponible. Les messages d’erreur pourraient être masqués du fait qu’il s’agit d’un disque externe. Théorie : manquez-vous d’espace disque ?

5

Nous montons gocryptfs sur un partage SAMBA, et il devrait y avoir suffisamment d’espace disponible. Sortie de 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

Il est à noter qu’une sauvegarde manuelle a réussi après avoir choisi « Oui (ne pas inclure les téléchargements) » — journal ici. L’échec pourrait donc bien être lié au volume de données compressées.

J’ai ensuite déplacé les sauvegardes vers le disque interne, et désormais les sauvegardes manuelles fonctionnent également avec les téléchargements inclus — journal ici.

Il semble que l’échec soit spécifique à notre configuration gocryptfs / SAMBA. Néanmoins, si quelqu’un a des idées pour investiguer davantage, je suis ravi de les entendre. Par exemple, qu’est-ce qui fait exactement que gzip renvoie Operation not permitted.