Servizio di backup e DR per Microsoft SQL Server

Acquisire dati SQL Server

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

  • Istanze

  • Database nei gruppi di disponibilità Always On

  • Gruppi con coerenza di database

  • Database individuali

  • Database di sistema

  • Database utente

  • Database nelle VM

Backup and RE sposta e gestisce i dati di Microsoft SQL Server separatamente da dove Microsoft SQL Server scrive l'archiviazione principale.

Un'appliance di backup/ripristino archivia i dati delle applicazioni su un disco di staging. Gli snapshot sul disco di staging consentono all'appliance di backup/ripristino di conservare i dati storici.

Preparati 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 RPO e RTO.

    I database che utilizzano il modello di recupero completo di Microsoft SQL Server possono acquisire sia il database che i relativi log. Pertanto, un database acquisito può essere recuperato in un momento specifico facendo avanzare i relativi log.

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

Acquisizione dati

Quando acquisisci i dati, tieni presente quanto segue:

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

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

  • Il disco di staging è smontato dal server.

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

Acquisire i log del database SQL Server

L'acquisizione dei log del database è impostata in Dettagli e impostazioni di una policy di snapshot. Consente a un'unica policy di snapshot di acquisire i log per i database Microsoft SQL Server e 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 la frequenza con cui viene acquisito il database associato. Ad esempio, se la frequenza di acquisizione del database è ogni 24 ore, la frequenza di acquisizione del file di log deve essere uguale o inferiore a ogni 24 ore.

La conservazione dei log è definita separatamente dal database associato. Avere periodi di conservazione separati ti consente di conservare informazioni dei log sufficienti a coprire tutte le versioni snapshot e OnVault di un database. Ad esempio, se i dati dello snapshot di un database vengono conservati per tre giorni e i dati OnVault per sette giorni, puoi definire la conservazione dei log in modo che copra tutti e sette i giorni. In questo esempio, è possibile selezionare una singola immagine del database acquisita e i relativi log possono essere spostati in avanti per l'intero periodo.

I log del database vengono preparati in un unico disco di staging nel pool di snapshot di Backup and 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 remota. Puoi utilizzare i log nel sito remoto per qualsiasi immagine del database all'interno dell'intervallo di conservazione dei log replicati.

Ridimensiona il disco di staging del log del database

Lo spazio fisico necessario per ospitare i backup dei log di un database viene gestito automaticamente da Backup eRER. Questo spazio è chiamato disco di staging dei log ed è separato dallo spazio di archiviazione gestito dal server di origine. Come minimo, Backup and 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, le policy degli snapshot forniscono le seguenti impostazioni avanzate:

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

  • Log Staging Disk Size Growth: definisce la percentuale in base alla quale aumentare automaticamente le dimensioni del disco di staging in cui risiedono i log.

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

  • Compress Database Log Backup: indica al database di origine di comprimere i log prima dell'acquisizione sull'appliance di backup/recupero. Il server di database esegue la compressione dei log durante il backup dei log (il valore predefinito è Attivato).

Opzioni di acquisizione dei dati di SQL Server

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

Acquisire istanze, singoli database e gruppi di database

L'agente Backup and 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, puoi acquisire l'intera istanza o i database selezionati al suo interno. Quando proteggi l'intera istanza, i database aggiunti all'istanza vengono inclusi automaticamente nel successivo job di acquisizione di Backup e RE. I database in un'istanza vengono sospesi e acquisiti insieme a un unico piano di backup.

Se l'acquisizione del database e dei log di Backup e RE è abilitata nella norma del piano di backup, tutti i database di questa istanza possono essere recuperati nello stesso momento specifico. Il recupero e il roll forward dei log per tutti i database o per singoli database in un'istanza vengono eseguiti dall'interfaccia utente di Backup e RE con una singola azione.

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

Acquisizione di gruppi con coerenza

Un gruppo di coerenza è un gruppo di database inattivi e acquisiti insieme a un singolo modello di policy del piano di backup e profilo di risorsa. 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 garantiscono l'acquisizione e il recupero point-in-time coerenti in più database. Se la tecnologia di acquisizione di database e log di Backup and RE è abilitata nella policy del piano di backup, tutti i database del gruppo possono essere recuperati nello stesso momento specifico. Il recupero e il roll forward dei log per tutti i database o per singoli database in un gruppo di coerenza vengono eseguiti dall'interfaccia utente di Backup anREDR con una singola azione. I membri di un gruppo di coerenza devono risiedere 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)

È possibile accedere ai singoli membri di un gruppo di coerenza tramite operazioni di montaggio, clonazione, LiveClone e ripristino.

