La copia de seguridad en disco externo falla sin razón aparente

Soporte
1

Hemos configurado copias de seguridad automáticas y también hemos movido /var/discourse/shared/standalone/uploads y /var/discourse/shared/standalone/backups a un disco externo según esta guía, es decir, tenemos la siguiente configuración en 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

El administrador recibe el mensaje “Backup failed” con el siguiente registro, disponible durante un mes aquí.

Este mensaje de error aparece sin una razón aparente, ya que parece que la copia de seguridad se ha creado. Salida 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

¿Tienen alguna idea de qué podría estar ocurriendo aquí? Nuestra versión de Discourse es 2.7.0.beta8 (656b0ae39e). Nuestra configuración de copias de seguridad es la siguiente:

backup_settings
backup_settings728×731 60 KB

2

Podría ser un problema de permisos. Intenta permitir que todos puedan escribir en el directorio.

3

¿A qué directorio te refieres? El que contiene la copia de seguridad (/path/to/external/backups/default) ya tiene permisos de escritura para todos (véase la salida de ls -la anterior).

4

Solo falla después de 44 segundos.

gzip crea un segundo archivo y elimina el archivo sin comprimir al finalizar. Esto significa que necesitas tener al menos 327 MB de espacio en disco disponible. Los mensajes de error podrían verse oscurecidos debido a que se trata de una unidad externa. Teoría: ¿quizás te estás quedando sin espacio en el disco?

5

Estamos montando gocryptfs en un recurso compartido SAMBA y debería haber suficiente espacio disponible. Salida 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

Cabe destacar que una copia de seguridad manual tuvo éxito después de que elegí “Sí (no incluir subidas)” – registro aquí. Por lo tanto, el fallo podría deberse realmente a la cantidad de datos comprimidos.

Luego moví las copias de seguridad nuevamente al disco interno y ahora las copias de seguridad manuales también funcionan con las subidas incluidas – registro aquí.

Parece que el fallo es específico de nuestra configuración de gocryptfs / SAMBA. Aun así, si alguien tiene ideas para investigar esto más a fondo, estaré encantado de escucharlas. Por ejemplo, ¿qué es exactamente lo que hace que gzip diga “Operación no permitida”?