Ao tentar restaurar um backup (em multisite, mas isso não parece importar, veja abaixo), ocorre o seguinte:
Migrando o banco de dados...
EXCEÇÃO: lib/discourse.rb:57:in `exec': Falha ao migrar o banco de dados.
rake aborted!
Errno::ENOENT: Arquivo ou diretório não encontrado @ rb_sysopen - /var/www/discourse/public/uploads/default/original/2X/7/7be997f9f48c034ddf5d4eb95d2ea7416f010241.svg
/var/www/discourse/app/models/optimized_image.rb:87:in `block in create_for'
/var/www/discourse/app/models/optimized_image.rb:24:in `block (2 levels) in lock'
/var/www/discourse/lib/distributed_mutex.rb:33:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:14:in `synchronize'
/var/www/discourse/app/models/optimized_image.rb:23:in `block in lock'
/var/www/discourse/lib/distributed_mutex.rb:33:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:14:in `synchronize'
/var/www/discourse/app/models/optimized_image.rb:22:in `lock'
/var/www/discourse/app/models/optimized_image.rb:59:in `create_for'
/var/www/discourse/lib/site_icon_manager.rb:28:in `block in ensure_optimized!'
/var/www/discourse/lib/site_icon_manager.rb:24:in `each'
/var/www/discourse/lib/site_icon_manager.rb:24:in `ensure_optimized!'
/var/www/discourse/lib/tasks/db.rake:83:in `block in <top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rake-13.0.1/exe/rake:27:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/ruby_executable_hooks:24:in `eval'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/ruby_executable_hooks:24:in `<main>'
Tasks: TOP => db:migrate
A princípio, achei que fosse apenas um problema de multisite, mas está falhando também em um ambiente não multisite.
O curioso é que nem mesmo os uploads estavam sendo extraídos (EDIT: naquele momento). No entanto, esse upload específico está incluído no arquivo.
tar tvf public/backups/default/redacted-forum-2020-03-02-165725-v20190130013015.tar.gz |grep 7be997f9f48c034ddf5d4eb95d2ea7416f010241
-rw-r--r-- daemon/daemon 3074 2019-05-27 08:21 uploads/default/original/2X/7/7be997f9f48c034ddf5d4eb95d2ea7416f010241.svg
Versão original do dump do banco de dados: v20190130013015
Então extraí os uploads manualmente (para default) e executei a restauração novamente, que teve sucesso.
Foi aí que percebi… os uploads são extraídos APÓS o db:migrate, mas o db:migrate executa SiteIconManager.ensure_optimized!, exigindo que os arquivos já estejam presentes…
Portanto, há dois problemas:
SiteIconManager.ensure_optimized!é executado antes que as imagens tenham sido extraídas; (na verdade, é executado duas vezes — é executado novamente após os uploads terem sido extraídos)- ele espera que os arquivos estejam em
defaultporque o remapeamento ainda não foi executado.
Neste caso específico, a falha é crítica porque o código para um upload de SVG segue um caminho diferente. Para outros uploads, parece falhar silenciosamente.
Aliás, analisando o código, parece que isso poderia ser contornado usando SKIP_POST_DEPLOYMENT_MIGRATIONS=1, já que isso pula a otimização de imagens durante o db:migrate, mas isso não funcionou quando tentei.