Devo eseguire il backup di 10-20 database di SQL Server 2008 R2 con dimensioni comprese tra 10-50 GB, mentre sono online e utilizzati contemporaneamente da un'unica app aziendale. Devo anche ripristinarli a uno stato ampiamente sincronizzato tra tutti i database (posso permettermi fino a qualche secondo di desincronizzazione tra i database). Lo scopo è acquisire dati di produzione per ambienti QA / DEV.

Vorrei fortemente non richiedere che i database funzionassero nel pieno recupero e trovare un metodo di backup dedicato alla cattura dei dati per gli ambienti di controllo qualità e che rimanga indipendente da un processo di backup principale che non è sotto il mio controllo.

Per i miei clienti, ci vorranno 1-2 ore per acquisire 20 backup completi a ~ 30 GB ciascuno. Ciò rende inaccettabile l'esecuzione di backup completi sequenzialmente, poiché i database sarebbero troppo desincronizzati durante l'esecuzione in un semplice ripristino.

Sto cercando un'idea migliore di queste:

IDEA 1: istantanea a livello SAN dei dischi VM. xcopy MDF / LDF dall'istantanea.

Una volta che i file copiati sono collegati a un'istanza del server diversa, il suo processo di recupero dovrebbe produrre database coerenti che sono istantaneamente quasi istantaneamente.
Googling around mi ha convinto che questa è una cattiva idea, almeno perché potrei ottenere desincronizzazione contro master / msdb / ecc.

IDEA 2: orchestra un backup complesso e sincronizza-ripristina su tutti i database

Ciò richiede che i database esigenti vengano eseguiti in pieno recupero, cosa che non desidero. Avviare backup paralleli per tutti i database ben prima della scadenza (T0). Una volta raggiunto T0, eseguire il backup di tutti i registri (dovrebbe richiedere al massimo alcuni minuti). Prendi la miriade di backup risultante e prova a ripristinarli e sposta i log in avanti / indietro per ottenere uno stato piuttosto coerente tra i database, rispetto a T0.
Ciò richiede molta pianificazione e scripting per utilizzarlo in modo affidabile, quindi farei di tutto per evitarlo.

Mi manca qualche altra soluzione?

PS1: Mi sarebbe piaciuto poter usare le istantanee di db . L'idea era di avviare un'istantanea su ciascun db (che dovrebbe essere finita in pochi secondi), quindi eseguire il backup completo di ciascuno in sequenza nei minuti / ore seguenti. Quindi ripristinali tutti su un altro server e ripristina ciascuno sull'istantanea. AFAIK questo scenario non è possibile perché non è possibile eseguire il backup degli snapshot insieme al database. Possono essere ripristinati solo sul posto, sul server in cui sono stati creati. Inoltre, richiedono Enterprise Edition che non ho per tutti i clienti.

PS2: se conosci una soluzione di terze parti in grado di produrre backup sincronizzati cross-db, menzionalo.

Devo eseguire il backup di 10-20 dbs di SQL Server utilizzati contemporaneamente da una singola app aziendale, mentre sono online, in modo da ripristinarli a uno stato ampiamente sincronizzato tra tutti i dbs

Quello che stai cercando è un backup coerente in tutti i database dei clienti, dovresti usare i backup COMPLETI insieme Marked Transactions(enfasi in grassetto aggiunto):

Quando si eseguono aggiornamenti correlati a due o più database, database correlati , è possibile utilizzare i segni di transazione per ripristinarli in un punto logicamente coerente . Tuttavia, questo recupero perde qualsiasi transazione che viene impegnata dopo il segno utilizzato come punto di ripristino. Contrassegnare le transazioni è adatto solo quando si stanno testando database correlati o quando si è disposti a perdere transazioni impegnate di recente.

Assicurarsi di eseguire il backup del log delle transazioni ad hoc COPY_ONLY, altrimenti il ​​ripristino sarà un problema, poiché qualsiasi backup del log delle transazioni ad hoc senza COPY_ONLYinterromperà la catena di log. Per precauzione, è possibile limitare gli utenti all'utilizzo solo dei COPY_ONLY backup .

Ho bisogno di una soluzione per SQL Server versioni 2008 R2 e successive. Le dimensioni dei database sono fino a 50 GB per db e il tempo per il backup di tutti è probabilmente superiore a 1-2 ore.

