Non è forse troppo rischioso fare solo 1 backup al giorno? Se succede qualcosa al server e l’ultimo backup è avvenuto ieri, cosa devo fare? Gli utenti registrati tra ieri e oggi non saranno più registrati? Penso sia meglio fare backup più frequenti, magari ogni ora. Ma nel caso, bisogna mettere il sito in sola lettura prima di fare un backup? Grazie in anticipo!
3 Mi Piace
+1 per questo, di nuovo. Discourse è l’unico sistema dinamico in cui è possibile automatizzare il backup del database solo una volta al giorno.
Non mi aspetto che questo cambi nel core a breve. Ho avuto conversazioni sul cambiamento del default a più di una volta alla settimana e questo non sta accadendo.
Penso che potrebbe essere utile un plugin che aggiunga un’impostazione del sito per eseguire backup solo del database in un certo numero di ore (non c’è motivo di conservare un milione di copie di upload non comprimibili in tutti quei backup completi). Se sei interessato, mandami un messaggio privato o chiedi nel marketplace.
2 Mi Piace
Se hai bisogno di un migliore disaster recovery, ti consiglio di seguire Eseguire Discourse con un server PostgreSQL separato ed eseguire PostgreSQL per conto tuo, dove puoi controllare l’esatta alta disponibilità di cui hai bisogno, come repliche di sincronizzazione live, ripristino point-in-time e backup più frequenti.
3 Mi Piace
Posso chiedere il motivo di questa policy, è tecnica o più legata alla classe? Un intervallo di 24 ore tra i backup è un problema piuttosto critico per i forum ad alto traffico. O è qualcosa che offrite solo ai clienti paganti?
1 Mi Piace
L’esecuzione di Discourse con un server PostgreSQL separato riduce la velocità trovandosi su un server diverso?
1 Mi Piace
Certo, questa è una soluzione. Una soluzione piuttosto rara tra le app, però. Nel mondo PHP/MySQL, eseguire il backup del database utilizzando cron sarebbe davvero facile da fare, ma ancora una volta, in quel mondo ogni app può farlo da sola, con o senza qualche plugin.
Sì, sono un po’ più di un utente finale medio 
ma ho una comprensione molto limitata di come funzionano docker, rails ecc. e per me la situazione in cui le attività comuni sono quasi impossibili è davvero difficile da capire. Certo, forse è a causa delle mie limitazioni, ma non sono l’unico a chiedermelo, però.
Bene. Non otterremo facilmente backup del database nel futuro prossimo o medio, ho capito.
1 Mi Piace
Puoi configurare anche i backup di PostgreSQL con cron. Niente di diverso qui.
Non in alcun modo rilevante. Ogni istanza di Discourse che ospitiamo, come questa qui, utilizza un database su un server dedicato.
2 Mi Piace
Ti faccio solo due domande per capire meglio.
- Il database è l’unica cosa di cui hai bisogno per ripristinare tutto, giusto? Il backup che viene eseguito quotidianamente tramite le impostazioni, esegue il backup solo del database?
- Il forum dovrebbe essere in modalità di sola lettura quando si esegue il backup del database? O può essere fatto senza alcun problema, in qualsiasi momento?
Grazie mille in anticipo!
2 Mi Piace
Le impostazioni risiedono nel database.
Tecnicamente, è necessario anche eseguire il backup della cartella uploads e della definizione del sito app.yml. Tuttavia, questo di solito viene gestito avendo app.yml nel controllo di origine e gli uploads in un servizio di object storage.
Non è necessaria la modalità di sola lettura.
4 Mi Piace
Quindi, supponendo che io abbia il database su un server separato e faccia backup di quel database ogni ora. Se faccio anche il backup, dalle impostazioni nel pannello di amministrazione, solo i file inclusi il file app.yml e la cartella uploads sarebbero inclusi nel backup, ma non il database, giusto? @Falco
1 Mi Piace
Il backup includerà il database e i caricamenti (se non sono su S3). app.yml non è nel backup, poiché Discourse non può leggerlo.
Ciò che consiglio alla maggior parte delle persone è di avere i backup su S3 e app.yml in un posto dove puoi recuperarlo in caso di emergenza. Quindi puoi creare un nuovo container con app.yml e ripristinarlo dalla riga di comando. Ma se hai le competenze tecniche per eseguire il backup/ripristino di postgres con un altro strumento, e le immagini su S3 (o forse le hai anche sottoposte a backup in un altro modo), allora puoi semplicemente ricreare il container e sarai di nuovo operativo.
Oppure forse vuoi avere più server postgres continuamente specchiati e quindi organizzarti per passare automaticamente al backup se il primario va giù.
Ci sono un miliardo di modi per fornire backup più frequenti di quelli forniti da Discourse. Se hai bisogno di backup più frequenti, dovrai farli in un altro modo.
2 Mi Piace
Un altro punto qui riguarda il rischio e la manutenzione: se si utilizza la soluzione giornaliera “out of the box” è probabile che sia più robusta e affidabile come soluzione di backup rispetto alla configurazione di una propria. Cosa succede se qualcosa va storto con la propria soluzione e lo si scopre solo quando è troppo tardi? Almeno con la soluzione standard si hanno centinaia di siti che la testano quotidianamente.
Dato che non ho avuto una singola esperienza di corruzione in diversi siti in 4 anni, anche il rischio di aver effettivamente bisogno del backup in primo luogo è basso…
Forse altri possono menzionare rischi maggiori, ma probabilmente il rischio maggiore sono i problemi dovuti al riempimento del server? Quindi tieni d’occhio lo spazio? Imposta un avviso?
3 Mi Piace
Quindi, da quanto ho capito, il modo migliore è tenere tutto separato.
Server principale per l’esecuzione di Discourse. Poi un server per PostgreSQL e S3 (o qualsiasi altro servizio di object storage) per i caricamenti.
Il file app.yml mi sembra che non cambi spesso, quindi devi solo salvarlo una volta. O al massimo un paio di volte durante il mese.
Questo ti permette di fare backup dei tuoi file, anche in modo più organizzato.
Se è così, trovo che la loro scelta di non implementare backup multipli giornalieri nel core abbia senso. D’altra parte, chi ha esigenze complesse farà sicuramente configurazioni particolari come questa. E alla fine devi solo rifare l’installazione (con l’app.yml salvato da qualche parte) e poi ricollegarlo al database e all’S3 per i caricamenti dei dati. I backup sono in quei 2 server separatamente, quindi è facile da gestire per me. Trovo che sia una soluzione molto equa.
Grazie a tutti per la spiegazione.
3 Mi Piace
C’è un altro thread qui: Configure automatic backups for Discourse - #113 by Tris20
@pfaffman ha fatto alcune raccomandazioni lì con dei link. Questo mi ha portato alla riga di comando come modo per pianificare backup più frequenti, che per me è una soluzione piuttosto ragionevole:
Nota che con questa soluzione potresti combinare tutto in uno script Python per pianificare anche una copia del file yaml, ecc. allo stesso tempo.
2 Mi Piace
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.