Questo argomento si è poi evoluto in ‘Ripristina fallimento’ dal 4° post in poi, che è il problema principale ora. Puoi ignorare i primi 4 post.
Ho impostato i miei upload su Aws S3 anni fa/all’inizio.
Anche se (per quanto ne so) non ho mai abilitato l’opzione per includere gli upload S3 nei miei backup, ieri, quando ho scelto di includere ‘Uploads’ nei miei backup, ho ottenuto questo nei miei log:
Ciò solleva alcune curiose discrepanze, che mi lasciano perplesso:
Ieri sera, ho attivato l’opzione nelle mie Impostazioni Amministratore per includere ‘Uploads’ nei miei Backup. E poi, quando ho visualizzato la mia cartella locale ‘Shared Uploads’ tramite WinScp, conteneva meno di 100 file in solo 1 cartella (non esistono altre cartelle 2x, 3x lì, posso condividere SS se necessario). Allora perché i log di backup mostrano circa 3.000 file scaricati. (‘Impossibile scaricare’ è un altro grattacapo/problema in questi log, ma quello è 'altro). Ora, se sta scaricando questi file dallo storage locale, dove esistono così tanti file? E se sta scaricando da S3, allora, a, perché sta scaricando da lì, perché non ho cambiato quell’opzione nella console rails per includere i dati S3 nei backup, né ho creato alcuna opzione simile nella sezione Env del mio file yml.
Poi oggi ho cambiato quell’opzione nella Rails Console in ‘True’. E ora, quando ho eseguito il processo di backup, ha mostrato gli stessi circa 3.200 file scaricati, circa 100 ‘Impossibile scaricare’. Ma quando ho controllato nel mio bucket Aws S3, aveva quasi 10 volte, 32.000 file per circa 3 GB. Allora perché non sta scaricando tutti quei file?
Non c’è un modo per verificare/sincronizzare tutti questi dati e, possibilmente, sapere quali discrepanze si stanno verificando e dove?
Ora sono molto perplesso, cosa dovrei fare. Il mio obiettivo finale è spostare il mio (troppo costoso) storage aws verso una versione più economica (Hetzner stesso, dove è in esecuzione il mio VPS, è molto, molto economico, quindi posso anche aumentare lo storage del mio server primario).
Anche quando la mia cartella ‘Uploads’ (nel bucket Aws S3) supera i 3 GB (3,2k file), perché i backup sono poco meno di 1 GB (con solo 2,9k file scaricati nel backup), anche dopo aver abilitato l’opzione ‘include_s3_uploads_in_backup’ tramite la console Rails?
Questa impostazione scarica i file in una directory temporanea e li include nel backup. Non li inserisce nella directory di caricamento. Per inserirli nella directory di caricamento è necessario ripristinare il backup. Lo farei su un nuovo server in modo che, se qualcosa dovesse andare storto, il tuo server originale rimanga intatto.
Sembra che alcuni file potrebbero mancare. Hai post con immagini mancanti? Un’altra possibilità è che la tabella dei caricamenti includa caricamenti che non sono più referenziati nei post, quindi quelle immagini mancanti non hanno importanza.
Se sono solo circa 100, probabilmente non è un grosso problema.
Oppure potrebbe essere che un bug a un certo punto abbia ripulito (cancellato) file che avrebbero dovuto essere conservati.
Per vedere i file che ha scaricato, dovrai scaricare il file di backup e vedere cosa include. Ripristina il tuo backup su un nuovo server per vedere come funziona.
Ma il punto principale è perché il backup è poco meno di 1 GB (con solo 3100 file) anche quando la cartella ‘Uploads’ di S3 da sola è di 3,2 GB e 32K file. (i log di backup mostrano chiaramente che ha scaricato solo circa il 10%, 3k file).
[Trovo molto complicato creare una nuova configurazione di discourse con un dominio diverso per testare questa cosa, anche se trovo molto facile creare uno snapshot e poi, se necessario, ripristinare il mio sito, molto poco trafficato, entro 5 minuti senza alcun problema]
Beh, pensavo che anche dopo aver cambiato l’opzione in Rails C, perché non aggiungere questa riga anche in yml DISCOURSE_INCLUDE_S3_UPLOADS_IN_BACKUPS: true pensando che forse questo avrebbe richiamato tutti i miei caricamenti da Aws S3.
Ma dopo aver cambiato questa opzione in yml, ricostruito il container, eseguito il backup, ho trovato le stesse righe nei log di backup (3000 download di media con circa 100 fallimenti).
E quando ho provato a ripristinare (non ho ancora cambiato alcuna impostazione di caricamento/S3 nelle mie impostazioni di amministrazione), ha dato errore.
Quindi, ho disabilitato i caricamenti S3 e poi ho provato a ripristinare il mio backup da 1 GB (il backup è ancora su Aws S3), e ha fallito di nuovo. Cosa potrebbe andare storto qui?
Inoltre, dopo il ripristino fallito sono stato disconnesso e quando ho effettuato nuovamente l’accesso, mi è stato mostrato un banner che indicava che tutte le email non di staff erano disabilitate. E quando ho provato ad accedere al log dal link ricevuto via email, quel file non è stato trovato/è inaccessibile (viene visualizzata la mia pagina di errore impostata).
Quando stava cercando di ripristinare, poco prima di essere disconnesso, stavo vedendo questi messaggi di log:
[2024-08-19 04:12:58] 'Bathinda_Helper' has started the restore!
[2024-08-19 04:12:58] Marking restore as running...
[2024-08-19 04:12:58] Making sure /var/www/discourse/tmp/restores/default/2024-08-19-041258 exists...
[2024-08-19 04:12:59] Downloading archive to tmp directory...
Nel successivo tentativo ‘FAILED-restore’, sono riuscito a fare clic sul collegamento del log appena prima di essere disconnesso. Eccolo: log- failed restore.txt (98,9 KB)
Ho fatto alcune sperimentazioni che dimostrano che nuovi caricamenti vengono effettivamente creati sul mio server Ubuntu locale. Ma il ripristino da S3 a locale sta fallendo. La cosa è che alcuni post che ho controllato continuano a mostrare le immagini da S3 (quelle non mancanti).
Per favore, aiutami. Il ripristino sta fallendo ancora e ancora.
Inoltre, dopo “Ripristino fallito”, anche quando accedo con lo stesso amministratore, non riesco ad accedere all’allegato “Log.txt”. Invece, mostra la pagina non disponibile/la pagina di errore della mia configurazione.
In realtà ho provato a fare esattamente la stessa cosa degli screenshot che hai postato poco sopra. Comunque, ora farò solo il ‘Discourse restore’.
Per come ho capito/spero, non ho bisogno di fornire alcun percorso al file di backup (.tz) che si trova ovunque, lo preleverà automaticamente dalla cartella di backup del mio server locale.