Le transazioni contrassegnate funzioneranno per la tua situazione. L'unica cosa per fare backup paralleli è per STRIPEloro, ma poi si finisce per assicurarsi di non perdere le strisce di backup. Per renderli più veloci, puoi giocare con BUFFERCOUNTe MAXTRANSFERSIZE.

È necessario utilizzare la compressione del backup e abilitare l'inizializzazione del file istantaneo .

Fare riferimento a

• Utilizzo delle transazioni contrassegnate (modello di recupero completo)
• Come aumentare la velocità di backup completo del database SQL utilizzando la compressione e i dischi a stato solido?

Se si eseguono backup completi e backup del registro delle transazioni (e se si considerano questi dati importanti) è possibile semplicemente copiare i backup e i backup del registro delle transazioni sul sistema di test ed eseguire un ripristino temporizzato per ripristinare i database su + - allo stesso tempo.

A seconda che tutti i database risiedano sullo stesso computer SQL Server o in che modo gli orologi dei server siano sincronizzati, si dovrebbe essere in grado di abbinare il target di "desincronizzazione di un paio di secondi".

Potrebbe essere un po 'una soluzione di cerotto ma soddisferebbe i requisiti e sarebbe abbastanza semplice ed economico.

Se non si dispone di backup completi e backup del registro delle transazioni dai database importanti (che sono in pieno recupero) è necessario rivedere la strategia di backup. Le snapshot a livello SAN hanno davvero il punto di avere un database in modalità di recupero completo poiché non sarai in grado di eseguire comunque un ripristino temporizzato.

Si prega di leggere ciò che MrDenny ha da dire al riguardo

Nelle circostanze che hai indicato hai esaminato i backup VSS tramite un provider VSS di terze parti o basato su Microsoft? È possibile eseguire un backup COPY_ONLY che non interromperà la catena di recupero della produzione e si dovrebbe finire con un backup di tutti i database che è possibile ripristinare altrove entro i limiti ragionevoli. Tenere presente che un backup VSS ha alcuni degli stessi meccanismi e guasti degli snapshot del database in quanto un database molto attivo potrebbe causare un problema di spazio su disco a causa dei file sparsi utilizzati. Dai un'occhiata alle risorse TechNet sul servizio SQL Writer qui e ai backup VSS di SQL Server qui .

Per fare ciò tramite Windows Server Backup seguirai i passaggi della procedura guidata per un backup manuale assicurandoti di selezionare il backup della copia VSS nelle impostazioni di configurazione personalizzate in Impostazioni VSS. Ciò consentirà al backup di Windows Server di non interferire con qualsiasi altro backup eseguito sul server. Consultare il riferimento di Windows Server Backup per i dettagli.

Voterò la risposta di @Kin perché era la prima che corrispondeva a ciò che la domanda poneva. Ho finito per trovare una risposta aggiuntiva e la descriverò di seguito.

Per i clienti che utilizzano un modello di recupero semplice, avrò bisogno di una copia di MDF e LDF estratti da un'istantanea del disco temporanea presa a T0 a livello di hypervisor o SAN. Posso usarli per recuperare i dbs allo stato da T0.

Per i clienti che utilizzano il modello di recupero completo richiederò:

• Copie dal processo di backup PRINCIPALE dell'ultimo backup completo completato prima di T0 + catena minima di successivi backup del registro delle transazioni che coprono T0. Posso quindi eseguire un ripristino temporizzato in T0.

• Accesso per eseguire i miei COPY_ONLYbackup ausiliari . Li inizierò tutti in parallelo a T0, che non dovrebbe richiedere più di qualche secondo ed è stata la mia principale preoccupazione n. 1. Quindi, al ripristino, eseguirò un ripristino temporizzato su FirstLSN da ciascun backup. Il bello di questo è che non mi impone di interagire affatto con il processo di backup PRINCIPALE, che era l'altra mia preoccupazione, possono persino troncare i registri mentre i miei COPY_ONLYbackup sono in esecuzione senza comprometterne la coerenza.

Lo faccio più volte all'anno per il controllo qualità e altri ambienti che sono copie della produzione. Per i ripristini, la modalità di ripristino completo è davvero necessaria e il ripristino a un certo punto funziona bene. Esistono anche molte repliche ed è raro che siano presenti errori di "riga non trovata" dopo il ripristino in un determinato momento. Utilizziamo anche il metodo SAN clone / snapshot per una copia di produzione geograficamente distante e che funziona bene anche per la sincronizzazione dei database.