Che cos'è una buona pianificazione del backup di SQL Server?


18

Sembra che ci siano molte informazioni sul processo di impostazione delle attività di backup, ma non molte informazioni sulla visione generale dei backup del database. Almeno, è difficile formulare una query del motore di ricerca che ti fornisca tali informazioni. So che ci sono tre diversi tipi di backup:

  • Backup completi del database
  • Backup differenziali del database
  • Backup del registro delle transazioni

Sembra che dovrei usarli tutti e tre. Quindi, questo è un programma che ha senso?

  • 1 ° di ogni mese : esegue unbackup completo del database.
  • Ogni giorno a mezzanotte : esegui unbackup differenziale del database.
  • Ogni 15 minuti : esegue unbackup del registro delle transazioni .

In questo modo, se il mio database fallisce, diciamo, il 12, ripristinerei il backup completo del database dal 1 °, farei i 12 backup differenziali dal 1 ° al 12 ° e infine ripristinerei il registro delle transazioni più recente (sono il registro delle transazioni differenziale?).

Infine, un backup completo del database è autonomo? vale a dire, una volta effettuato il backup completo del database il 1 ° febbraio, posso eliminare tutti i file da gennaio? Certo, terrei un paio di set dei mesi precedenti per ogni evenienza, ma la domanda è concettuale.

Risposte:


24

Come per tutte le cose in SQL Server, dipende.

La prima cosa che devi fare è assicurarti di capire cosa fa ogni tipo di backup.

Books Online ha tutti i dettagli appiccicosi , ma ecco il mio riassunto.

Un backup COMPLETO contiene tutto all'interno del database. Un backup DIFFERENZIALE è cumulativo NON incrementale. Nel tuo esempio, se il tuo database non è riuscito il 12, dovrai ripristinare il backup completo solo dal 1 ° e quindi il differenziale più recente il 12, seguito da tutti i backup del registro delle transazioni fino al fallimento. Un backup del REGISTRO DI TRANSAZIONE è necessario solo per i database che utilizzano il modello di recupero con registrazione completa o in blocco. Se si utilizza il modello di recupero semplice, non sono necessari backup del registro delle transazioni.

Ora che l'abbiamo chiarito ... La progettazione di una pianificazione di backup dipende in realtà dalla quantità di dati necessari per il ripristino e dalla velocità con cui è necessario ripristinarli in caso di un diaster. Consiglierei di iniziare con un backup completo ogni giorno. Puoi sempre ridurre la frequenza in seguito. Ricorda che il backup differenziale è cumulativo dall'ultimo completo, quindi a seconda della modifica della quantità in corso nel tuo database il differenziale potrebbe essere più grande del backup completo dopo alcuni giorni. Se si esegue un backup completo ogni giorno, potrebbe non essere necessario utilizzare i differenziali; tuttavia potresti ancora farlo una volta al giorno e programmarlo alle 12.00. Il backup del registro delle transazioni esegue solo il backup del registro. La frequenza del backup del registro determinerà la quantità di dati che sei disposto a perdere in caso di errore. Se si esegue il backup del registro ogni 15 minuti, allora ti aspetteresti di perdere fino agli ultimi 15 minuti di dati che sono cambiati. 15 minuti sono una buona frequenza, ma ogni 30 minuti funziona perfettamente per il mio ambiente.

Come ho detto prima, tutto dipende dal tuo ambiente. Dopo aver progettato e impostato la pianificazione del backup, ricordarsi di testarlo su un server alternativo. Esercitati a ripristinare i backup completi, diff e log in modo da sapere che tutto funziona come l'hai progettato.

La documentazione online offre alcune buone informazioni se si prevede di utilizzare i piani di manutenzione, ma se si desidera davvero la flessibilità, consultare gli script di backup di Ola Hallengren .


Grazie per la magnifica risposta. Ho una domanda minore per te: ricostruisci / riorganizzi i tuoi indici troppo prima dei backup completi?
atanamir,

Sì, prima del backup completo è una buona idea. In questo modo se il database non riesce, il backup completo conterrà già tutte le modifiche reindex.
Patrick Keisler,

Nella maggior parte dei casi è possibile eseguire il backup del registro di coda attivo dopo l'errore, pertanto l'esposizione alla perdita di lavoro è minima anche se si esegue il backup del registro solo quotidianamente. Detto questo, di solito non c'è motivo di non eseguirne il backup frequentemente.
Presto, il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.