Las copias de seguridad siguen tumbando mi foro

[piffy]

Tengo ciclos recurrentes en los que la creación de copias de seguridad inhabilita mi sitio debido a problemas de espacio.

Lo he configurado para usar un volumen de DO separado para almacenar las copias de seguridad y las cargas. El volumen es de 300 GB.

Mi configuración de copias de seguridad:

El problema se ha repetido durante meses. Recibiré mensajes sobre el fallo de la copia de seguridad en la bandeja de entrada de administración (ver abajo).

No queda espacio en el dispositivo

[2024-02-14 03:43:34] Finalizando copia de seguridad...
[2024-02-14 03:43:34] Creando archivo: elite-fourum-2024-02-14-033845-v20240204204532.tar.gz
[2024-02-14 03:43:34] Asegurándose de que el archivo no exista ya...
[2024-02-14 03:43:34] Creando archivo vacío...
[2024-02-14 03:43:34] Archivo de volcado de datos...
[2024-02-14 03:43:58] Archivo de cargas...
[2024-02-14 03:55:03] Eliminando el directorio temporal '/var/www/discourse/tmp/backups/default/2024-02-14-033845'...
[2024-02-14 03:55:03] Comprimiendo archivo, esto puede tardar un tiempo...
[2024-02-14 04:25:38] EXCEPCIÓN: /var/www/discourse/lib/discourse.rb:138:in `exec': Fallo al comprimir el archivo.

gzip: /var/www/discourse/public/backups/default/elite-fourum-2024-02-14-033845-v20240204204532.tar.gz: No queda espacio en el dispositivo

[2024-02-14 04:25:38] /var/www/discourse/lib/discourse.rb:172:in `execute_command'
/var/www/discourse/lib/discourse.rb:138:in `exec'
/var/www/discourse/lib/discourse.rb:34:in `execute_command'
/var/www/discourse/lib/backup_restore/backuper.rb:253:in `create_archive'
/var/www/discourse/lib/backup_restore/backuper.rb:40:in `run'
/var/www/discourse/lib/backup_restore.rb:13:in `backup!'
/var/www/discourse/app/jobs/regular/create_backup.rb:10:in `execute'
/var/www/discourse/app/jobs/base.rb:297:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-5.0.0/lib/rails_multisite/connection_management.rb:82:in `with_connection'
/var/www/discourse/app/jobs/base.rb:284:in `block in perform'
/var/www/discourse/app/jobs/base.rb:280:in `each'
/var/www/discourse/app/jobs/base.rb:280:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:202:in `execute_job'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:170:in `block (2 levels) in process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:177:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:132:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:179:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:182:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:169:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:113:in `local'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq.rb:44:in `block in <module:Sidekiq>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:263:in `stats'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:13:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:80:in `global'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:124:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:39:in `prepare'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:123:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:168:in `process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:78:in `process_one'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:68:in `run'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:8:in `watchdog'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:17:in `block in safe_thread'
[2024-02-14 04:25:38] Eliminando copias de seguridad antiguas...
[2024-02-14 04:25:38] Limpiando cosas...
[2024-02-14 04:25:38] Eliminando restos de '.tar'...
[2024-02-14 04:25:39] Marcando copia de seguridad como finalizada...
[2024-02-14 04:25:39] Notificando a 'system' el fin de la copia de seguridad...

Pero entonces, recibiré una serie de copias de seguridad parcialmente (?) completas de las que, hasta donde sé, no se me notifica. Se acumulan hasta el punto en que se intenta crear una nueva copia de seguridad cada día y al mismo tiempo inhabilita mi sitio.

Tengo que conectarme por SSH manualmente y eliminarlas porque no aparecen en la página /admin/backups.

Sé que es difícil replicar este problema y, por lo tanto, difícil de solucionar, pero me preguntaba si hay algo obvio que estoy haciendo mal o si otros se enfrentan al mismo problema.

[Ed_S]

Lo primero que hay que intentar, después de eliminar las partes que no son archivos de copia de seguridad comprimidos, es reducir el número máximo de copias de seguridad a 2.

Creo que, en cualquier caso, es mejor tener alguna forma de obtener estas copias de seguridad en otro lugar, por ejemplo, en tu casa. Si tuvieras un problema con tu proveedor de alojamiento y te borraran la cuenta, te quedarías sin nada. Igualmente, si tu cuenta fuera comprometida, y quizás también si tuvieran un incendio.

Una vez que tengas alguna forma, quizás manual, quizás automática, de obtener copias externas, estarás muy cerca de tener una forma de comprobar y eliminar fragmentos.

Ya he sugerido antes que el panel de control debería advertir si los archivos de copia de seguridad no se han leído durante varios días desde su creación. Es una comprobación relativamente fácil y, en mi opinión, un buen indicador para comprobar que existe una copia externa.

También puedes optar por poner tus copias de seguridad en almacenamiento de bloques, y podrías hacerlo utilizando un proveedor diferente. Así, tendrías menos probabilidades de perder tanto tu instalación como tus copias de seguridad.

Creo que hay trabajo pendiente desde hace mucho tiempo que no requeriría tener tanto la copia de seguridad como brevemente el archivo de copia de seguridad comprimido, pero no vale la pena esperar a eso. Mientras tanto, necesitas espacio para las N copias de seguridad que conservas, más 1 para la copia de seguridad que se está realizando en formato sin comprimir, más 1 para la copia de seguridad comprimida que necesitas brevemente antes de que se elimine la más antigua de las N.

Necesitas espacio en disco para N+2 copias de seguridad, y si una copia de seguridad falla, necesitas eliminar las partes.

[pfaffman (Jay Pfaffman)]

@piffy

/var/www/discourse/tmp/

Necesitas ver que también pongas ese directorio en tu partición de 300 GB. Esa es la que está llenando el disco.

También podrías considerar mover las cargas a esa partición.

[piffy]

¿Sabes de memoria cómo hacerlo? ¿Hay alguna configuración yml o algo que necesite cambiar?

También lo tengo configurado para tener una pantalla estática sin conexión cuando se reconstruye, así que no sé si eso complica las cosas.

[pfaffman (Jay Pfaffman)]

Algo como

volumes:
  - volume:
      host: /tu/gran/partición/tmp
      guest: /var/www/discourse/tmp

Presumiblemente ya estás haciendo algo como eso para obtener las copias de seguridad en la partición grande?

@piffy

También lo tengo configurado para tener una pantalla estática sin conexión cuando se reconstruye, así que no sé si eso complica las cosas.

Lo hace. Probablemente no sea el problema, a menos que el problema sea que sigue mostrando la página estática sin conexión aunque Discourse esté en funcionamiento.

[piffy]

Descubrí después de crear este tema que necesitas ejecutar un comando en la consola cuando expandes tu volumen de DigitalOcean. Así que, en efecto, no estaba usando los 300 GB completos.

Lo arreglé y no cambié nada más, y el problema se repitió hoy. Había 2 archivos tar descomprimidos y 3 comprimidos con gzip cuando mi sitio dejó de funcionar.

Intentaré la estrategia discutida anteriormente a continuación.

Pero lo que quería decir es que sería bueno tener un indicador en la interfaz de administración de que hay copias de seguridad fallidas. ¿O tal vez eliminar cualquier *.tar al activar un nuevo proceso de copia de seguridad? En este caso, tenía 90 GB de copias de seguridad descomprimidas que no se pueden ver desde la interfaz de administración. Y tampoco recibí ningún DM de “copia de seguridad fallida”.

[gerhard (Gerhard Schlager)]

¿Cómo está el uso de memoria en tu droplet? El proceso de copia de seguridad debería ejecutar rutinas de limpieza y enviar una notificación a los administradores cuando falla. Eso no sucederá si el proceso es terminado por el “out-of-memory killer”.

[pfaffman (Jay Pfaffman)]

@gerhard

Eso no sucederá si el proceso es terminado por el “out-of-memory killer”.

¡Quizás eso es lo que está pasando! He visto este escenario de “copias de seguridad interrumpidas que dejan copias parciales que llenan el disco” en algunos sitios. Mi mejor explicación ha sido un reinicio del sistema operativo en medio de una copia de seguridad, pero lo he visto sin reinicios del sistema operativo.

Que el proceso de copia de seguridad sea terminado por falta de memoria parece una explicación probable que es lo suficientemente difícil de replicar como para explicarlo.

. . . .

Oh. Vaya. Un sitio que recuerdo que tuvo este problema tiene 16 GB de RAM, así que no creo que eso lo explique. En ese sitio, el problema es que cada semana más o menos se deja una copia de seguridad en el disco local después de que se envía (o quizás no se envía) a S3. También tienen más de 100 GB de espacio libre en disco, por lo que tarda meses en convertirse en un problema lo suficientemente grande como para que el disco se llene.

Aquí está el conjunto de archivos que acabo de eliminar:

forum-2024-03-11-123904-v20240202052058.tar.gz
forum-2024-03-09-123159-v20240202052058.tar.gz                           
forum-2024-03-07-123727-v20240202052058.tar.gz                           
forum-2024-03-05-123019-v20240202052058.tar.gz
forum-2024-03-03-123934-v20240202052058.tar.gz  

[Firepup650 (Firepup Sixfifty)]

+1 a eso, el foro que ayudo a administrar tiene copias de seguridad aleatorias en el servidor en lugar de enviarlas a S3, y ha caído el foro al menos una vez.

[piffy]

No estoy seguro si esto es útil, pero aquí están las métricas de DO

7 días

24h

Ampliar