Comprensione dell'impatto / rischio della disattivazione della "verifica dell'integrità del backup" sul backup SQL

Attualmente utilizziamo piani di manutenzione standard per i backup sui server SQL Server 2005/2008 / 2008R2 / 2012 nel nostro ambiente e la casella "Verifica integrità backup" è sempre stata selezionata.

Alcuni backup durano molto a lungo, quindi ho consigliato di disattivare questa opzione, ma il management ha bisogno di me per documentare l'impatto e i rischi di questa modifica.

Comprendo l'uso e la cronologia di questa opzione, mi sembra inutile raddoppiare il tempo per il processo di backup quando (a mio avviso), qualsiasi errore che potrebbe verificarsi si verifichi durante la fase di backup , non durante la verifica.

Ho sbagliato? È un rischio minimo disattivarlo, se eseguo il backup su disco e non su nastro in streaming o altro? (Effettuiamo il backup in rete su un'appliance di backup EMC DD-800, se pertinente.)

Esistono raccomandazioni ufficiali sulla SM per quando è sicuro spegnerlo?

Esegui "verifica" su ogni backup nel tuo ambiente? Li controlli a campione?

MODIFICA : Per chiarire, quando si seleziona "verifica integrità del backup" nel piano di manutenzione, SQL eseguirà un RIPRISTINO VERIFICAMENTE completo su ciascun database immediatamente dopo ogni backup. Questo è altrettanto intenso in termini di dati / I / O del backup originale e (sostanzialmente) raddoppia il tempo complessivo del processo di backup. Ciò non equivale a abilitare l'opzione "checksum" sul backup (che non è possibile eseguire nella procedura guidata, per quanto ne so).

Ho sbagliato? È un rischio minimo disattivarlo, se eseguo il backup su disco e non su nastro in streaming o altro?

No, hai ragione :-)

RESTORE VERIFYONLYsolo non ti assicurerai che sarai in grado di recuperare il tuo database in caso di corruzione. Per sua natura, non eseguirà alcun controllo di integrità.

Un modo migliore sarà quello di eseguire periodicamente i backup e fare un ripristino valido su un altro server ed eseguire DBCC CHECKDB su di esso.

Questo è uno dei motivi per cui non sono un grande fan dei piani di manutenzione poiché la GUI non espone molte opzioni del genere backup .. with CHECKSUMche possono essere raggiunte da T-SQL.

Dal blog Myth di Paul Randal

24p) utilizzando RESTORE ... WITH VERIFYONLY convalida l'intero backup

No. L'uso di VERIFYONLY convalida solo l'intestazione del backup appare come un'intestazione del backup. Solo quando si esegue il backup con WITH CHECKSUM e si ripristina ... CON VERIFYONLY e si utilizza WITH CHECKSUM che il ripristino esegue controlli più approfonditi, incluso il checksum sull'intero backup.

Esegui "verifica" su ogni backup nel tuo ambiente? Li controlli a campione?

Non eseguo il VERIFYONLY. Invece prendo il backup con CHECKSUM e poi li ho ripristinati + CHECKDB su un altro server. È possibile seguire il campionamento statistico per la verifica dell'approccio Backup database se si desidera essere creativi.

Ciò non equivale a abilitare l'opzione "checksum" sul backup (che non è possibile eseguire nella procedura guidata, per quanto ne so).

È possibile abilitare Trace Flag 3023 in modo che l' CHECKSUMopzione sia abilitata automaticamente per il comando BACKUP. Come sempre, prova il comportamento di eventuali flag di traccia nel tuo ambiente!

La linea di fondo è: abbandonare i piani di manutenzione e utilizzare una soluzione di backup più sensata (suggerimento: la soluzione di backup di Ola) che ti consentirà di personalizzarla in base alle tue esigenze.

(Effettuiamo il backup in rete su un'appliance di backup EMC DD-800, se pertinente.)

Eseguire il backup in locale sul disco e quindi disporre di un processo di trasferimento PowerShell che copierà il backup in locale dal server in una condivisione di rete (server di backup). Sarà più veloce rispetto alla copia diretta su una condivisione di rete.

Inoltre, abilita l'inizializzazione istantanea dei file, che aiuterà con le crescite automatiche sui file di dati e contribuirà a ridurre i tempi di ripristino (in caso di necessità di ripristinare i database). È sempre utile avere opzioni a portata di mano.

Una buona lettura sarà: Backup: Pianificazione di una strategia di recupero

La linea di fondo è che a meno che non si esegua il ripristino di un database da qualche parte, non si può essere completamente sicuri che un determinato file di backup sia valido.

Il test ideale per verificare i backup è quello di impostare un ambiente in cui i backup del database e i backup del registro del database vengano ripristinati continuamente come parte del processo quotidiano. Questo è uno dei vantaggi dell'utilizzo del log shipping ...

Se si desidera continuare a verificare solo, è possibile impostare un ambiente appositamente solo per fare questo. Ciò scaricherà il lavoro dal tuo (presumibilmente) server di produzione e ridurrebbe i tempi di lavoro.

Infine, hai considerato di abbandonare i piani di manutenzione? Script come gli script di Ola sono esclusi i backup e la manutenzione: https://ola.hallengren.com/

Tecnicamente il ripristino è come eseguire un ripristino, tuttavia non è meglio verificare che il ripristino del database sia effettivamente valido. Abbiamo avuto un'istanza in cui è stata verificata solo la verifica, tuttavia il database non è stato ripristinato a causa della corruzione, il mio punto è non contare su questo come verifica che il backup sia corretto. Ora abbiamo sviluppato un sistema che ripristina tutti i nostri database su un'istanza separata per verificarne la validità, chiaramente questo non è sempre possibile, quindi prova a campionare determinati database a settimana. I long e short non si fidano solo del 100%.