Backup em disco externo falha sem motivo aparente

Suporte
1

Configuramos backups automáticos e também movemos /var/discourse/shared/standalone/uploads e /var/discourse/shared/standalone/backups para uma unidade externa, conforme este guia, ou seja, temos a seguinte configuração 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

O administrador recebe a mensagem “Backup falhou” com o seguinte log, disponível por um mês aqui.

Essa mensagem de erro aparece sem motivo aparente, pois o backup parece ter sido criado. Saída 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

Vocês têm alguma ideia do que possa estar acontecendo? Nossa versão do Discourse é 2.7.0.beta8 (656b0ae39e). Nossas configurações de backup são as seguintes:

backup_settings
backup_settings728×731 60 KB

2

Pode ser um problema de permissão. Tente permitir que todos possam escrever no diretório.

3

A qual diretório você se refere? Aquele que contém o backup (/path/to/external/backups/default) já tem permissão de escrita para todos (veja a saída do ls -la acima).

4

Falha apenas após 44 segundos.

O gzip cria um segundo arquivo e remove o arquivo descomprimido ao concluir. Isso significa que você precisa ter pelo menos 327 MB de espaço em disco disponível. Mensagens de erro podem estar ocultas devido ao fato de ser uma unidade externa. Teoria: você pode estar ficando sem espaço em disco?

5

Estamos montando gocryptfs em uma share SAMBA, e deveria haver bastante espaço disponível. Saída do 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

Vale ressaltar que um backup manual teve sucesso após eu escolher “Sim (não incluir uploads)” — log aqui. Portanto, a falha pode realmente estar relacionada à quantidade de dados comprimidos.

Em seguida, movi os backups de volta para a unidade interna e, agora, os backups manuais também funcionam com uploads incluídos — log aqui.

Parece que a falha é específica da nossa configuração do gocryptfs / SAMBA. Ainda assim, se alguém tiver ideias para investigar isso mais a fundo, ficarei feliz em ouvir. Por exemplo, o que exatamente faz o gzip retornar Operation not permitted.