Modo corretto per proteggere/effettuare il backup di Discourse su server self-hosted?

Ciao,

Su un server self-hosted, quali sono i modi migliori per evitare che il nostro forum vada perso per sempre? Come eseguire correttamente e in modo sicuro il backup dei nostri dati preziosi?

In un argomento ora cancellato, @falco ha detto:

Gli snapshot del file system non sono supportati e potrebbero causare la perdita di dati.

Inoltre, riguardo alla funzione di backup di Hetzner, l’azienda afferma:

consigliamo di spegnere il server per garantire la coerenza dei dati sul disco.

Quindi immagino che non sia davvero una soluzione consigliata… O lo è?

Sul mio forum uso rclone e sincronizzo le mie cartelle di backup locali con una cartella di Google Drive.

Se il mio server si rompe, ho i miei backup settimanali su Google Drive.
Se i backup locali scompaiono e rclone elimina i backup su Drive dopo aver sincronizzato la mia cartella ora vuota, i backup eliminati saranno comunque disponibili, poiché si troveranno nel cestino di Google Drive.

Quindi ritengo che sia un modo ragionevolmente valido per proteggere i dati del mio forum.

Ma è davvero così? Esiste un’altra soluzione affidabile e facile da installare?
Per quanto riguarda rclone: è compatibile con molti sistemi di archiviazione. Ce ne sono alcuni migliori per l’archiviazione e la sincronizzazione dei nostri backup?

Non esisterà mai un modo al 100% sicuro per archiviare i dati. Chiarito questo, Discourse dispone di un eccellente processo di backup eseguibile su base schedulata.

Se non mi fido molto dei dispositivi e posso aumentare la spesa mensile, inizierei a caricare i backup su S3 abilitando la replicazione S3; da lì, utilizzerei uno script per copiare i dati sul mio computer locale e, forse una volta al mese, trasferirei tutto su un disco esterno.

In questo modo si hanno diversi punti di guasto che non falliranno tutti contemporaneamente. L’affidabilità di S3 è piuttosto alta, e il tuo computer locale dovrebbe essere in buone condizioni dato che lo usi quotidianamente e non ha mai fallito (anche se potrebbe, e sicuramente più velocemente di un guasto diffuso su S3).

Poiché questo approccio sicuro non si basa sulla sicurezza delle informazioni (crittografia, ecc.), il modo migliore è avere più copie in più luoghi.

Se sincronizzi da remoto /var/discourse/containers e /var/discourse/shared/standalone/backups, sarai al sicuro. Se il tuo server dovesse smettere di funzionare, ti serviranno solo i file yml del container e il backup più recente. Consiglio backup giornalieri. Se sei particolarmente abile e dedicato, potresti implementare un processo di pulizia sulla destinazione di rsync che mantenga backup settimanali, mensili e annuali.

Ho appena scritto questo: Best Practices for Backups

Vedi anche questo:

Esegui il backup su Amazon S3, che è automatico e integrato.

Utilizziamo rsync da anni e funziona perfettamente per noi. Eseguiamo ogni giorno il rsync dei nostri backup verso un backup offsite che controlliamo e gestiamo noi stessi, così se il data center subisse un disastro, avremmo tutte le risorse :slight_smile:

Inoltre, quando pensi ai backup e alla sicurezza, tieni presente che la sicurezza informatica è composta da tre domini chiave:

  • disponibilità
  • integrità
  • riservatezza

Quando esegui il backup dei tuoi dati, devi considerare tutti e tre questi domini.

Se hai un requisito elevato di riservatezza, eseguire il backup su soluzioni di terze parti (e su cloud che non sono sotto il tuo stretto controllo amministrativo e appartengono ad altri) potrebbe non essere la scelta migliore per te.

La sicurezza non è una soluzione unica per tutti, ma si basa sul tuo modello unico di gestione del rischio. Anche questo è composto da tre aree chiave:

  • minaccia
  • vulnerabilità
  • criticità

