Servizio di backup e DR per Microsoft SQL Server

Acquisisci i dati di SQL Server

Il servizio di backup e RE consente di acquisire i seguenti tipi di applicazioni Microsoft SQL Server:

  • Istanze

  • Database nei gruppi di disponibilità AlwaysOn

  • Gruppi di coerenza dei database

  • Database individuali

  • Database di sistema

  • Database utente

  • Database nelle VM

Il backup e RE dei dati di Microsoft SQL Server vengono spostati e gestiti distintamente da dove Microsoft SQL Server scrive lo spazio di archiviazione principale.

Un'appliance di backup/ripristino archivia i dati dell'applicazione su un disco di staging. Gli snapshot sul disco di staging consentono all'appliance di backup/ripristino di mantenere i dati storici.

Prepararsi a eseguire il backup dei dati di Microsoft SQL Server

La preparazione del backup dei dati di Microsoft SQL Server prevede quattro passaggi:

  1. Aggiungi i server che ospitano i database Microsoft SQL Server.

  2. Scopri le VM e i database Microsoft SQL Server.

  3. Definisci i modelli di criteri di backup e RE e i profili delle risorse in base ai tuoi RPOs e RTOs.

    I database che utilizzano il modello di recupero completo di Microsoft SQL Server possono acquisire sia il database sia i relativi log. Pertanto, un database acquisito può essere recuperato fino a un determinato punto nel tempo eseguendo il roll forward dei relativi log.

  4. Assegna modelli di criteri di backup e RE e profili delle risorse ai database Microsoft SQL Server.

Acquisizione dati

Quando acquisisci i dati, tieni presente quanto segue:

  • Un disco di staging viene creato e montato automaticamente su un server.

  • Viene eseguita una copia completa iniziale sul disco di staging. Le copie successive sono costituite solo da blocchi modificati.

  • Il disco di staging non è montato sul server.

  • Viene creato uno snapshot del disco di staging sull'appliance di backup/ripristino.

Acquisisci i log del database SQL Server

L'acquisizione dei log del database è impostata in Dettagli e impostazioni di un criterio di snapshot. Consente a un singolo criterio di snapshot di acquisire i log per i database Microsoft SQL Server e per i gruppi di coerenza che contengono database Microsoft SQL Server.

La frequenza con cui vengono acquisiti i log del database è definita separatamente da quella del database. Ad esempio, un database può essere acquisito ogni giorno e i relativi log ogni ora.

La frequenza del backup dei log del database è impostata in minuti e la frequenza con cui vengono acquisiti i log non deve superare quella con cui viene acquisito il database associato. Ad esempio, se la frequenza di acquisizione di un database è ogni 24 ore, la frequenza di acquisizione dei file di log deve essere uguale o inferiore a ogni 24 ore.

La conservazione dei log viene definita anche separatamente dal database associato. Avere periodi di conservazione distinti ti consente di mantenere informazioni sui log sufficienti per coprire tutte le versioni di snapshot e OnVault di un database. Ad esempio, se i dati dello snapshot di un database vengono conservati per tre giorni e i dati di OnVault per sette giorni, puoi definire la conservazione dei log per tutti i sette giorni. In questo esempio, è possibile selezionare una singola immagine del database acquisita e i relativi log possono essere sottoposti a roll forward per l'intero periodo.

I log del database vengono sottoposti a staging su un singolo disco di staging nel pool di snapshot di Backup e RE. Per risparmiare spazio nel pool di snapshot, puoi utilizzare un'impostazione avanzata per indicare al database di comprimere i log.

Puoi specificare di replicare i log delle transazioni del database Microsoft SQL Server in un'appliance di backup/recupero remoto. Puoi utilizzare i log sul sito remoto per qualsiasi immagine del database nell'intervallo di conservazione dei log replicati.

Ridimensiona il disco di staging del log del database

Lo spazio fisico necessario per i backup dei log di un database viene gestito automaticamente da Backup e RE. Si tratta di un disco di staging dei log separato dallo spazio di archiviazione gestito dal server di origine. Come minimo, Backup e RE valuta le dimensioni tipiche dei log e il relativo periodo di conservazione e utilizza un disco più grande, se necessario.

