Backup and RE per Microsoft SQL Server su un'appliance di backup/recupero

Acquisisci i dati di SQL Server

Backup e RE consente di acquisire i seguenti tipi di applicazioni Microsoft SQL Server:

  • Istanze

  • Database nei gruppi di disponibilità Always On

  • Gruppi di coerenza dei database

  • Database individuali

  • Database di sistema

  • Database utente

  • Database nelle VM

Backup e RE sposta e gestisce i dati di Microsoft SQL Server separatamente dal punto in cui Microsoft SQL Server scrive lo spazio di archiviazione principale.

Un'appliance di backup/ripristino archivia i dati delle applicazioni su un disco di gestione temporanea. Gli snapshot sul disco di gestione temporanea 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 policy 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 sia i relativi log. Pertanto, un database acquisito può essere recuperato in un momento specifico eseguendo il roll forward dei log.

  4. Assegna i modelli di policy e i profili delle risorse di Backup e RE 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 eseguita una copia completa iniziale sul disco di gestione temporanea. Le copie successive sono costituite solo dai blocchi modificati.

  • Il disco di staging viene smontato dal server.

  • Sull'appliance di backup/ripristino viene creato uno snapshot del disco di gestione temporanea.

Acquisisci i log del database SQL Server

L'acquisizione dei log del database è impostata in Dettagli e impostazioni di una policy di snapshot. Consente a una singola 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 viene 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 pari o inferiore a ogni 24 ore.

Anche la conservazione dei log viene definita separatamente dal database associato. La presenza di periodi di conservazione separati consente di mantenere informazioni di log sufficienti per coprire tutte le versioni di snapshot e OnVault di un database. Ad esempio, se i dati degli 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 un singolo database acquisito e i relativi log possono essere applicati in avanti per l'intero periodo.

I log del database vengono inseriti in un unico disco di gestione temporanea 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/recovery remota. Puoi utilizzare i log nel sito remoto per qualsiasi database compreso nell'intervallo di conservazione dei log replicati.

Ridimensiona il disco di gestione temporanea del log del database

Lo spazio fisico necessario per ospitare i backup dei log di un database viene gestito automaticamente da Backup e RE. Si tratta di un disco di gestione temporanea 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 dei log di un database, le policy degli snapshot forniscono le seguenti impostazioni avanzate:

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

  • Crescita delle dimensioni del disco di gestione temporanea dei log: definisce la percentuale di aumento automatico del disco di gestione temporanea su cui risiedono i log.

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

  • Comprimi backup log database: indica al database di origine di comprimere i log prima dell'acquisizione nell'appliance di backup/ripristino. Il server di database esegue la compressione dei log durante il backup dei log (l'impostazione predefinita è 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, puoi scegliere di 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 job di acquisizione di Backup e RE successivo. I database in un'istanza vengono messi in pausa e acquisiti insieme a un unico piano di backup.

Se l'acquisizione dei log e del database di Backup e RE è abilitata nella policy del piano di backup, tutti i database nell'istanza possono essere recuperati allo stesso momento. Il recupero e il roll forward dei log per tutti i database o per singoli database di un'istanza vengono eseguiti dall'interfaccia utente di Backup e RE con un'unica azione.

I singoli membri di un'istanza sono accessibili tramite operazioni di montaggio, clonazione, LiveClone e ripristino, a seconda delle esigenze.

Acquisisci gruppi di coerenza

Un gruppo di coerenza è un gruppo di database che vengono messi in pausa e acquisiti insieme con un unico modello di policy del piano di backup e un unico profilo delle risorse. L'appartenenza a un gruppo di coerenza viene assegnata manualmente ed è adatta ai gruppi di database i cui membri non cambiano molto spesso. Per proteggere automaticamente i nuovi membri di un gruppo di database, crea e proteggi i database in un'istanza SQL Server.

Come suggerisce il nome, i gruppi di coerenza garantiscono l'acquisizione e il recupero point-in-time coerenti su più database. Se la tecnologia di acquisizione dei log e del database di Backup e RE è abilitata nella policy del piano di backup, tutti i database di quel gruppo possono essere recuperati nello stesso momento. 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 e RE con un'unica 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)

I singoli membri di un gruppo di coerenza sono accessibili 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 una condizione 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 periodicamente l'integrità del backup del database montando un backup su un server ed eseguendo il controllo di coerenza del database. Puoi utilizzare la funzionalità del workflow 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 backup che sia un database e una VM completamente funzionali. Il backup può quindi essere migrato in una nuova posizione permanente.

Replica i dati di SQL Server

I dati possono essere replicati in una seconda appliance di backup/recovery o nel cloud per il recovery, 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 con una compressione che:

  • Riduce l'utilizzo complessivo della rete.

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

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

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

  • Le policy Da produzione a mirror offrono diverse opzioni per replicare i dati in una seconda appliance di backup/ripristino.

  • Le policy Da produzione a OnVault utilizzano un motore proprietario di Backup e RE per trasferire i dati nell'archivio di oggetti.

