# Pianificazioni di backup multiple

**URL:** <https://meta.discourse.org/t/multiple-backup-schedules/223312>\
**Category:** Feature\
**Created:** [5 Aprile 2022, 8:36am UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312 "2022-04-05T08:36:27Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![RGJ](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rgj/32/523185_2.png) [@RGJ](https://meta.discourse.org/u/RGJ)\
**Post date:** [13 Aprile 2022, 12:19pm UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312/11 "2022-04-13T12:19:45Z")

</div>

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)_

---

_[View the full topic](https://meta.discourse.org/t/multiple-backup-schedules/223312)._
