Pianificazione di Backup e Ripristino

Voglio garantire una buona strategia di backup quando il mio sito andrà online. Questi sono i seguenti passaggi che ho messo in atto. Cosa mi manca?

Backup del database

  • Discourse esegue un backup giornaliero del database.
  • Viene eseguito un ulteriore backup del database tramite cron ogni giorno. (+12 ore dal backup basato sull’interfaccia utente)
  • I backup vengono archiviati in un bucket S3 (data center diverso)

File principali

I seguenti file vengono sottoposti a backup due volte al giorno in un bucket S3 (data center diverso)

  • discourse/containers/app.yml
  • discourse/shared/standalone/uploads/
  • discourse/shared/standalone/backups/
  • discourse/shared/standalone/ssl/
  • discourse/shared/standalone/letsencrypt/

I backup dei file avvengono due volte al giorno, 30 minuti dopo i backup del database.

S3: Uploads

  • Il backup giornaliero degli Uploads viene archiviato in un bucket S3 in un data center diverso.

Backup del server

  • Backup settimanali dell’intero server - vengono conservati 4 backup settimanali
  • Archiviazione annuale di un backup settimanale come backup principale in una posizione remota.

Ciò dovrebbe fornire tutti i dati e le impostazioni necessarie per ripristinare un server in loco o su un nuovo server.

Mi manca qualcosa?

1 Mi Piace

Questo è il modo suggerito. Se esegui il backup del tuo database una volta al giorno, rischi al massimo 24 ore di qualsiasi cosa sia accaduta in quel forum.

Mi è stato detto almeno due volte che non è un problema, ma nessuno ha mai spiegato perché no. Quindi sto eseguendo il backup del mio database ogni 6 ore — il mio forum non è molto trafficato, quindi posso correre questo rischio. Per fare un confronto — il mio e-commerce esegue il backup ogni 4 minuti.

1 Mi Piace

Come hai configurato il tuo database per eseguire il backup più frequentemente? Preferirei due volte al giorno, ma la funzionalità dell’interfaccia utente consente solo giornalmente.

Puoi avere un cron job (sul tuo server, non nel container) che esegue

docker exec app bash -c "discourse backup"

Se i dati sono davvero critici, puoi configurare un server di replica postgres e avere ogni commit su un secondo server.

1 Mi Piace

Ho questo in crontab:

docker exec app discourse backup --sql-only

Questo è il comando CLI di Discourse per il backup, e mi è stato detto che docker exec app lo esegue al di fuori del container (app sul nome del container, ovviamente).

E poiché ho configurato S3 che salta nello stesso bucket dove si trovano anche i backup “normali”.

C’è un piccolo problema… molto presto ci saranno un miliardo di backup. Non so se dovrei fare diversamente il dump SQL, spostarlo usando aws-cli e poi eliminare tutto ciò che è più vecchio di un certo periodo di tempo. O fare la stessa cosa sul VPS.

Ma questo è il modo più semplice per ottenere il dump SQL.

1 Mi Piace

Presumo che questo attivi la routine di backup del discorso interno, quindi tutte le notifiche rimangono al loro posto.

Disattivi la pianificazione del backup all’interno dell’interfaccia utente e gestisci tutto tramite cron? oppure, ne fai uno all’interno dell’interfaccia utente e fai quello aggiuntivo tramite cron?

No. Faccio entrambe le cose. Non mi fido abbastanza né del sistema né di me stesso. Molto raramente la quantità di backup è un problema, la carenza lo è.

1 Mi Piace

Grazie @Jagster e @pfaffman per l’aiuto nell’impostare un database aggiuntivo tramite cron. Questo riduce la perdita massima di dati del mio sistema a 12 ore.

2 Mi Piace