Per gestire in modo più efficiente ed efficace i requisiti di archiviazione per i log di un database, i criteri di snapshot forniscono le seguenti impostazioni avanzate:

  • Periodo di conservazione dei backup dei log: la conservazione dei log viene definita separatamente dal database associato. Avere tassi di fidelizzazione separati ti consente di mantenere informazioni sui log sufficienti per coprire tutte le versioni di istantanee di un database. Il periodo di conservazione dei log è un'impostazione obbligatoria.

  • Log Staging Disk Size Growth: definisce la percentuale in base alla quale deve essere incrementato automaticamente il disco di staging su cui si trovano i log.

  • Tasso di variazione stimato: definisce la variazione giornaliera (in percentuale), che consente all'appliance di backup/recupero di calcolare meglio le dimensioni del disco di staging necessario per contenere i log.

  • Comprimi il backup dei log del database: indica al database di origine di comprimere i log prima dell'acquisizione nell'appliance di backup/recupero. Il server del database esegue la compressione dei log durante il backup dei log (il valore predefinito è Attivata).

Opzioni di acquisizione dei dati di SQL Server

Le sezioni seguenti illustrano le opzioni di acquisizione dei dati di SQL Server.

Acquisisci istanze, singoli database e gruppi di database

L'agente di backup e RE viene utilizzato per acquisire istanze, database utente, database di sistema e gruppi di database su server fisici e virtuali.

Quando acquisisci un'istanza SQL Server, hai la possibilità di acquisire l'intera istanza o database selezionati al suo interno. Quando proteggi l'intera istanza, i database vengono aggiunti all'istanza e inclusi automaticamente nel successivo job di acquisizione di backup e RE. I database di un'istanza vengono messi in stato di riposo e acquisiti insieme a un singolo piano di backup.

Se nel criterio del piano di backup sono attivati il database e l'acquisizione dei log di Backup e RE, tutti i database dell'istanza possono essere recuperati nello stesso istante. Il recupero e il rolling forward dei log per tutti o singoli database di un'istanza vengono eseguiti dall'interfaccia utente di Backup e RE con una singola azione.

È possibile accedere ai singoli membri di un'istanza tramite le operazioni di montaggio, clonazione, LiveClone e ripristino, in base alle esigenze.

Gruppi di coerenza di Capture

Un gruppo di coerenza è un gruppo di database messi in stato di riposo e acquisiti insieme a un singolo modello di criteri del piano di backup e a un profilo di risorse. L'appartenenza a un gruppo di coerenza viene assegnata manualmente ed è adatta a gruppi di database i cui membri non cambiano molto spesso. Per proteggere automaticamente i nuovi membri di un gruppo di database, crea e proteggi questi database in un'istanza SQL Server.

Come suggerisce il nome, i gruppi di coerenza assicurano il recupero e l'acquisizione point-in-time in modo coerente su più database. Se la tecnologia di acquisizione di log e database di Backup e RE è attivata nel criterio del piano di backup, tutti i database di quel gruppo possono essere recuperati nello stesso istante. Il recupero e il rollforward dei log per tutti o singoli database in un gruppo di coerenza vengono eseguiti dall'interfaccia utente di Backup e RE con una singola azione. I membri di un gruppo con coerenza devono trovarsi nella stessa istanza.

Un gruppo di coerenza può essere composto da:

  • Uno o più database di sistema

  • Uno o più database utente

  • Database di sistema o utente insieme

  • Zero o più file system (lettere di unità o punti di montaggio)

I singoli membri di un gruppo di coerenza sono accessibili tramite le operazioni di montaggio, clonazione, LiveClone e ripristino.

I database in un'istanza di failover in cluster devono essere rilevati dal node attivo. Una volta protetto, GO segue il nodo SQL attivo in un cluster. I job di protezione continuano a essere eseguiti anche in caso di failover. Oltre a velocizzare le operazioni di acquisizione e accesso, i gruppi di coerenza consumano meno risorse di sistema (VDisk) rispetto alla protezione dei database singolarmente.

Puoi convalidare l'integrità del backup del database periodicamente montando un'immagine di backup su un server ed eseguendo il controllo della coerenza del database. Puoi utilizzare la funzionalità di flusso di lavoro per automatizzare il processo di convalida.

