Il backup su disco esterno fallisce senza motivo apparente

Supporto
1

Abbiamo configurato i backup automatici e abbiamo anche spostato /var/discourse/shared/standalone/uploads e /var/discourse/shared/standalone/backups secondo questa guida su un’unità esterna, ovvero abbiamo la seguente configurazione 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

L’amministratore riceve il messaggio “Backup fallito” con il seguente log, disponibile per un mese qui.

Questo messaggio di errore appare senza una ragione apparente, poiché sembra che il backup venga creato. Output di 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

Avete qualche idea su cosa possa star succedendo? La nostra versione di Discourse è 2.7.0.beta8 (656b0ae39e). Le nostre impostazioni di backup sono le seguenti:

backup_settings
backup_settings728×731 60 KB

2

Potrebbe essere un problema di permessi. Prova a rendere la directory scrivibile da tutti.

3

Quale directory intendi? Quella che contiene i backup (/path/to/external/backups/default) è già scrivibile da tutti (vedi l’output di ls -la sopra).

4

Fallisce solo dopo 44 secondi.

gzip crea un secondo file e rimuove il file non compresso al termine. Ciò significa che è necessario disporre di almeno 327 MB di spazio su disco disponibili. I messaggi di errore potrebbero essere oscurati dal fatto che si tratta di un’unità esterna. Ipotesi: potresti aver esaurito lo spazio su disco?

5

Stiamo montando gocryptfs su una condivisione SAMBA e dovrebbe esserci abbondante spazio disponibile. Output di 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

Va notato che un backup manuale è riuscito dopo aver scelto “Sì (non includere i caricamenti)” — log qui. Quindi il fallimento potrebbe effettivamente essere correlato alla quantità di dati compressi.

Ho quindi spostato nuovamente i backup sul disco interno e ora anche i backup manuali funzionano con i caricamenti inclusi — log qui.

Sembra che il fallimento sia specifico della nostra configurazione gocryptfs / SAMBA. Tuttavia, se qualcuno ha idee per indagare ulteriormente, sarò felice di ascoltarle. Ad esempio, cosa esattamente fa sì che gzip restituisca Operation not permitted.