È l’intersezione di questi tre domini che aiuta a definire la tua strategia di backup e ripristino.

  • Alcuni siti web sono più esposti alle minacce di altri a causa del loro contenuto o dominio (modello di business), mentre altri non suscitano davvero interesse tra i malintenzionati.

  • Alcune persone sanno come ospitare in modo sicuro, installare gli ultimi patch, proteggere il proprio filesystem, ecc., quindi sono meno vulnerabili di chi non è così esperto (o semplicemente pigro) in quest’area.

  • Alcune persone gestiscono siti web e forum molto critici per la loro missione. Se il sito si interrompe, ad esempio, potrebbero perdere molto denaro in un singolo giorno (o anche in un’ora) o la loro reputazione ne risentirebbe.

  • Altri, se il sito si interrompe, forse solo poche persone se ne accorgono o se ne curano e non viene perso denaro.

Quindi, senza trasformare questo argomento divertente in un trattato sulla sicurezza, devi comprendere i tuoi requisiti di gestione del rischio basandoti sul tuo modello di business e sui tuoi fattori di rischio unici, non sul modello di gestione del rischio di altri.

Una soluzione non va bene per tutti… e questa è una delle lezioni più importanti che gli addetti all’IT possono comprendere sulla sicurezza informatica (ma pochissime in realtà la capiscono). I backup e il ripristino sono una parte fondamentale dell’equazione.

FWIW: Non affidiamo mai i nostri backup a terze parti (mai) e li teniamo sempre in un luogo sicuro sotto il nostro controllo tecnico e amministrativo.


A proposito, un mio amico è uno dei migliori subacquei esploratori di grotte al mondo. Quando si immerge ed esplora grotte sottomarine, ha una ridondanza doppia e tripla (gas, maschere, computer, luci, batterie, coltelli, scooter sottomarini e altro). L’ho visto predisporre oltre 40 bombole di gas e portare con sé almeno due scooter sottomarini. Sa come gestire il rischio sott’acqua.

TUTTAVIA, questo stesso esploratore di grotte sottomarine, famoso in tutto il mondo, non esegue mai il backup del suo computer desktop e spesso va online perché il suo laptop si è bloccato e ha perso tutti i suoi dati. Dice che non gli importa se perde le sue presentazioni PowerPoint… quindi questa è la sua strategia personale di gestione del rischio. Per lui la vita vale molto più di qualche file digitale.

Così va la vita…


Quindi, per rispondere alla tua domanda. Siamo in self-hosting da quasi 30 anni. Conserviamo sempre i nostri backup offsite utilizzando rsync e persino sftp su un server a cui abbiamo accesso, e non abbiamo mai avuto problemi in 30 anni di server su Internet. Ho anche una copia extra nella mia rete domestica su un piccolo Mac Mini come dispositivo di archiviazione privato. Questo è ciò che considero “sicuro”… per il mio modello di gestione del rischio.

Grazie per tutte queste informazioni :+1:t6:

Mi chiedo perché non abbia nemmeno menzionato S3 :thinking: forse stavo pensando inconsciamente a metodi di backup gratuiti… Anche se ho un abbonamento a Google Drive :upside_down_face:

Detto questo, come posso stimare correttamente i costi di S3 per lo storage dei backup di Discourse?
Non sono sicuro di come compilare i campi del calcolatore:


Nel mio caso, i miei backup (con gli upload) sono di circa 1 GB e farei backup giornalieri con una ritenzione di 4-7 giorni, credo.

Un’altra cosa di cui non ho parlato è che vorrei che anche il mio co-amministratore avesse accesso ai backup remoti.
Attualmente su Google Drive ho condiviso con lui la directory in cui sono archiviati i backup.
È possibile condividere l’accesso anche ai backup su S3?

Prevedete costi di 7 GB-mese (più un margine per la crescita) al mese, con un costo aggiuntivo per il trasferimento ogni volta che è necessario recuperare uno dei backup.

Invio o recupero di un backup = 1 richiesta?