In che modo i backup SQL sono diversi dai normali backup notturni del server IT?

Il nostro reparto IT esegue il backup dell'intero server ogni notte (su questo server è installata un'istanza di SQL Server), che dovrebbe eseguire il backup di quel server e dell'intera rete, nel caso qualcosa vada storto ...

Quindi il mio manager mi ha chiesto qual è il significato dei miei backup completi, differenziali e Log SQL rispetto a qualunque sia il backup del reparto IT? Per risparmiare più spazio sul nostro server anziché conservare questi file per un paio di settimane ed eliminarli, pensa che l'IT li fornirà!

So che non è giusto, dato che posso ripristinare fino agli ultimi 30 minuti con i miei backup del log, l'IT lo ripristina il giorno successivo, ma questa è l'unica differenza?

Poiché salvo / invio i file di backup del mio database allo stesso server, l'IT li ripristinerà, ma se non ho questi processi di backup nel mio piano di manutenzione, l'IT può semplicemente ripristinare l'istanza SQL senza nessuna delle nostre tabelle, transazioni ... ecc. Sto capendo bene?
Qualsiasi consiglio sarebbe molto apprezzato.

I backup del database offrono funzionalità di ripristino temporizzato (a condizione che si disponga di FULLun modello di ripristino). Anche se il personale IT esegue i backup ogni pochi minuti, il che è estremamente improbabile, avrai comunque un divario.

I backup del server non sostituiscono i backup del database, ma li completano "archiviando" i file di backup del database a lungo termine (vale a dire più di oggi).