I database in un'istanza di failover in cluster devono essere rilevati dal nodo 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 rendere veloci le operazioni di acquisizione e accesso, i gruppi di coerenza consumano meno risorse di sistema (VDisk) rispetto alla protezione dei database individuali.

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

Acquisire i database e il volume di avvio di una VM

Quando acquisisci 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 una VM e un database completamente funzionali. L'immagine può quindi essere migrata in una nuova posizione permanente.

Replica i dati di SQL Server

I dati possono essere replicati in una seconda appliance di backup/recupero o nel cloud per il recupero, il ripristino di emergenza o per scopi di test o sviluppo. La replica dei dati è da tempo un ostacolo alla gestione efficiente dei dati in un ambiente distribuito geograficamente. La replica di Backup e RE risolve questi problemi di compressione:

  • Riduce l'utilizzo complessivo della rete.

  • Elimina la necessità di un acceleratore o di uno strumento di ottimizzazione WAN dedicato.

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

La replica è controllata dalle policy dei modelli di policy di Backup e RE:

  • Le norme Production to Mirror offrono diverse opzioni per replicare i dati in una seconda appliance di backup/ripristino.

  • I criteri Production to OnVault utilizzano un motore proprietario di Backup and RE per trasferire i dati all'archiviazione a oggetti.

Replica dei log

Quando l'opzione Attiva backup log database di una policy è impostata su Attiva, l'impostazione avanzata Replica log consente di replicare i log delle transazioni del database Microsoft SQL Server in un'appliance di backup/recupero remota. Per l'esecuzione di un job di replica dei log, nel modello deve essere inclusa una norma di replica StreamSnap insieme a un profilo risorsa che specifica un'appliance di backup/recupero remota e deve essere completata almeno una replica riuscita del database. Puoi quindi utilizzare i log nel sito remoto per qualsiasi immagine del database all'interno dell'intervallo di conservazione dei log replicati. Questa funzione è attivata per impostazione predefinita.

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

I log possono anche essere replicati in un pool OnVault. Se abilitato (non predefinito), i log vengono inviati a ogni pool OnVault specificato da una combinazione valida di criteri OnVault o profilo risorsa (ad es. Pool OnVault uno selezionato nelle norme e pool OnVault uno 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, Backup and RE può presentare immediatamente una copia del database eseguita in roll forward fino a un momento specifico. L'operazione di roll forward è specificata nella console di gestione.

Per i database Microsoft SQL Server che utilizzano il modello di recupero di base, Backup e 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), è possibile accedere ai dati anche utilizzando un datastore NFS presentato all'host ESXi.

Controllo dell'accesso basato sui ruoli

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

Supporti

La funzione di montaggio di Backup e RE fornisce l'accesso immediato ai dati senza spostarli. Le copie acquisite dei database possono essere ripristinate utilizzando l'interfaccia utente di Backup andRER e montate su qualsiasi server di database. Backup e RE offre due modi per montare un database Microsoft SQL Server:

  • Il montaggio dell'applicazione virtuale presenta e rende disponibili i dati Microsoft SQL Server acquisiti a un server di destinazione come database Microsoft SQL Server. In questo modo puoi creare e gestire copie dei database di produzione per l'utilizzo non di produzione. I montaggi delle applicazioni virtuali vengono creati dall'appliance di backup/recupero e non richiedono l'intervento manuale degli amministratori di database, server o spazio di archiviazione. I montaggi di applicazioni virtuali possono essere utilizzati per la generazione di report, l'analisi, il test di integrità e il test e lo sviluppo di database. I database virtuali sono descritti in Montare un database SQL Server come nuovo database virtuale e Montare i database nei gruppi di disponibilità SQL Always On.

  • Il montaggio standard, chiamato anche montaggio diretto, presenta e rende disponibili i dati Microsoft SQL Server acquisiti a un server di destinazione come file system, non come database. Questa operazione è utile se un database è danneggiato, 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 di database dall'immagine montata nella loro posizione originale sul server di database. I montaggi diretti sono descritti 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 set di dati senza dover gestire manualmente i dati o interferire con l'ambiente di produzione.

Clones

La funzione di clonazione sposta una copia dei dati di produzione in una posizione diversa dall'origine. Il tempo necessario per completare un'operazione di clonazione dipende dalla quantità di dati coinvolti. I cloni sono descritti in dettaglio in Clonare i database SQL Server.

Ripristini

Un ripristino ripristina i dati di produzione in un momento specifico. Le operazioni di ripristino spostano effettivamente i dati. Le operazioni di ripristino vengono in genere eseguite dopo un danneggiamento massiccio dei dati. Il tempo necessario per completare un'operazione di ripristino dipende dalla quantità di dati coinvolti.

