I’ve been running into issues trying to run a restore on our Staging Discourse instance. Staging is running v2.4.0.beta1 +36. Any idea where the breakdown might be or where to look? Thanks in advance!
Below is the end of the log output:
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] Migrating the database...
[2019-07-16 20:08:16] Reconnecting to the database...
[2019-07-16 20:08:16] Reloading site settings...
[2019-07-16 20:08:16] Disabling outgoing emails for non-staff users...
[2019-07-16 20:08:16] Clearing emoji cache...
[2019-07-16 20:08:16] Disabling readonly mode...
[2019-07-16 20:08:16] Clear theme cache
[2019-07-16 20:08:22] Extracting uploads...
[2019-07-16 20:08:40] Migrating uploads to S3...
[2019-07-16 20:08:46] Restore process was cancelled!
[2019-07-16 20:08:46] Trying to rollback...
[2019-07-16 20:08:46] Rolling back...
[2019-07-16 20:08:47] Cleaning stuff up...
[2019-07-16 20:08:47] Removing tmp '/var/www/discourse/tmp/restores/default/2019-07-16-200516' directory...
[2019-07-16 20:08:48] Unpausing sidekiq...
[2019-07-16 20:08:48] Marking restore as finished...
Below is the output after running discourse restore BACKUP_FILENAME from the command line. Any feedback is appreciated, thanks!
Disabling outgoing emails for non-staff users...
Clearing emoji cache...
Disabling readonly mode...
Clear theme cache
Extracting uploads...
Migrating uploads to S3...
Checking if default already migrated...
524 of 9474 uploads are not migrated to S3. S3 migration failed for db 'default'.
321 posts are not remapped to new S3 upload URL. S3 migration failed for db 'default'.
Looking for missing uploads on: default
Fixing missing uploads:
..........................................................................................................
116 post uploads are missing.
116 uploads are missing.
106 of 116 are old scheme uploads.
98 of 83342 posts are affected.
rake posts:missing_uploads identified 98 issues. S3 migration failed for db 'default'.
No posts require rebaking
Migrating uploads to S3 for 'default'...
Some uploads were not migrated to the new scheme. Please run these commands in the rails console
SiteSetting.migrate_to_new_scheme = true
Jobs::MigrateUploadScheme.new.execute(nil)
Restore process was cancelled!
Trying to rollback...
Rolling back...
Cleaning stuff up...
Removing tmp '/var/www/discourse/tmp/restores/default/2019-07-22-172918' directory...
Unpausing sidekiq...
Marking restore as finished...
Notifying 'system' of the end of the restore...
Finished!
[FAILED]
Restore done.
Estoy bastante seguro de que acabo de verse afectado por esto también; creo que esto debería marcarse como un error.
(Si es diferente, siéntete libre de moverlo a un nuevo tema separado).
Es bastante importante que la restauración de copias de seguridad funcione.
Ten en cuenta que la razón del fallo no es obvia al usar la interfaz de administración y hacer clic en Restaurar junto al nombre de la copia de seguridad; obtienes:
...
Migrando cargas a S3...
¡El proceso de restauración fue cancelado!
...
Completar la restauración mediante la línea de comandos te proporciona más detalles:
discourse enter app
discourse restore example-net-2020-01-02-033557-v20191219112000.tar.gz
...
Reconectando a la base de datos...
Recargando la configuración del sitio...
Deshabilitando correos salientes para usuarios no pertenecientes al personal...
Limpiando la caché de emojis...
Deshabilitando el modo de solo lectura...
Limpiando la caché del tema
Extrayendo cargas...
Reasignando cargas...
Reasignando '//forum-example-net.s3.dualstack.eu-west-2.amazonaws.com/' a '/uploads/default/'
optimized_images=3
uploads=1
Migrando cargas a S3...
Verificando si 'default' ya fue migrado...
6 de 12 cargas no han sido migradas a S3. La migración a S3 falló para la base de datos 'default'.
1 publicación no fue reasignada a la nueva URL de carga de S3. La migración a S3 falló para la base de datos 'default'.
Buscando cargas faltantes en: default
No faltan cargas de publicaciones.
Por favor, proporciona las siguientes variables de entorno
- DISCOURSE_S3_BUCKET
- DISCOURSE_S3_REGION
y bien
- DISCOURSE_S3_ACCESS_KEY_ID
- DISCOURSE_S3_SECRET_ACCESS_KEY
o
- DISCOURSE_S3_USE_IAM_PROFILE
¡El proceso de restauración fue cancelado!
Intentando revertir...
Revertiendo...
Limpiando cosas...
Eliminando la función del esquema discourse_functions
Eliminando el directorio temporal '/var/www/discourse/tmp/restores/default/2020-01-06-222212'...
Reanudando sidekiq...
Marcando la restauración como finalizada...
Notificando a 'system' sobre el final de la restauración...
¡Finalizado!
[FAILED]
Restauración completada.
Agregué un pequeño código de depuración en uploads.rake justo antes de “Por favor, proporciona las siguientes variables de entorno” para volcar las variables de entorno:
puts "ENV: " + ENV.inspect
ENV no contenía ninguna variable DISCOURSE_S3_* configurada.
¿Hay alguna razón significativa por la que esto no esté extrayendo estos datos de la configuración?}
Creo que la idea es que, si tienes archivos subidos en S3, harás una copia de seguridad solo de la base de datos y, por lo tanto, no fallará porque no incluirá las subidas.
Totalmente, pero eso no ayuda cuando la copia de seguridad que tienes es una que incluye las subidas.
Para ser claro: no es críticamente importante para mí en este momento; puedo comentar las líneas problemáticas y completar la restauración, pero otros no pueden.
No es necesario convertir esto en un bug. Está en mi lista de tareas y ya he dedicado una gran cantidad de tiempo a refactorizar el proceso de restauración, agregar muchas pruebas y hacerlo más confiable. Haré algunos ajustes más para reducir la probabilidad de que la restauración en S3 falle y para mostrar más información en la interfaz de administración.
Por lo que sé, la copia de seguridad y restauración ha sido rediseñada, pero acabo de descubrir que esto sigue siendo un problema.
Un intento en beta11 de restaurar una copia de seguridad con enable s3 uploads activado sigue fallando con:
[2020-02-18 09:51:38] Restaurando archivos subidos, esto puede tardar un poco...
[2020-02-18 09:51:38] EXCEPCIÓN: Por favor, proporcione las siguientes variables de entorno:
- DISCOURSE_S3_BUCKET
- DISCOURSE_S3_REGION
y bien
- DISCOURSE_S3_ACCESS_KEY_ID
- DISCOURSE_S3_SECRET_ACCESS_KEY
o
- DISCOURSE_S3_USE_IAM_PROFILE
[2020-02-18 09:51:38] /var/www/discourse/lib/file_store/to_s3_migration.rb:34:in `s3_options_from_env'
Correcto, esto se trata de la migración de cargas.
Las credenciales de acceso a S3 están presentes en la base de datos restaurada, por lo que no es necesario exigir que también estén en una variable de entorno.
Proporcionar las variables de entorno también provoca un error:
Restaurando cargas, esto puede tardar un poco...
Verificando si db8015 ya fue migrada...
200 de 206 cargas no han sido migradas a S3. La migración a S3 falló para la base de datos 'db8015'.
5 publicaciones no fueron remapeadas a la nueva URL de carga de S3. La migración a S3 falló para la base de datos 'db8015'.
Ninguna publicación requiere rebakeado.
Migrando cargas a S3 para 'db8015'...
Subiendo archivos a S3...
- Listando archivos locales
=> 21 archivos
- Listando archivos en S3
. => 16 archivos
- Sincronizando archivos con S3
.....................
Actualizando las URLs en la base de datos...
Eliminando imágenes optimizadas antiguas...
Marcando todas las publicaciones que contienen lightboxes para rebakeado...
5 publicaciones fueron marcadas para un rebakeado
EXCEPCIÓN: 183 de 206 cargas no han sido migradas a S3. La migración a S3 falló para la base de datos 'db8015'.
/var/www/discourse/lib/file_store/to_s3_migration.rb:127:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:74:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:350:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:61:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:203:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:48:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:30:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:58:in `run'
script/discourse:143:in `restore'
No tengo idea de por qué esto está fallando.
La mayoría de las cargas estaban en S3, por lo que los mensajes “200 de 206 cargas no han sido migradas a S3” y “183 de 206 cargas no han sido migradas a S3” son incorrectos. La cantidad de 21 archivos locales es correcta, y hay aproximadamente 200 cargas en S3 (podrían ser 206 también). No reconozco ninguno de los otros números (183, 16).
Tampoco sé por qué el proceso de restauración está intentando mover más cargas a S3. ¿No debería simplemente tomar las imágenes locales de la copia de seguridad y dejar las cargas en S3 sin tocarlas? ¿O estoy pasando por alto algo?
Al final, terminé modificando manualmente la configuración enable_s3_uploads en el volcado de la base de datos para establecerla en false, pero eso provocó que todo fuera remapeado nuevamente a local. Y como había algunas imágenes que aún estaban en local, requirió mucho trabajo determinar cuáles debían ser remapeadas a S3 y cuáles no.
La combinación de cargas locales con cargas almacenadas en S3 no es compatible. Sí, sé que es posible terminar en tal situación cuando alguien cambia de local a S3 y no migra las cargas existentes a S3, pero eso es otra historia…
La restauración de una copia de seguridad siempre incluye el remapeo de cargas si el sistema detecta cambios que afectan las URL de carga. Esto incluye cambiar entre modo independiente y multisitio, cambiar entre cargas locales y S3, así como cambios en la configuración de S3 y CDN. Todas las cargas se restauran en la ubicación correcta según la configuración, ya sea localmente o en S3.
De vez en cuando nos encontramos con copias de seguridad donde el remapeo automático y la migración a S3 fallan por varias razones. Puedes esperar ver más mejoras a principios del ciclo de desarrollo de la versión 2.5.