Alla fine tu e il tuo management dovete decidere il vostro RPO (l'obiettivo del punto di ripristino - quanto è necessario per poter recuperare in caso di crash). Con solo i backup giornalieri del server e nessun backup del database, nel caso peggiore perderai un'intera giornata di lavoro.

Modifica : @Sting ha un punto valido in quanto le copie shadow (il meccanismo più probabilmente utilizzato per eseguire i backup del server) non sono molto probabilmente in grado di eseguire una copia esattamente simultanea di tutti i file del database (inclusi i file di registro), il che può portare a incoerenze quando ripristini il backup. Ad esempio, se la copia shadow legge il registro delle transazioni alcuni millisecondi prima di leggere il file del database, il file del database potrebbe contenere una transazione non impegnata, ma poiché la transazione è stata impegnata un millisecondo più tardi, il registro non ne avrà alcuna registrazione.

È possibile che un ripristino di file mdf e ldf dalla copia shadow sia incompatibile dal punto di vista transazionale. Ciò significa che questi ripristini shadow non sono conformi alle proprietà ACID del database.

https://msdn.microsoft.com/en-us/library/aa480356.aspx

È probabile che il ripristino probabilmente funzionerà, ma ti lascerai a chiederti cosa stai effettivamente ottenendo. (Per non parlare del fatto che ti verrebbero affidati dei test per accertarti che i backup del server / le copie shadow funzionino correttamente su tutti i server) Inoltre, non è possibile ripristinare i registri delle transazioni fino a un certo momento come puoi usare SQL Server T -SQL RESTORE LOG / STOPAT.

Fino a quando i backup / ripristini di Windows Server non saranno conformi al test ACID di SQL Server, il nostro settore non può permettersi di correre rischi.

Detto questo, ho partecipato ad alcuni degli incontri più strani. Se trasmetti i problemi all'IT e non sembrano ancora preoccuparsene o sono disposti a correre il rischio, ciò rimuove un enorme onere dalle tue spalle. Qualunque cosa accada, documenta i verbali della riunione di ciò che tutti decidono e perché tutti lo hanno deciso e inviarlo ai partecipanti alla riunione.

Tutto dipende dal prodotto utilizzato dal reparto IT per i backup a livello di server.

Ad esempio, in un ambiente virtuale VMWare eseguirà le istantanee del server. Se SQL Server è coinvolto VMWare ha un'opzione che la maggior parte degli amministratori abilita (o potrebbe essere per impostazione predefinita non lo so) che bloccherà l'IO per i database durante l'istantanea. Ora, mentre ciò dovrebbe richiedere solo pochi secondi, potresti potenzialmente causare problemi alla tua applicazione e non è davvero un metodo affidabile da utilizzare per ripristinare il database.

Se si utilizza un prodotto di terze parti per eseguire backup a livello di server, è probabile che si tratti solo di backup a livello di file dei database. Inoltre, deve avere la possibilità di eseguire il backup dei file bloccati, poiché SQL Server ha tutti i file mdf e ldf collegati bloccati dalla prospettiva di Windows. BackupExec di Symantec, ad esempio, utilizza l'opzione Advanced Open File per eseguire questa operazione, in modo da poter praticamente scattare una foto di quel file bloccato. Proprio il modo in cui i suoni faranno rabbrividire la maggior parte dei DBA se devono ripristinare il database con un backup del genere, pensa alla coerenza del database quando esegue quel backup. Non vi è alcuna garanzia se il backup viene avviato mentre è in corso un processo di caricamento dei dati, quale parte del caricamento dei dati ha ricevuto quel backup?

I backup nativi di SQL Server sono affidabili per il rispetto che vengono verificati come buoni backup. Sai esattamente in che stato si trovavano quando hai sparato il backup per un COMPLETO, se hai pianificato questo intorno ai carichi di dati e così via. Un backup del registro per il modello di recupero COMPLETO garantisce che è possibile ripristinare quel database nel secondo.

Se il tuo manager non è impostato per utilizzare il backup a livello di server, farei una ricerca approfondita del prodotto che stanno utilizzando. Vorrei scoprire se esiste un "componente aggiuntivo" di SQL Server o un agente di backup che è possibile acquistare per consentirgli di eseguire backup VDI dei database.

Qualcosa da considerare e discutere con il proprio manager è quale coinvolgimento sarà necessario avere nella verifica e nella risoluzione dei problemi se i backup di SQL Server falliscono. Ho usato Netbackup pesantemente in precedenti lavori e alcuni anni fa un cliente voleva farmi passare per testare l'uso dell'agente SQL Server di Netbackup per il loro ambiente. Ciò includeva altri DBA che dovevano anche fornire supporto. Ho detto loro in anticipo che la risoluzione dei problemi relativi agli errori di backup per SQL Server richiedeva una buona conoscenza di Netbackup. I server master Netbackup generalmente vengono eseguiti su server Unix, quindi ora devi conoscere alcuni Unix .... può essere divertente ma più doloroso se sei già occupato. Solo qualcosa da considerare e può essere un buon punto di discussione con il tuo manager e scoprire chi è responsabile della risoluzione dei problemi.

Ci sono solo meno di un milione di variabili nella tua domanda. Dovrai parlare con il tuo dipartimento IT su quali backup eseguono. Con ogni probabilità hanno o possono avere backup fino al minuto disponibili. Quanto tempo impiegano per caricarli dipende da più variabili.

In uno scenario perfetto, il reparto IT mantiene i backup su uno o più server diversi in posizioni diverse. Probabilmente stai mantenendo il backup sullo stesso server su cui vivono i tuoi database. Quindi, se il server muore o il tuo edificio si brucia, il tuo reparto IT probabilmente può ripristinare i tuoi file, ma i backup che hai eseguito andranno via con il server.

MA puoi ripristinare il tuo backup, alla tua velocità, quando vuoi, purché il tuo server sia ancora attivo.

Come altri hanno già detto, dipende dalle tue esigenze, dalla tua tolleranza al rischio e da quanto sia importante il controllo dei tempi di recupero. Se vuoi recuperare da qualcosa di stupido che hai fatto, i tuoi backup saranno più veloci e migliori. Se si desidera ripristinare un disastro al di fuori del proprio controllo, il backup IT (dovrebbe essere) la scelta migliore.