Acquisisci i database e il volume di avvio di una VM

Quando acquisisci i database sulle VM, hai la possibilità di acquisire anche il volume di avvio della VM. Quando il volume di avvio di una VM viene acquisito insieme ai relativi database, è possibile presentare un'immagine che sia un database e una VM completamente funzionanti. L'immagine può quindi essere migrata in una nuova posizione permanente.

Replicare i dati di SQL Server

I dati possono essere replicati in una seconda appliance di backup/ripristino o nel cloud per scopi di recupero, ripristino di emergenza, test o sviluppo. La replica dei dati è stata per molto tempo un fattore che ha impedito una gestione efficiente dei dati in un ambiente geograficamente distribuito. La replica di backup e RE risolve questi problemi con la compressione che:

  • Riduci l'utilizzo complessivo della rete.

  • Elimina la necessità di un acceleratore o di un ottimizzatore WAN dedicato.

  • Crittografa i dati utilizzando lo standard di crittografia AES-256. L'autenticazione tra le appliance di backup/recupero viene eseguita utilizzando certificati a 1024 bit.

La replica è controllata dai criteri dei modelli di criteri di backup e RE:

  • I criteri Produzione a mirroring offrono diverse opzioni per replicare i dati su una seconda appliance di backup/ripristino.

  • I criteri Produzione su OnVault utilizzano un motore proprietario di backup e RE per trasferire i dati nello spazio di archiviazione oggetti.

Replicare i log

Quando l'opzione Attiva il backup dei log del database di un criterio è impostata su Attiva, l'impostazione avanzata Replica i log consente di replicare i log delle transazioni del database Microsoft SQL Server in un'appliance di backup/recupero remoto. Affinché un job di replica dei log venga eseguito, nel modello deve essere incluso un criterio di replica di StreamSnap insieme a un profilo della risorsa che specifichi un appliance di backup/recupero remoto e deve essere completata almeno una replica riuscita del database. Puoi quindi utilizzare i log sul sito remoto per qualsiasi immagine del database nell'intervallo di conservazione dei log replicati. Questa funzione è attiva per impostazione predefinita.

La replica dei log utilizza la tecnologia StreamSnap per eseguire la replica tra le appliance di backup/ripristino locale e remota. La replica dei log avviene direttamente dal pool di snapshot locale al pool di snapshot sull'appliance remota.

I log possono essere replicati anche in un pool OnVault. Se abilitato (non predefinito), i log vengono inviati a ogni pool OnVault specificato da una combinazione valida di criteri o profili di risorse OnVault (ad es. Pool OnVault 1 selezionato nel criterio e pool OnVault 1 specificato nel profilo della risorsa). La conservazione dei log nel pool OnVault corrisponde sempre alla conservazione dei log nel pool di snapshot.

Accedere ai dati di SQL Server

Per i database Microsoft SQL Server che utilizzano il modello di recupero completo, il backup e il RE possono presentare immediatamente una copia del database sottoposto a esecuzione di rollforward fino a un determinato momento. L'operazione di applicazione delle modifiche è specificata nella console di gestione.

Per i database Microsoft SQL Server che utilizzano il modello di recupero di base, il backup e il RE possono presentare immediatamente qualsiasi backup del database che non ha superato il periodo di conservazione.

Indipendentemente dal modello di recupero di Microsoft SQL Server utilizzato, è possibile accedere ai dati di Microsoft SQL Server utilizzando l'interfaccia iSCSI. Se utilizzi VMware (GCVE), puoi accedere ai dati anche utilizzando un archivio dati NFS presentato all'host ESXi.

Controllo dell'accesso basato sui ruoli

Puoi controllare quali utenti hanno accesso ai dati, alle funzionalità di backup e RE e alle risorse. I dati acquisiti possono essere contrassegnati come sensibili e agli utenti di backup e RE può essere concessa l'autorizzazione di accesso ai dati sensibili.

Supporti

