Con quale frequenza eseguire il backup del database principale?

Il suggerimento in BOL è abbastanza vago:

Eseguire il backup di master tutte le volte che è necessario per proteggere i dati in modo sufficiente per le esigenze aziendali. Si consiglia una pianificazione di backup regolare, che è possibile integrare con un backup aggiuntivo dopo un aggiornamento sostanziale.

Se ti avventuri ulteriormente , troverai questi dettagli:

I tipi di operazioni che causano l'aggiornamento del master e che richiedono l'esecuzione di un backup includono quanto segue:

• Creazione o eliminazione di un database utente.
• Se un database utente cresce automaticamente per accogliere nuovi dati, il
  master non è interessato.
• Aggiunta o rimozione di file e filegroup.
• Aggiunta di accessi o altre operazioni correlate alla sicurezza dell'accesso.
• Le operazioni di sicurezza del database, come l'aggiunta di un utente a un database, non influiscono sul master.
• Modifica delle opzioni di configurazione a livello di server o di database.
• Creazione o rimozione di dispositivi di backup logici.
• Configurazione del server per query distribuite e chiamate di procedure remote (RPC), come l'aggiunta di server collegati o accessi remoti.

Quindi se tutti i nostri accessi vengono aggiunti tramite gruppi di Windows e non apportiamo altre modifiche al database, significa che è sufficiente un backup singolo del master?

In caso contrario, qual è l'intervallo di backup standard per il database master?

Il tuo DB master è generalmente molto piccolo. Esegui il backup con il resto dei tuoi database, almeno quotidianamente. Importa?

Personalmente, quando SHTF mi piacerebbe un backup db master che risale a poche ore, anche se ne ho altri 400 identici che risalgono a 400 giorni fa. Non voglio pensare troppo nel caso dovessi ripristinarlo ...

1. Sì, se dall'ultimo backup non sono state apportate modifiche al server (come aggiornamenti, aggiunta di accessi, aggiunta di nuovi database, ecc.), In realtà non è necessario eseguire il nuovo backup. Ma non riesco a capire quale sia il problema con questo: il backup del master è un'operazione rapida, il file di backup è piccolo.
2. Nella mia azienda i master-backup sono divisi in 3 gruppi:
   • una volta ogni 12 ore (per server in cui è possibile aggiungere 10-50 accessi durante la giornata lavorativa)
   • una volta al giorno (per la maggior parte dei server)
   • una volta alla settimana (per una piccola parte dei server con modifiche non frequenti)

Non è uno standard, è una regola aziendale.

Tutti i nostri database di produzione vengono sottoposti a backup quotidianamente in tempi lenti. Se le operazioni fossero in esecuzione 24 ore su 24, 7 giorni su 7, raccomanderei una volta ogni 12 ore come la prima risposta.

Davvero la domanda è: quanti dati e strutture di dati puoi permetterti di perdere? Se un meteorite ha distrutto il tuo database principale in modo che ci fosse solo una fossa fumante nel terreno quanto velocemente potresti portare un backup per prendere il suo posto? Puoi ridere dell'impossibilità di un evento che elimina il tuo database ma se le linee di business lo usano scoprirai che c'è ben poca tolleranza per i tempi di inattività.

Se esegui il backup ogni giorno quante nuove informazioni potresti perdere in un giorno? Quanto tempo per sostituire / ripetere queste modifiche? È possibile ripetere le modifiche di cui non è stato eseguito il backup? Come lo sapresti ...

Invece di concentrarsi sulla politica di qualcun altro, è necessario chiedere alla direzione qual è la sua tolleranza per la perdita di dati e i tempi di inattività.