Pianificazioni di backup multiple

Non sono sicuro se rispondere qui o creare un nuovo post: Richiesta di funzionalità: pianificazioni separate per “includi allegati” e “non includi allegati”.

Mi piacerebbe molto avere backup giornalieri piccoli, forse anche più volte al giorno dato che il database è piccolo. Non sarei devastato se perdessi una settimana di allegati, dato che sono molto più limitati e di solito le persone possono ritrovare la loro fonte. Questo potrebbe aumentare il fattore di sicurezza senza sovraccaricare lo storage.
Non ho guardato il codice sorgente, ma probabilmente sarebbe una revisione piuttosto importante poiché i ripristini dovrebbero essere entità separate, o almeno la capacità di avere diversi punti di ripristino per le 2 origini.

4 Mi Piace

L’azione suggerita per questa richiesta è solitamente quella di eseguire altri backup del database utilizzando uno strumento esterno di qualche tipo.

Se sposti i caricamenti su S3, puoi eseguire solo backup del database e non preoccuparti dei caricamenti.

6 Mi Piace

Abbastanza ragionevole. Non appena inizio a considerare strumenti esterni, penso a “modi esterni per mandare davvero tutto all’aria” poiché sono tipicamente capaci di più caos rispetto alla console di amministrazione integrata a prova di idiota (più o meno).

L’ultima volta che io e altri abbiamo chiesto la stessa cosa, le risposte sono state le stesse di prima:

  • un backup giornaliero è sufficiente
  • utilizzare strumenti esterni, come script e cron

Beh, un backup giornaliero dal database non è sufficiente, uno orario potrebbe esserlo.
Qualsiasi strumento esterno può fare il lavoro, è vero. Ma tutte le altre app offrono un backup decente nativamente, ma non Discourse.

Mi piacerebbe davvero sapere se il motivo è

  • “non vogliamo farlo, ecco perché nessun altro ne ha bisogno”
  • è tecnicamente molto difficile e/o costoso

Beh, e c’è sempre una terza opzione: Marketplace

Se vuoi molti backup con WordPress (una popolare piattaforma web) devi usare un plugin di backup che costa denaro, quindi forse non tutte le altre app lo fanno nativamente. Almeno questo è quello che sto facendo, anche se è passato molto tempo da quando ho preso quella decisione, quindi forse è stata una decisione sbagliata.

Il motivo è che avere molti backup è un modo per riempire il tuo disco, che è una delle ragioni più comuni per cui un sito self-hosted va offline (il che penso lo metta nella categoria “costoso”). Quindi l’idea è che se hai abbastanza abilità per gestire un’infinità di backup e gestire lo spazio del tuo disco, allora puoi probabilmente risolvere questo problema in molti modi. E se vuoi backup orari, allora devi farli essere solo backup del database piuttosto che dozzine o centinaia di copie dei tuoi caricamenti.

Quindi i backup orari hanno senso solo se hai caricamenti su S3 in modo da poter fare backup solo del database, e probabilmente inviarli su S3 in modo da non preoccuparti del tuo disco locale. E poi ci sono un numero piuttosto esiguo di siti self-hosted che lo desiderano.

Se hai tutto questo a posto, allora un plugin che farebbe backup orari solo del database non richiederebbe più di un’ora o due di lavoro, o forse 2-10 se non sai come creare un plugin e devi capire come creare un lavoro orario.

1 Mi Piace

Vero. WordPress da solo non può fare molto. Ecco perché ci sono così tanti plugin, buoni e cattivi.

Certo, non ha senso fare il backup dei file o del sistema stesso, così spesso. Il database stesso è un gioco completamente diverso. Dovrebbe essere fatto almeno ogni 15 minuti se c’è più traffico.

La domanda è molto semplice: quanto contenuto puoi permetterti di perdere.

Se la perdita massima di dati che puoi permetterti è così piccola, potresti considerare l’utilizzo di una soluzione di replica di Postgres invece di eseguire backup così frequentemente.

4 Mi Piace

C’è qualche altro dato di cui non sono a conoscenza? O usi dati nel senso più ampio includendo tutti i file; di sistema, Docker/Discourse/ecc., caricati?

Quei file possono essere recuperati facilmente o con piccoli costi — beh, tranne quelli caricati, ma è per questo che abbiamo S3 :wink: .

No, intendevo i dati del database.

1 Mi Piace

Allora è per lo più di piccole dimensioni, ma è il più grande se pensiamo al forum stesso. Ma per qualche motivo siamo tornati a questo:

Mi piacerebbe davvero sapere se il problema principale qui è tecnico o mentale. O fa parte del modello di business e se il backup sarà facile e funzionante, l’hosting perderà un punto di forza — e non so se ci sia affatto una tale argomentazione di vendita. Sto solo cercando di capire perché un backup migliore sia una questione così importante, anche se è già stato richiesto in precedenza.

Non c’è bisogno di sospettare che ci sia una strategia o un piano malvagio dietro questo. Non credo ci sia molto interesse per backup più frequenti. Se ci fosse, qualcuno avrebbe scritto un plugin per questo. Sarebbe qualche ora di lavoro. Non vedo il Marketplace inondato di richieste a riguardo.

Penso che si riduca a:

  • per i forum piccoli, non perderai comunque molti dati perché non c’è molto di nuovo in un giorno, quindi backup più frequenti non valgono davvero lo sforzo
  • per i forum più grandi, backup più frequenti richiederanno prestazioni e spazio di archiviazione
  • per forum molto grandi, vorrai considerare soluzioni diverse (come la replica su un server di database standby attivo)

Non dimenticare che anche le probabilità di aver bisogno effettivamente di un backup sono molto piccole. Nella storia di Communiteq (oltre 8 anni), abbiamo dovuto ripristinare un backup solo una volta e ciò è accaduto solo perché eravamo impazienti e non volevamo aspettare qualche ora per un ripristino del file system.

*) (esclusi i ripristini su richiesta del cliente dove volevano semplicemente annullare le modifiche, per lo più in forum non di produzione, ed escluso il nostro test di ripristino mensile)

4 Mi Piace

Quindi, se cerco qui non trovo argomenti in cui Discourse è crashato per qualche motivo e l’unica soluzione è stata il ripristino da un backup?

Ma è bello sentire che Discourse è così solido da non aver bisogno di backup aggiornati. Beh, sappiamo che non è del tutto vero.

Quindi il cerchio si chiude e siamo tornati al punto di partenza:

E la terza opzione. Finché sto di fatto facendo dei test per Discourse, qui e per conto mio, non sono disposto a pagare per una funzionalità così basilare.

Beh, stiamo parlando qui senza alcun commento dal team. Di nuovo :rofl:

Quanto pensi che costerebbe svilupparlo? A seconda del prezzo, sarei disposto a finanziarlo subito se sei interessato. :dollar:

Quel problema è già stato affrontato da CDCK. Dai loro solo un po’ di tempo per rispondere, tutto qui.

Questo è il modo. Segui Eseguire Discourse con un server PostgreSQL separato per eseguire la tua istanza PostgreSQL e gestire backup e alta disponibilità come ritieni opportuno se il backup giornaliero non è sufficiente per il tuo caso d’uso.

3 Mi Piace

Sto pensando a $250-500, a seconda di quanto sia configurabile e di quanto lavoro sia necessario sul front-end. Non ho ancora guardato cosa comporterebbe, però. @RGJ potrebbe farlo per meno; mi ha spesso sorpreso con la rapidità con cui riesce a fare le cose.

EDIT: OH, questo argomento è chiuso. Se sei interessato, puoi contattarmi o pubblicare su Marketplace.