La funzione di montaggio di Backup e RE consente di accedere istantaneamente ai dati senza spostarli. Le copie acquisite dei database possono essere sottoposte a roll forward utilizzando l'interfaccia utente di Backup e RE e montate su qualsiasi server di database. Backup e RE offrono due modi per montare un database Microsoft SQL Server:

  • Il mount dell'applicazione virtuale presenta e rende disponibili i dati acquisiti di Microsoft SQL Server per un server di destinazione come database Microsoft SQL Server. In questo modo puoi creare e gestire copie dei database di produzione per uso non di produzione. I montaggi delle applicazioni virtuali vengono creati dall'appliance di backup/recupero e non richiedono l'intervento manuale da parte di amministratori di database, server o archiviazione. I montaggi di applicazioni virtuali possono essere utilizzati per report, analisi, test di integrità e test e sviluppo del database. I database virtuali sono descritti in dettaglio in Montare un database SQL Server come nuovo database virtuale e Montare i database nei gruppi di disponibilità SQL AlwaysOn.

  • Il mount standard, chiamato anche mount diretto, presenta e rende disponibili i dati di Microsoft SQL Server acquisiti per un server di destinazione come file system, non come database. Questa operazione è utile se un database è danneggiato, se è stato perso o se un server di database viene sostituito. In questi casi, non puoi utilizzare un'operazione di ripristino per recuperare il database. In alternativa, puoi montare un'immagine e copiare i file del database dall'immagine montata alla posizione originale sul server del database. Le mount dirette sono descritte in dettaglio in Montare i dati Microsoft SQL acquisiti.

LiveClones

Un LiveClone è una copia indipendente dei dati di Microsoft SQL Server che può essere aggiornata e mascherata prima di essere resa disponibile agli utenti. In questo modo, i team di sviluppo e test possono lavorare sull'ultimo insieme di dati senza doverli gestire manualmente o interferire con l'ambiente di produzione.

Clones

La funzione clone sposta una copia dei dati di produzione in una posizione diversa rispetto all'origine. Il tempo necessario per completare un'operazione di clonazione dipende dalla quantità di dati coinvolti. Le informazioni dettagliate sulle cloni sono disponibili in Clonare i database SQL Server.

Ripristini

Un ripristino ripristina i dati di produzione a un punto in tempo specificato. Le operazioni di recupero muovono effettivamente i dati. Le operazioni di ripristino vengono in genere eseguite dopo un grave danneggiamento dei dati. Il tempo necessario per completare un'operazione di ripristino dipende dalla quantità di dati coinvolti.

Per ripristinare un database e applicare i log, il database ripristinato deve essere in modalità di ripristino. Puoi ripristinare il database in Modalità di ripristino e poi eseguire il roll forward dei log fino a un punto temporale specifico. Se ripristini il database senza specificare Ripristina senza recupero, il database verrà ripristinato e messo online senza applicare i log. I dettagli sui ripristini sono disponibili in Ripristinare i database SQL Server. Per un ripristino con tempi di riposo quasi nulli, monta prima i dati come descritto in Montare e migrare i dati SQL.

Workflows per automatizzare l'accesso ai dati di SQL Server

Workflows automatizzano l'accesso ai dati di Microsoft SQL Server acquisiti. Workflows possono presentare i dati come montaggio diretto o come LiveClone:

  • I montaggi diretti (standard o basati sulle applicazioni) sono adatti per i dati di Microsoft SQL Server che non devono essere mascherati prima di essere presentati. Una copia montata dei dati può essere aggiornata manualmente o automaticamente in base a una pianificazione. I mount diretti ti consentono di accedere immediatamente ai dati di Microsoft SQL Server acquisiti senza spostarli.

  • Un LiveClone è una copia dei dati di produzione di Microsoft SQL Server che può essere aggiornata manualmente o in base a una pianificazione. Puoi mascherare i dati sensibili in un LiveClone prima di renderli disponibili per gli utenti.

La combinazione della cattura automatica dei dati di Microsoft SQL Server e controllo dell'accesso dell'accesso di Backup e RE con i flussi di lavoro e le relative funzionalità di mascheramento dei dati facoltative consente di creare ambienti di self-provisioning. Gli utenti possono eseguire il provisioning dei propri ambienti quasi istantaneamente.

