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.
Sono quasi sicuro di aver appena incrociato anche io questo problema; credo che debba essere segnalato come un bug.
(Se è diverso, sentiti libero di spostarlo in un nuovo argomento separato)
È piuttosto importante che il ripristino dei backup funzioni.
Nota che la causa del fallimento non è evidente quando si utilizza l’interfaccia di amministrazione e si clicca su Ripristina accanto al nome del backup; si ottiene:
...
Migrazione degli upload verso S3 in corso...
Il processo di ripristino è stato annullato!
...
Completando il ripristino tramite riga di comando si ottengono maggiori dettagli:
discourse enter app
discourse restore example-net-2020-01-02-033557-v20191219112000.tar.gz
...
Riconnessione al database in corso...
Ricaricamento delle impostazioni del sito...
Disabilitazione delle email in uscita per gli utenti non staff...
Pulizia della cache delle emoji...
Disabilitazione della modalità di sola lettura...
Pulizia della cache dei temi
Estrazione degli upload in corso...
Rimappatura degli upload in corso...
Rimappatura di '//forum-example-net.s3.dualstack.eu-west-2.amazonaws.com/' in '/uploads/default/'
optimized_images=3
uploads=1
Migrazione degli upload verso S3 in corso...
Verifica se 'default' è già stato migrato...
6 di 12 upload non sono stati migrati su S3. La migrazione S3 è fallita per il db 'default'.
1 post non sono stati rimappati al nuovo URL di upload S3. La migrazione S3 è fallita per il db 'default'.
Ricerca di upload mancanti su: default
0 upload di post sono mancanti.
Si prega di fornire le seguenti variabili d'ambiente
- DISCOURSE_S3_BUCKET
- DISCOURSE_S3_REGION
e una delle seguenti
- DISCOURSE_S3_ACCESS_KEY_ID
- DISCOURSE_S3_SECRET_ACCESS_KEY
oppure
- DISCOURSE_S3_USE_IAM_PROFILE
Il processo di ripristino è stato annullato!
Tentativo di rollback in corso...
Rollback in corso...
Pulizia dei file temporanei in corso...
Rimozione della funzione dallo schema discourse_functions
Rimozione della directory tmp '/var/www/discourse/tmp/restores/default/2020-01-06-222212'...
Riattivazione di sidekiq in corso...
Segnalazione del completamento del ripristino...
Notifica dell'evento 'system' alla fine del ripristino in corso...
Completato!
[FAILED]
Ripristino terminato.
Ho aggiunto un po’ di codice di debug in uploads.rake subito prima di “Si prega di fornire le seguenti variabili d’ambiente” per stampare le variabili d’ambiente:
puts "ENV: " + ENV.inspect
ENV non conteneva alcuna variabile DISCOURSE_S3_* impostata.
Esiste una ragione valida per cui questi dati non vengono recuperati dalle impostazioni?
Assolutamente, ma questo non aiuta quando il backup che hai include gli upload.
Per essere chiari: al momento non è fondamentale per me, posso commentare le righe problematiche e completare il ripristino, ma gli altri non possono farlo.
Non c’è bisogno di convertirlo in un bug. È già nelle mie priorità e ho già dedicato molto tempo a rifattorizzare il processo di ripristino, aggiungendo numerosi test e rendendolo più affidabile. Farò ancora qualche modifica per rendere il ripristino su S3 meno soggetto a errori e per visualizzare più informazioni nell’interfaccia di amministrazione.
Per quanto ne so, il backup/ripristino è stato ripensato, ma ho appena scoperto che questo è ancora un problema.
Un tentativo su beta11 di ripristinare un backup con enable s3 uploads abilitato fallisce ancora con
[2020-02-18 09:51:38] Ripristino dei caricamenti, ciò potrebbe richiedere del tempo...
[2020-02-18 09:51:38] ECCEZIONE: Fornisci le seguenti variabili d'ambiente:
- DISCOURSE_S3_BUCKET
- DISCOURSE_S3_REGION
e una delle seguenti:
- DISCOURSE_S3_ACCESS_KEY_ID
- DISCOURSE_S3_SECRET_ACCESS_KEY
oppure
- 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'
Corretto, si tratta della migrazione dei caricamenti.
Le credenziali di accesso S3 sono presenti nel database ripristinato, quindi non è necessario richiederle anche come variabili d’ambiente.
La fornitura delle variabili d’ambiente provoca anch’essa un errore:
Ripristino dei caricamenti, potrebbe richiedere del tempo...
Verifica se db8015 è già stato migrato...
200 su 206 caricamenti non sono stati migrati su S3. Migrazione S3 fallita per il db 'db8015'.
5 post non sono stati rimappati al nuovo URL di caricamento S3. Migrazione S3 fallita per il db 'db8015'.
Nessun post richiede una ricottura (rebake).
Migrazione dei caricamenti su S3 per 'db8015'...
Caricamento dei file su S3...
- Elenco dei file locali
=> 21 file
- Elenco dei file S3
. => 16 file
- Sincronizzazione dei file su S3
.....................
Aggiornamento degli URL nel database...
Rimozione delle immagini ottimizzate vecchie...
Segnalazione di tutti i post contenenti lightbox per la ricottura...
5 post sono stati segnalati per una ricottura
ECCEZIONE: 183 su 206 caricamenti non sono stati migrati su S3. Migrazione S3 fallita per il db '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'
Non ho idea del motivo per cui questo stia fallendo.
La maggior parte dei caricamenti era già su S3, quindi “200 su 206 caricamenti non sono stati migrati su S3” e “183 su 206 caricamenti non sono stati migrati su S3” sono errati. Il numero di 21 file locali è corretto, e ci sono circa 200 caricamenti su S3 (potrebbero essere anche 206). Non riconosco nessuno degli altri numeri (183, 16).
Non ho idea del motivo per cui il processo di ripristino stia cercando di spostare altri caricamenti su S3? Dovrebbe semplicemente prendere le immagini locali dal backup e lasciare i caricamenti su S3 così come sono? O sto trascurando qualcosa?
Alla fine ho finito per modificare manualmente l’impostazione enable_s3_uploads nel dump del database impostandola su false, ma questo ha causato la rimappatura di tutto verso l’archiviazione locale. Dato che c’erano ancora alcune immagini locali, è stato necessario molto lavoro per capire quali dovevano essere rimappate su S3 e quali no.
La combinazione di upload locali con quelli archiviati su S3 non è supportata. Sì, lo sappiamo, è possibile ritrovarsi in una situazione del genere quando qualcuno passa da locale a S3 senza migrare gli upload esistenti su S3, ma questa è un’altra storia…
Il ripristino di un backup include sempre la rimappatura degli upload se il sistema rileva modifiche che influenzano gli URL degli upload. Questo include il passaggio da standalone a multisito, il passaggio da upload locali a S3, nonché le modifiche alle impostazioni di S3 e CDN. Tutti gli upload vengono ripristinati nella posizione corretta in base alle impostazioni, sia localmente che su S3.
Di tanto in tanto ci imbattiamo in backup in cui la rimappatura automatica e la migrazione su S3 falliscono per vari motivi. Ci si può aspettare di vedere ulteriori miglioramenti all’inizio del ciclo di sviluppo della versione 2.5.