Per ripristinare un database e poi applicare i log, il database ripristinato deve essere in modalità di ripristino. Puoi ripristinare il database in modalità di ripristino e poi avanzare i log fino a un momento specifico. Se ripristini il database senza specificare Ripristina senza recupero, il database verrà ripristinato e portato online senza applicare i log. I ripristini sono descritti in dettaglio in Ripristina database SQL Server. Per un ripristino con tempi di inattività quasi nulli, monta prima i dati come descritto in Monta ed esegui la migrazione dei dati SQL.

Workflows per automatizzare l'accesso ai dati di SQL Server

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

  • I montaggi diretti (standard o sensibili all'applicazione) funzionano bene 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 montaggi diretti ti consentono di accedere immediatamente ai dati 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 renderlo disponibile agli utenti.

La combinazione dell'acquisizione automatica dei dati di Microsoft SQL Server e controllo dell'accesso dell'accesso di Backup and RE con i workflow e le relative funzionalità di mascheramento dei dati facoltative consente di creare ambienti di provisioning autonomo. 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 Microsoft SQL Server acquisiti come LiveClone o come montaggio diretto.

  • Aggiorna i dati LiveClone o montabili di Microsoft SQL Server in base a una pianificazione o su richiesta

  • (Facoltativo) Applica 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.

Una volta completato il flusso di lavoro, gli utenti con accesso adeguato possono eseguire il provisioning dei propri ambienti con i dati LiveClone o Microsoft SQL Server montabili.

Backup e RE che funziona con i prodotti di backup esistenti

Man mano che sempre più aziende cercano di accelerare lo sviluppo di applicazioni utilizzando i database di produzione, spesso è necessario che Backup e RE coesista con i prodotti di backup legacy che operano negli stessi ambienti di database di produzione. Il backup e RE possono coesistere perfettamente con altri prodotti che acquisiscono dati dai database di produzione, se vengono seguite queste best practice.

Backup and RE ha un metodo proprietario di monitoraggio dei blocchi modificati, pertanto le soluzioni di backup che utilizzano SQL o altri metodi per ottenere i backup non sono interessate dai job di acquisizione dei dati di Backup and RE pianificati.

I job di backup possono richiedere un utilizzo intensivo di I/O. Potrebbero avere una lunga durata e potrebbero influire sulle prestazioni del database durante le finestre di backup. Backup e RE riduce al minimo l'impatto durante i job, ma anche un aggiornamento incrementale permanente a livello di blocco deve generare alcune operazioni di I/O e richiedere un po' di tempo.

Requisito Non pianificare l'esecuzione di job per il software di backup legacy e Backup e RE in modo da consentire qualsiasi sovrapposizione nel tempo.
Best practice Pianifica l'inizio dei job di backup e RE del database in un momento in cui il software di backup legacy dovrebbe essere terminato. Non pianificare l'esecuzione del software di backup legacy immediatamente dopo il completamento di un job di Backup e RE.
Motivo Se i job di backup legacy e i job di Backup e RE vengono eseguiti contemporaneamente, potrebbero verificarsi gravi problemi di prestazioni sul server di database, con conseguente instabilità e possibile interruzione del servizio.

I log del database vengono utilizzati per acquisire singole transazioni in un database, consentendo i recuperi point-in-time. La maggior parte dei casi d'uso dell'agilità riguarda l'ottenimento di snapshot del database su base periodica dalla produzione. La frequenza comune varia da giornaliera a settimanale o una volta ogni due settimane, a seconda del caso d'uso. Di conseguenza, gli sviluppatori di applicazioni in genere non hanno la necessità di posizionare la propria istanza non di produzione in un momento specifico dell'origine (produzione). In genere, in questo modo non è più necessario acquisire e gestire i log nell'ambito di una soluzione di Backup eRER agile.

Requisito Solo un sistema può gestire (acquisire o troncare (eliminare)) i log, ovvero il software di backup legacy o Backup REDR.
Best practice Continua a consentire la gestione di tutti i log da parte del software di backup legacy, non utilizzare Backup and RE per proteggere i log in questo ambiente.
Motivo Se il sistema è configurato per gestire (acquisire o troncare/eliminare) i log e il software di backup legacy acquisisce e/o tronca/elimina anche i log, uno o entrambi i sistemi potrebbero ritrovarsi con una catena di log incompleta, rendendo difficile o impossibile recuperare il database in un momento specifico.

Altra documentazione per Backup and RE per Microsoft SQL Server

Questa pagina fa parte di una serie di pagine specifiche per la protezione e il recupero di database Microsoft SQL Server con Backup and RE. Puoi trovare ulteriori informazioni all'indirizzo:

Passaggi successivi

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