Replica i log

Quando l'opzione Abilita backup dei log del database di una policy è impostata su Abilita, l'impostazione avanzata Replica log consente di replicare i log delle transazioni del database Microsoft SQL Server in un'appliance di backup/recovery remota. Per l'esecuzione di un job di replica dei log, nel template deve essere inclusa una policy di replica StreamSnap insieme a un profilo delle risorse che specifica un'appliance di backup/recovery remota e deve essere completata almeno una replica del database. Puoi quindi utilizzare i log nel sito remoto per qualsiasi backup del database entro l'intervallo di conservazione dei log replicati. Questa funzione è abilitata 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 abilitata (non per impostazione predefinita), i log vengono inviati a ogni pool OnVault specificato da una combinazione valida di policy OnVault o profilo delle risorse (ad esempio, il pool OnVault uno selezionato nella policy e il pool OnVault uno specificato nel profilo delle risorse). La conservazione dei log nel pool OnVault corrisponde sempre alla conservazione dei log nel pool di snapshot.

Accedi ai dati di SQL Server

Per i database Microsoft SQL Server che utilizzano il modello di recupero completo, Backup e RE può presentare istantaneamente una copia del database con roll forward a un momento specifico. L'operazione di roll forward viene specificata nella console di gestione dell'appliance.

Per i database Microsoft SQL Server che utilizzano il modello di recupero di base, Backup e RE può presentare istantaneamente 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 datastore 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 fornisce l'accesso istantaneo ai dati senza spostarli. Le copie dei database acquisite possono essere aggiornate utilizzando l'interfaccia utente di Backup e RE e montate su qualsiasi server di database. Backup e RE offre due modi per montare un database Microsoft SQL Server:

  • Il mount 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 un utilizzo non di produzione. I montaggi di applicazioni virtuali vengono creati dall'appliance di backup/ripristino 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, i test di integrità, i test e lo sviluppo dei database. I database virtuali sono descritti in dettaglio in Monta un database SQL Server come nuovo database virtuale e Monta i database nei gruppi di disponibilità Always On di SQL.

  • 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. Questo è 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. Puoi invece montare un backup e copiare i file di database dal backup montato alla posizione originale sul server di database. I montaggi diretti sono descritti in dettaglio in Monta 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 sul set di dati più recente 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 rispetto all'origine. Il tempo necessario per completare un'operazione di clonazione dipende dalla quantità di dati coinvolti. I cloni sono descritti in dettaglio in Clona i database SQL Server.

Ripristini

Un ripristino riporta i dati di produzione a 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 interessati.

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, quindi eseguire il roll forward dei log fino a un momento specifico. Se ripristini il database senza specificare Restore with no Recovery, il database verrà ripristinato e portato online senza applicare i log. I ripristini sono descritti in dettaglio in Ripristina i 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 alle applicazioni) 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 istantaneamente ai dati Microsoft SQL Server acquisiti senza spostarli effettivamente.

  • 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 agli utenti.

La combinazione dell'acquisizione automatica dei dati di Microsoft SQL Server e controllo 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 una policy di template di backup che acquisisce i dati di Microsoft SQL Server in base a una pianificazione specificata. L'amministratore può contrassegnare i dati di produzione 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 workflow che:

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

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

  • Facoltativamente, applica automaticamente gli script ai dati di Microsoft SQL Server del 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 l'accesso appropriato possono eseguire il provisioning dei propri ambienti con i dati LiveClone o Microsoft SQL Server montabili.

Backup e RE funziona con i prodotti di backup esistenti

Poiché sempre più aziende cercano di accelerare lo sviluppo di applicazioni utilizzando 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. Backup e RE può coesistere perfettamente con altri prodotti che acquisiscono dati dai database di produzione, se vengono seguite queste best practice.

Backup e RE dispone di un metodo proprietario di Change Block Tracking, 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 e RE pianificati.

I job di backup possono richiedere un utilizzo intensivo di I/O. Potrebbero avere durate lunghe e 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 un po' di I/O e richiede un po' di tempo.

Requisito Non pianificare l'esecuzione di job del software di backup legacy e di Backup e RE in modo che si sovrappongano nel tempo.
Best practice Pianifica i job del database di Backup e RE in modo che inizino nel momento in cui il software di backup legacy dovrebbe aver 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, potrebbe verificarsi un grave impatto sulle prestazioni del server del database, con conseguente instabilità ed eventualmente un'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 di agilità si concentra sull'ottenimento periodico di snapshot del database 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 bisogno di posizionare l'istanza non di produzione in un momento specifico dall'origine (produzione). In genere, questo elimina la necessità di acquisire e gestire i log nell'ambito di una soluzione di agilità di Backup e RE.

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

Altra documentazione per Backup e RE per Microsoft SQL Server

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

Passaggi successivi

Prepara i database SQL Server per Backup e DR.