Ciao a tutti - sto cercando di migrare da Discourse ospitato a self-hosting. Ho fatto un sacco di test di successo su varie cose, ma quando provo a fare la cosa reale, inclusi tutti gli upload, dopo un paio d’ore di estrazione dell’archivio, dice che nessun file o directory esiste quando si tenta di estrarre il file di dump. Quindi ora affronto la prospettiva di perdere circa 140 GB di upload, a meno che qualcuno non abbia qualche idea?
Puoi fornire il log?
Stai ripristinando dalla riga di comando o dall’interfaccia web? Consiglio l’interfaccia web.
Ciao, ho allegato il log all’email precedente, anche se lo allego di nuovo qui. Ho provato prima usando l’interfaccia web e poi la seconda volta tramite la riga di comando. Ho il sospetto che il backup possa essere corrotto in qualche modo, poiché non viene riconosciuto quando viene caricato su S3 e viene rifiutato quasi istantaneamente se provo a caricarlo tramite il browser.
restore-failure-log.txt (3,28 KB)
Sembra proprio così. Hai caricato tramite browser web o con scp/rsync? Ti consiglierei di caricare di nuovo con rsync.
Ciao Jay, scusa se prima mi sono confuso, abbiamo anche avuto discussioni con Discourse via email durante questo processo di migrazione, ed è lì che ho allegato il file di log.
Guardando l’errore, sospetto che il tarball non contenga effettivamente uno sql dump, ma solo immagini. Il file è stato avviato e controllato da Discourse per nostro conto. L’ho scaricato tramite http e caricato sul server tramite scp, poiché l’upload tramite browser lo ha rifiutato.
Sì, ho appena eseguito un comando per ispezionare il contenuto del tarball e contiene solo immagini, nessun sql dump.
Puoi verificare se le dimensioni del tarball sono esattamente le stesse?
- sull’istanza CDCK
- quello scaricato
- quello caricato tramite scp
Potresti voler usare tar tfvz per verificare se l’archivio non è troncato.
Potresti voler verificare se non stai esaurendo lo spazio su disco da qualche parte, poiché sono necessarie più volte le dimensioni dell’archivio.
Ok, sono uscito per un po’ ma controllerò più tardi. Lo spazio non dovrebbe essere un problema in quanto ho 512 GB e il file di backup è di 70 GB. Sono rimasto sorpreso che il file fosse di qualche GB più piccolo dell’ultimo che abbiamo creato, mi aspettavo che fosse leggermente più grande. Sono abbastanza sicuro che per qualche motivo non abbia incluso il dump SQL, che corrisponderebbe alla differenza di dimensioni.
Ciao @pfaffman @RGJ solo un aggiornamento su come è progredito questo. Il dump SQL mancava effettivamente dall’archivio scaricato e non ero sicuro se eseguire un backup separato del database e inserirlo nell’archivio avrebbe funzionato (e avrebbe richiesto diverse ore per testarlo). Quindi abbiamo finito per ripristinare il database e migrare (con successo).
Il problema ora è che non appena Discourse dismetterà tutto e spegnerà il bucket S3 / CDN, tutte le nostre immagini storiche si romperanno.
Ho tutte le immagini e penso di poterle caricare tutte sul nostro bucket S3 mantenendo la stessa struttura di cartelle. Ho visto alcuni thread che discutono della possibilità di utilizzare discourse.remap / dbhelper.remap per aggiornare in blocco i collegamenti a livello di database. Qualsiasi pensiero al riguardo molto apprezzato!
Non riesco a immaginare come sia potuto succedere. Il tuo browser ha in qualche modo decompresso e spacchettato il backup e tu hai cercato di rimettere tutto insieme?
Puoi chiedere alla gente di discourse.org di darti un backup che includa i caricamenti. È quello che vuoi fare. Attivano un include_s3_uploads_in_backup (è vicino, ma quasi certamente non il nome dell’impostazione nascosta).
Puoi anche escogitare l’uso di strumenti S3 per scaricarli tutti dal loro bucket e ricaricarli. Ci sono un paio di argomenti a riguardo. Non lo consiglio.
Recentemente ho migrato un backup di circa 100 GB da CDCK a Digital Ocean, droplet, bucket spaces e CDN bunny.net per $ 1000. Mi dispiaceva.
È solo il database?
Oh, hai in qualche modo eseguito un ripristino solo del database anche se hai le immagini nel file tar?
Devi eseguire il ripristino del file esatto che hanno creato e far sì che Discourse lo ripristini. Quello che ha il database e i caricamenti. Oppure puoi guardare il codice di ripristino ed escogitare di fare a mano le cose che fa per rimappare le immagini nella nuova posizione. Sebbene pensi che Richard abbia le competenze e gli strumenti per farlo, non penso che tu voglia farlo in quel modo.
Abbiamo fatto un test un paio di mesi fa e tutto è andato bene. Penso che abbiano lasciato attiva quell’impostazione nascosta, poiché questa volta sono stato in grado di attivare un backup, inclusi i caricamenti dal backend, anche se dopo circa 12 ore abbiamo ricevuto una notifica che era fallito. Ho quindi contattato Discourse e mi hanno detto che avrebbero creato il backup dalla loro parte. Un paio d’ore dopo, il backup che avevo avviato sembrava essere completato, anche se abbiamo scartato il file come consigliato da Discourse. Hanno poi riscontrato una serie di problemi con i backup che andavano in timeout e restituivano errori, prima di comunicarci infine che c’era un file completo. Ma quando ho provato a ripristinare il file, dopo diverse ore per estrarre l’archivio, si è lamentato che il dump era mancante. Ispezionando il file usando tar -tf ho confermato che non c’era nessun dump al suo interno (guardando altri backup completi, di solito è il primo file nell’archivio). Dato che era domenica non ho potuto mettermi in contatto con Discourse, e avevamo promesso di completare la migrazione entro lunedì mattina, quindi ho effettuato solo un backup del database (circa 7 GB) e l’ho usato per migrare.
Discourse sta cercando di aiutare, ma c’è solo così tanto che possono fare ora, poiché abbiamo completato la migrazione e siamo nel nostro ambiente self-hosted da domenica pomeriggio. La soluzione più semplice sarebbe che mantenessero attivi il nostro bucket S3 e CDN (a pagamento), ma hanno detto che non è possibile. Penso che dovremo semplicemente perdere le immagini storiche, onestamente.
Questo è risolvibile. Basta scaricare il contenuto del bucket S3 nella directory di caricamento locale ed eseguire un remap sul database, riscrivendo gli URL del CDN e del bucket all’URL della tua istanza.
1 Mi Piace
Un paio di problemi: la dimensione delle immagini caricate saturerebbe l’SSD del nostro nuovo VPS e non abbiamo la possibilità di collegare un disco aggiuntivo. Forse potremmo semplicemente prenderne un sottoinsieme, anche se non sono sicuro di come funzionerebbe guardando la struttura delle directory. Inoltre, abbiamo già configurato il sito per utilizzare S3 per i caricamenti invece dello storage locale.
Ok, quindi copiare il loro S3 (o il backup da S3) nel tuo S3 e rimappare?
1 Mi Piace
Sì, spero sia possibile!
1 Mi Piace
Ah. Capisco. Sì, una volta che sei andato in diretta sei impegnato. È ancora del tutto possibile spostare i file su S3 prima che vengano eliminati.
Hai sempre avuto bisogno di spazio sufficiente per contenere tutte le immagini per eseguire il ripristino. Potresti copiare le immagini una alla volta. Ci sono anche strumenti che copiano i file direttamente, credo.
Il piano originale prevedeva l’utilizzo di una VM Azure temporanea per il ripristino, con un disco di grandi dimensioni collegato, quindi la reinvio su S3, l’esecuzione di un altro backup una volta completato e infine lo spostamento sul nostro VPS (cercando di mantenere bassi i costi).
Quindi ho un tar.gz contenente tutti gli upload e posso inserirli direttamente nel nostro bucket S3 mantenendo la struttura delle directory (penso che l’uploader AWS standard possa farlo al giorno d’oggi, altrimenti c’è la CLI). Potrebbe esserci qualche considerazione sulla proprietà / permessi, anche se forse no.
Dopo di che ci sarebbe il remap - non sono sicuro della differenza tra discourse.remap e dbhelper.remap. Vorrei testare tutto questo su un’installazione fittizia con un paio di file prima.
1 Mi Piace