Se stai gestendo un’installazione self-hosted, dovresti mantenere backup esterni nel caso si verifichi un problema catastrofico con il tuo server. Immagina che il tuo fornitore di server chiuda i battenti un giorno senza alcun preavviso, o che tu riesca in qualche modo a cancellare /var/discourse, eliminando l’intera installazione.
Il minimo indispensabile
Assicurati che i backup siano abilitati.
Impostazioni del sito da considerare:
enable backups: on (predefinito on)backup frequency: Quanto dati sei disposto a perdere? (Predefinito: 7 giorni). @pfaffman consiglia un giornobackup time of day: Quando vuoi che il forum sia in sola lettura durante l’esecuzione del backup?backup with uploads: On, a meno che non archivi i file caricati altrove o li salvi in altro modo. (Predefinito: on)maxiumum backups: Quanto sei paranoico? Quanto spazio su disco hai a disposizione? (Predefinito: 5)
Questo ti consentirà di ripristinare un backup recente nel caso in cui il database si corrompa in qualche modo, ma non ti proteggerà se il server Discourse scompare.
Backup remoti
Per ripristinare il tuo sito su un nuovo server, è necessario almeno il backup creato da Discourse. Sarà molto più semplice configurare un nuovo server se hai i container in /var/discourse//containers.
Come mantenere backup esterni esatti va oltre la portata di questo documento, ma un metodo consiste nell’utilizzare uno strumento come rsync per copiare i dati su un server remoto. Esistono dozzine di guide per farlo; scegli quella che ha più senso per te.
I file in /var/discourse/containers cambiano raramente, quindi effettuarne il backup manualmente solo quando apporti modifiche non è così oneroso. Contengono tipicamente le impostazioni SMTP e i plugin, che sono ragionevolmente semplici da ricostruire a memoria, ma preferiresti non doverlo fare in un’emergenza. Se ciò accadesse, potresti comunque far ripartire il sistema mancando alcuni plugin e con la posta non funzionante, per poi risolvere il resto mentre il sito procede a rilento.
Backup su S3
Il modo più comodo per mantenere backup esterni è inviarli su S3 come descritto all’indirizzo Set up file and image uploads to S3. Se lo fai e conservi le impostazioni di configurazione S3 in un luogo accessibile (o nel file app.yml), potrai ripristinare il sito direttamente da S3 una volta configurato il nuovo server.
È possibile incorporare le impostazioni nel file app.yml. Se includi qualcosa di simile nella sezione env del tuo app.yml, queste impostazioni scompariranno dall’interfaccia web e potrai seguire la procedura Restore a backup from the command line senza dover creare un account amministratore e accedere.
DISCOURSE_S3_ACCESS_KEY_ID: 'key'
DISCOURSE_S3_SECRET_ACCESS_KEY: 'secret'
DISCOURSE_BACKUP_LOCATION: 's3'
DISCOURSE_ENABLE_S3_UPLOADS: true
DISCOURSE_S3_BACKUP_BUCKET: 'my-backup-bucket'
DISCOURSE_S3_REGION: 'us-west-1'
Se hai anche i file caricati su S3 e ti fidi della stabilità del tuo fornitore S3, puoi configurare Discourse per eseguire il backup solo del database (vedi impostazione sopra). Questo ti eviterà di archiviare più copie di tutti i file caricati. Se scegli questa strada, dovresti eseguire un ripristino di prova per assicurarti che effettivamente tutti i file caricati siano su S3.
La pratica rende perfetti
Anche se avere una copia dell’ultimo backup è il minimo indispensabile per ripristinare il sistema in caso di crisi, se vuoi essere davvero sicuro che i backup funzionino, dovresti testarli almeno una volta, se non periodicamente. Avvia un nuovo server e verifica se riesci a ripristinare da un backup.