Ad esempio, un amministratore di Backup e RE può creare un criterio del modello di backup che acquisisce i dati di Microsoft SQL Server in base a una pianificazione specificata. L'amministratore può contrassegnare i dati di produzione di Microsoft SQL Server acquisiti come sensibili e accessibili solo agli utenti con i diritti di accesso appropriati.

Dopo aver definito i diritti di accesso e acquisito i dati, l'amministratore può creare un flusso di lavoro che:

  • Rende disponibili i dati di Microsoft SQL Server acquisiti come LiveClone o come montaggio diretto.

  • Aggiorna i dati di LiveClone o di Microsoft SQL Server montabili su base programmata o on demand

  • Se vuoi, puoi applicare automaticamente gli script ai dati di Microsoft SQL Server di LiveClone dopo ogni aggiornamento. Questa funzionalità è utile per mascherare i dati sensibili di Microsoft SQL Server.

Al termine del flusso di lavoro, gli utenti con accesso appropriato possono eseguire il provisioning dei propri ambienti con i dati di LiveClone o Microsoft SQL Server montabili.

Backup e RE che funzionano con i prodotti di backup esistenti

Poiché sempre più aziende cercano di accelerare lo sviluppo delle applicazioni utilizzando i database di produzione, spesso è necessario che il backup e la RE coesistano con i prodotti di backup precedenti che funzionano negli stessi ambienti di database di produzione. Il backup e RE possono coesistere perfettamente con altri prodotti che acquisiscono i dati dai database di produzione, se vengono seguite queste best practice.

Backup e RE hanno un metodo proprietario di monitoraggio dei blocchi di modifica, pertanto le soluzioni di backup che utilizzano SQL o altri metodi per ottenere i backup non sono interessate da job di acquisizione dei dati di backup e RE pianificati.

I job di backup possono richiedere un'I/O molto elevata. Potrebbero avere durate lunghe e influire sulle prestazioni del database durante le finestre di backup. Il backup e il RE riducono al minimo l'impatto durante i job, ma anche un update incrementale a livello di blocco deve generare un po' di I/O e deve richiedere un po' di tempo.

Requisito Non pianificare l'esecuzione di job da parte del software di backup precedente e di Backup e RE in modo da sovrapporre le esecuzioni nel tempo.
Best practice Pianifica l'avvio dei job di database di Backup e RE in un momento in cui il software di backup precedente dovrebbe essere terminato. Non pianificare l'esecuzione del software di backup precedente immediatamente dopo il completamento normale di un job di Backup e RE.
Motivo Se i job di backup legacy e i job di backup e RE vengono eseguiti contemporaneamente, potrebbe verificarsi un grave impatto sulle prestazioni del server di database, con conseguente instabilità e persino un interruzione del servizio.

I log del database vengono utilizzati per acquisire singole transazioni in un database, consentendo i ripristini in un determinato momento. La maggior parte dei casi d'uso dell'agilità si basa sull'ottenimento di istantanee del database in modo periodico dalla produzione. La frequenza più comune va da giornaliera a settimanale o una volta ogni due settimane, a seconda del caso d'uso. Di conseguenza, in genere gli sviluppatori di applicazioni non hanno bisogno di posizionare la propria istanza non di produzione in un momento specifico rispetto all'origine (produzione). In genere, non è più necessario acquisire e gestire i log come parte di una soluzione di agilità di backup e RE.

Requisito Solo un sistema può gestire (acquisire o troncare (ripulire)) i log, il software di backup precedente o Backup e RE.
Best practice Continua a consentire che tutta la gestione dei log venga eseguita dal software di backup precedente. Non utilizzare il backup e la RE per proteggere i log in questo ambiente.
Motivo Se il sistema è configurato per gestire (acquisire o troncare(ripulire)) i log e anche il software di backup precedente acquisisce e/o tronca/ripulisce i log, uno o entrambi i sistemi potrebbero avere una catena di log incompleta, il che rende difficile o impossibile recuperare il database a un punto in tempo specifico.

Passaggi successivi

Prepara i database SQL Server per il servizio di backup e RE.

Altra documentazione per il backup e il RE per Microsoft SQL Server

Questa pagina fa parte di una serie di pagine specifiche per la protezione e il recupero di database, file di supporto e file binari di Microsoft SQL Server con backup e RE.

Puoi trovare ulteriori informazioni qui: