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.
Tenho quase certeza de que acabei de ser afetado por isso também; acredito que isso deva ser marcado como um bug.
(Se for diferente, sinta-se à vontade para mover para um novo tópico separado)
É meio importante que a restauração de backups funcione.
Note que o motivo da falha não é óbvio ao usar a interface de administração do administrador e clicar em Restaurar ao lado do nome do backup; você recebe:
...
Migrando uploads para o S3...
O processo de restauração foi cancelado!
...
Concluir a restauração via linha de comando fornece mais detalhes:
discourse enter app
discourse restore example-net-2020-01-02-033557-v20191219112000.tar.gz
...
Reconectando ao banco de dados...
Recarregando as configurações do site...
Desativando e-mails de saída para usuários não da equipe...
Limpeza do cache de emojis...
Desativando o modo somente leitura...
Limpeza do cache do tema
Extraindo uploads...
Remapeando uploads...
Remapeando '//forum-example-net.s3.dualstack.eu-west-2.amazonaws.com/' para '/uploads/default/'
optimized_images=3
uploads=1
Migrando uploads para o S3...
Verificando se o padrão já foi migrado...
6 de 12 uploads não foram migrados para o S3. A migração do S3 falhou para o banco de dados 'default'.
1 post não foi remapeado para o novo URL de upload do S3. A migração do S3 falhou para o banco de dados 'default'.
Procurando por uploads ausentes em: default
0 uploads de post estão ausentes.
Por favor, forneça as seguintes variáveis de ambiente
- DISCOURSE_S3_BUCKET
- DISCOURSE_S3_REGION
e qualquer um dos seguintes:
- DISCOURSE_S3_ACCESS_KEY_ID
- DISCOURSE_S3_SECRET_ACCESS_KEY
ou
- DISCOURSE_S3_USE_IAM_PROFILE
O processo de restauração foi cancelado!
Tentando reverter...
Revertendo...
Limpeza de coisas...
Removendo a função do esquema discourse_functions
Removendo o diretório tmp '/var/www/discourse/tmp/restores/default/2020-01-06-222212'...
Retomando o sidekiq...
Marcando a restauração como concluída...
Notificando o 'system' sobre o fim da restauração...
Concluído!
[FALHA]
Restauração concluída.
Adicionei um pouco de código de depuração em uploads.rake logo antes de “Por favor, forneça as seguintes variáveis de ambiente” para exibir as variáveis de ambiente:
puts "ENV: " + ENV.inspect
O ENV não continha nenhuma variável DISCOURSE_S3_* definida.
Há alguma razão significativa para isso não estar puxando esses dados das configurações?
Com certeza, mas isso não ajuda quando o backup que você tem é aquele que inclui os uploads.
Para ficar claro — não é criticamente importante para mim agora, posso comentar as linhas problemáticas e concluir a restauração, mas outros não conseguem.
Não é necessário converter isso em um bug. Está sob minha responsabilidade e já dediquei uma grande quantidade de tempo a refatorar o processo de restauração, adicionando muitos testes e tornando-o mais confiável. Farei alguns ajustes adicionais para tornar a restauração no S3 menos propensa a falhas e para exibir mais informações na interface de administração.
AFAIK, o backup/restauração foi refeito, mas acabei de descobrir que isso ainda é um problema.
Uma tentativa no beta11 de restaurar um backup com enable s3 uploads ativado ainda falha com:
[2020-02-18 09:51:38] Restaurando uploads, isso pode levar algum tempo...
[2020-02-18 09:51:38] EXCEÇÃO: Por favor, forneça as seguintes variáveis de ambiente:
- DISCOURSE_S3_BUCKET
- DISCOURSE_S3_REGION
e também uma das seguintes:
- DISCOURSE_S3_ACCESS_KEY_ID
- DISCOURSE_S3_SECRET_ACCESS_KEY
ou
- 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'
As credenciais de acesso ao S3 estão presentes no banco de dados restaurado, portanto não é necessário exigir que elas também estejam em uma variável de ambiente.
Fornecer as variáveis de ambiente também resulta em falha:
Restaurando uploads, isso pode levar algum tempo...
Verificando se db8015 já foi migrado...
200 de 206 uploads não foram migrados para o S3. Migração para o S3 falhou para o banco de dados 'db8015'.
5 posts não foram remapeados para a nova URL de upload do S3. Migração para o S3 falhou para o banco de dados 'db8015'.
Nenhum post requer rebaking.
Migrando uploads para o S3 para 'db8015'...
Enviando arquivos para o S3...
- Listando arquivos locais
=> 21 arquivos
- Listando arquivos no S3
. => 16 arquivos
- Sincronizando arquivos com o S3
.....................
Atualizando as URLs no banco de dados...
Removendo imagens otimizadas antigas...
Marcando todos os posts contendo lightboxes para rebake...
5 posts foram marcados para rebake
EXCEÇÃO: 183 de 206 uploads não foram migrados para o S3. Migração para o S3 falhou para o banco de dados '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'
Não tenho ideia do motivo dessa falha.
A maioria dos uploads já estava no S3, então as mensagens “200 de 206 uploads não foram migrados para o S3” e “183 de 206 uploads não foram migrados para o S3” estão incorretas. O número de 21 arquivos locais está correto, e há aproximadamente 200 uploads no S3 (poderiam ser 206 também). Não reconheço nenhum dos outros números (183, 16).
Também não faço ideia do motivo pelo qual o processo de restauração está tentando mover mais uploads para o S3. Ele deveria apenas pegar as imagens locais do backup e deixar os uploads no S3 intactos? Ou estou passando por cima de algo?
No final, acabei modificando manualmente a configuração enable_s3_uploads no dump do banco de dados para false, mas isso fez com que tudo fosse remapeado de volta para o local. E como havia algumas imagens ainda locais, foi necessário muito trabalho para descobrir quais precisavam ser remapeadas de volta para o S3 e quais não.
A mistura de uploads locais com uploads armazenados no S3 não é suportada. Sim, eu sei, é possível acabar nesse estado quando alguém muda de local para S3 e não migra os uploads existentes para o S3, mas essa é outra história…
A restauração de um backup sempre inclui o remapeamento de uploads se o sistema detectar qualquer alteração que afete as URLs de upload. Isso inclui a troca entre standalone e multisite, a troca entre uploads locais e S3, bem como alterações nas configurações do S3 e da CDN. Todos os uploads são restaurados no local correto com base nas configurações, seja localmente ou no S3.
De vez em quando, encontramos backups em que o remapeamento automático e a migração para o S3 falham por vários motivos. Você pode esperar ver mais melhorias no início do ciclo de desenvolvimento 2.5.