Eseguire il backup dei gruppi di disponibilità AlwaysOn di SQL Server

Backup di Azure offre un supporto end-to-end per il backup di gruppi di disponibilità Always On di SQL Server se tutti i nodi si trovano nella stessa area e nella stessa sottoscrizione dell'insieme di credenziali di Servizi di ripristino. Tuttavia, se i nodi AG sono distribuiti tra aree, sottoscrizioni, locali e Azure, occorre prendere in considerazione alcune considerazioni.

Per visualizzare gli scenari di backup e ripristino attualmente supportati, vedere la matrice di supporto. Per domande comuni, vedere le domande frequenti.

La preferenza di backup utilizzata da Azure Backup SQL AG supporta solo backup completi e differenziali dalla replica primaria. Quindi, questi processi di backup vengono sempre eseguiti nel nodo Primario indipendentemente dalla preferenza di backup. Per i backup completi di sola copia e dei log delle transazioni, la preferenza di backup del gruppo di disponibilità è determinante nella scelta del nodo in cui verrà eseguito il backup stesso.

L'estensione di backup del carico di lavoro viene installata nel nodo quando viene registrata con il servizio Backup di Azure. Quando un database del gruppo di disponibilità è configurato per il backup, le pianificazioni di backup vengono inviate a tutti i nodi registrati del gruppo di disponibilità. Le pianificazioni vengono attivate su tutti i nodi di AG, e le estensioni di backup del carico di lavoro su questi nodi si sincronizzano tra loro per decidere quale nodo può eseguire il backup. La selezione del nodo dipende dal tipo di backup e dalla preferenza di backup, come illustrato nella sezione 1.

Il nodo selezionato procede con il processo di backup, mentre il processo attivato negli altri nodi si interrompe, ovvero viene saltato.

Registrare i nodi del gruppo di disponibilità nell'insieme di credenziali di Servizi di ripristino

Un insieme di credenziali di Servizi di ripristino supporta il backup dei database solo dalle macchine virtuali che si trovano nella stessa area e nella stessa sottoscrizione dell'insieme.

• Registrare il nodo primario nell'insieme di credenziali (in caso contrario, non è possibile eseguire backup completi).
• Registrare almeno un nodo secondario nell'insieme di credenziali (in caso contrario, non è possibile eseguire backup di log/completi di sola copia) se la preferenza di backup è solo secondario.

Se le condizioni precedenti non vengono soddisfatte, la configurazione dei backup per i database del gruppo di disponibilità ha esito negativo con codice di errore FabricSvcBackupPreferenceCheckFailedUserError.

Si consideri la seguente distribuzione del gruppo di disponibilità come riferimento.

Ecco alcune considerazioni sulla base della distribuzione del gruppo di disponibilità di esempio specificata:

• Poiché il nodo primario si trova nell'area 1 e nella sottoscrizione 1, per proteggere il gruppo di disponibilità l'insieme di credenziali di Servizi di ripristino (insieme di credenziali 1) deve trovarsi nell'area 1 e nella sottoscrizione 1.
• VM3 non può essere registrato su Vault 1 perché si trova in una sottoscrizione diversa.
• VM4 non può essere registrato nel Vault 1 perché si trova in una regione diversa.
• Se la preferenza di backup è solo secondaria, VM1 (Primario) e VM2 (Secondario) devono essere registrate nel Vault 1 (perché i backup completi richiedono il nodo primario e i log richiedono un nodo secondario). Per altre preferenze di backup, VM1 (primario) deve essere registrato nel Vault 1, VM2 è facoltativo (perché tutti i backup possono essere eseguiti sul nodo primario).
• Sebbene la macchina virtuale 3 possa essere registrata nell'insieme di credenziali 2 della sottoscrizione 2 e i database del gruppo di disponibilità vengano visualizzati per la protezione nell'insieme di credenziali 2, la configurazione dei backup avrebbe esito negativo a causa dell'assenza del nodo primario nell'insieme di credenziali 2.
• Analogamente, anche se VM4 potrebbe essere registrata nell'insieme di credenziali 4 nell'area 2, la configurazione dei backup avrà esito negativo perché il nodo primario non è registrato nell'insieme di credenziali 4.

Gestione del failover

Dopo il failover del gruppo di disponibilità in uno dei nodi secondari:

• I backup completi e differenziali continueranno dal nuovo nodo primario se è registrato nell'insieme di credenziali.
• Il backup dei log e i backup completi di sola copia continueranno dal nodo primario/secondario in base alle preferenze specificate.

In base alla distribuzione del gruppo di disponibilità di esempio precedente, di seguito sono riportate le diverse possibilità di failover.

• Failover nella macchina virtuale 2
  • I backup completi e differenziali verranno eseguiti da VM2.
  • I backup completi di log e copia verranno eseguiti da VM1 o VM2 in base alle preferenze di backup.
• Failover nella macchina virtuale 3 (un'altra sottoscrizione)
  • Poiché i backup non sono configurati in Vault 2, non verrebbero eseguiti backup.
  • Se la preferenza di backup non è solo secondaria, i backup possono essere configurati ora in Vault 2, perché il nodo primario è registrato in questo vault. Questo può tuttavia causare conflitti/errori di backup. Per ulteriori informazioni, consultare Configurare i backup per un AG multi-regione.
• Failover nella macchina virtuale 4 (un'altra area)
  • Poiché i backup non sono configurati in Vault 4, non verrebbero eseguiti backup.
  • Se la preferenza di backup non è solo secondaria, i backup possono essere configurati ora in Vault 4, perché il nodo primario è registrato in questo vault. Questo può tuttavia causare conflitti/errori di backup. Per ulteriori informazioni, consultare Configurare i backup per un AG multi-regione.

Configurare i backup per un gruppo di disponibilità in più aree

L'insieme di credenziali di Servizi di ripristino non supporta i backup tra sottoscrizioni o aree diverse. Questa sezione riepiloga come abilitare i backup per i gruppi di disponibilità che si estendono su sottoscrizioni o aree di Azure e le considerazioni associate.

• Valutare se è effettivamente necessario abilitare i backup da tutti i nodi. Se una regione/abbonamento ha la maggior parte dei nodi del Gruppo di Disponibilità e se il failover su altri nodi avviene molto raramente, configurare il backup in quella prima regione potrebbe essere sufficiente. Se i failover in un'altra area/sottoscrizione vengono eseguiti frequentemente e per una durata prolungata, è consigliabile configurare i backup in modo proattivo anche nell'altra area.

• Ogni vault in cui il backup viene abilitato avrà la propria catena di punti di ripristino. I ripristini da tali punti possono essere eseguiti solo nelle macchine virtuali registrate nell'insieme di credenziali specificato.

• I backup completi/differenziali verranno eseguiti con successo solo nell'insieme di credenziali con il nodo primario. Tali backup in altri insiemi di credenziali continueranno ad avere esito negativo.

• I backup del log continueranno a funzionare nell'archivio precedente fino a quando non verrà eseguito un backup del log nel nuovo archivio (ovvero nell'archivio in cui è presente il nuovo nodo primario) e interromperà la catena di log per l'archivio precedente.

  Nota

  È previsto un limite rigido di 15 giorni oltre il quale i backup del log inizieranno a non riuscire.

• I backup completi di sola copia funzioneranno in tutti i vault.

• La protezione in ogni insieme di credenziali viene considerata come un'origine dati distinta e viene fatturata separatamente.

Per evitare conflitti di backup dei log tra i due insiemi di credenziali, è consigliabile impostare la preferenza di backup su primario. Quindi, il vault che ospita il nodo primario si occuperà anche dei backup del log.

In base alla distribuzione del gruppo di disponibilità di esempio precedente, ecco i passaggi per abilitare il backup da tutti i nodi. Il presupposto è che le preferenze di backup siano soddisfatte in tutti i passaggi.

Passaggio 1: Abilitare i backup nella Regione 1, Sottoscrizione 1 (Vault 1)

Poiché il nodo primario si trova nella regione e nella sottoscrizione, i passaggi usuali per abilitare i backup funzioneranno.

Passaggio 2: Abilitare i backup nella Regione 1, Sottoscrizione 2 (Vault 2)

1. Eseguire il failover dell'AG su VM3 in modo che il nodo primario sia presente nel Vault 2.
2. Configurare i backup per i database dell'AG in Vault 2.
3. A questo punto:
   1. I backup completi/differenziali falliranno in Vault 1 poiché nessuno dei nodi registrati può eseguire questo backup.
   2. I backup del log avranno esito positivo nell'insieme di credenziali 1 fino a quando non viene eseguito un backup del log nell'insieme di credenziali 2 e non si interrompe la catena di log per l'insieme di credenziali 1.
4. Eseguire il failback del gruppo di disponibilità alla macchina virtuale 1.

Passaggio 3: Abilitare i backup nella Regione 2, Sottoscrizione 1 (Vault 4)

Uguale al passaggio 2.

Eseguire il backup di un gruppo di disponibilità che si estende su Azure e in locale

Backup di Azure per SQL Server non può essere eseguito in locale. Se il nodo primario si trova in Azure e la preferenza di backup è soddisfatta dai nodi in Azure, è possibile seguire le indicazioni precedenti per il gruppo di disponibilità in più aree per abilitare i backup per le repliche in Azure. Se si verifica un failover verso il nodo locale, i backup completi e differenziali in Azure inizieranno a fallire. I backup dei log possono continuare fino a quando non si verifica l'interruzione della catena dei log o trascorrano 15 giorni.

Limitazione dei processi di backup in un database del gruppo di disponibilità

Attualmente, le soglie di limitazione del backup si applicano a livello di singolo computer. Il limite predefinito è 20: se vengono attivati più di 20 backup contemporaneamente, verranno eseguiti i primi 20 e gli altri verranno accodati. Quando i processi in esecuzione sono completati, inizia l'elaborazione di quelli in coda.

È possibile modificare questo valore impostando un valore inferiore se i backup simultanei causano un carico di memoria/I/O/CPU sul nodo. Poiché la limitazione è a livello di nodo, la presenza di nodi non bilanciati nel gruppo di disponibilità può causare problemi con la sincronizzazione dei backup. Per comprendere questo aspetto, prendere in considerazione un gruppo di disponibilità di 2 nodi.

Ad esempio, il primo nodo ha 50 database autonomi protetti ed entrambi i nodi hanno 5 database del gruppo di disponibilità protetti. In effetti, il nodo 1 ha 55 processi di backup del database pianificati, mentre il nodo 2 ha solo 5. Inoltre, tutti questi backup sono configurati per l'esecuzione contemporaneamente, ogni ora. A un certo punto, tutti i 55 backup vengono attivati sul nodo 1 e 35 di questi vengono inseriti in coda. Alcuni di questi sono i backup dei database del gruppo di disponibilità. Ma nel nodo 2, i backup del database AG procederebbero senza coda.

Poiché i processi del database del gruppo di disponibilità vengono inseriti nella coda in un nodo ed eseguiti su un altro, la sincronizzazione del backup (citata nella sezione 6) non funzionerà correttamente. Il nodo 2 potrebbe presupporre che il nodo 1 sia inattivo e che i processi non siano disponibili per la sincronizzazione. Ciò può causare interruzioni della catena di log o backup aggiuntivi perché entrambi i nodi possono eseguire backup in modo indipendente.

Un problema simile può verificarsi se il numero di database del gruppo di disponibilità protetti è superiore alla soglia di limitazione. In questo caso, il backup per il database 1, ad esempio, può essere inserito nella coda del nodo 1, ma eseguito sul nodo 2.

È consigliabile usare le preferenze di backup seguenti per evitare questi problemi di sincronizzazione:

• Per un gruppo di disponibilità a 2 nodi, impostare la preferenza di backup su primario o solo secondario, in modo che solo un nodo possa eseguire i backup, mentre l'altro verrà sempre escluso.
• Per un gruppo di disponibilità con più di 2 nodi, impostare la preferenza di backup su primario, in modo che solo il nodo primario possa eseguire i backup, mentre gli altri vengono esclusi.

Fatturazione per i backup AG

Come un'istanza di SQL autonoma, un'istanza AG di cui è stato eseguito il backup è considerata un'istanza protetta. Viene addebitata la dimensione totale del front-end di tutti i database protetti in un'istanza. Si consideri la distribuzione seguente:

Le istanze protette vengono calcolate come segue:

Spostamento di un database protetto all'interno o all'esterno di un gruppo di disponibilità

Backup di Azure considera l'istanza SQL o il nome del gruppo di disponibilità\nome del database come nome univoco del database. Quando il database autonomo è stato protetto, il nome univoco era StandAloneInstanceName\DBName. Quando si sposta sotto un AG, il nome univoco cambia in AGName\DBName. I backup per il database autonomo inizieranno a non riuscire con il codice di errore UserErrorBackupFailedStandaloneDatabaseMovedInToAG.

Il database deve essere configurato per la protezione dall'interno del gruppo di disponibilità. Questa operazione verrà considerata come una nuova origine dati con una catena di punti di ripristino separata. La protezione più vecchia del database autonomo può essere interrotta mantenendo i dati per evitare che i futuri backup si attivino e falliscano su di essa. Analogamente, quando un database del gruppo di disponibilità protetto esce dal gruppo e diventa un database autonomo, i relativi backup hanno esito negativo con codice di errore UserErrorBackupFailedDatabaseMovedOutOfAG.

Il database deve essere configurato per la protezione dall'interno dell'istanza autonoma. Questa operazione verrà considerata come una nuova origine dati con una catena di punti di ripristino separata. La protezione precedente del database del gruppo di disponibilità può essere disabilitata conservando i dati per evitare l'attivazione e il fallimento dei backup futuri.

Aggiunta/rimozione di un nodo a un gruppo di disponibilità

Quando un nuovo nodo viene aggiunto a un gruppo di disponibilità configurato per i backup, le estensioni di backup del carico di lavoro in esecuzione nei nodi del gruppo di disponibilità già registrati rilevano la modifica della topologia del gruppo di disponibilità e informano il servizio Backup di Azure durante il successivo processo di individuazione del database pianificato. Quando questo nuovo nodo viene registrato per i backup nello stesso insieme di credenziali di Servizi di ripristino degli altri nodi esistenti, il servizio Backup di Azure attiva un flusso di lavoro che configura il nuovo nodo con i metadati necessari per l'esecuzione di backup del gruppo di disponibilità.

Successivamente, il nuovo nodo sincronizza le informazioni sulla pianificazione del backup del gruppo di disponibilità dal servizio Backup di Azure e inizia a partecipare al processo di backup sincronizzato. Se il nuovo nodo non è in grado di sincronizzare le pianificazioni di backup né di partecipare ai backup, l'attivazione di una nuova registrazione sul nodo forza anche la riconfigurazione del nodo per i backup del gruppo di disponibilità. Analogamente all'aggiunta di nodi, le estensioni del carico di lavoro rilevano il cambiamento della topologia del gruppo di disponibilità in questo caso e informano il servizio Backup di Azure. Il servizio avvia un flusso di lavoro di annullamento della configurazione nel nodo rimosso per cancellare le pianificazioni di backup per i database del gruppo di disponibilità ed eliminare i metadati correlati al gruppo.

Annullare la registrazione di un nodo del gruppo di disponibilità da Backup di Azure

Se un nodo fa parte di un gruppo di disponibilità con uno o più database configurati per il backup, Backup di Azure non consente la cancellazione della registrazione di tale nodo. Ciò consente di evitare errori di backup futuri nel caso in cui la preferenza di backup non possa essere soddisfatta senza questo nodo. Per annullare la registrazione del nodo, prima è necessario rimuoverlo dall'AG. Al termine del flusso di lavoro di annullamento della configurazione del nodo, è possibile annullare la registrazione del nodo.

Il ripristino di un database da Backup di Azure a un gruppo di disponibilità SQL non supporta il ripristino diretto di un database all'interno del gruppo. Il database deve essere ripristinato in un'istanza SQL autonoma e quindi essere aggiunto a un gruppo di disponibilità.

Scenari per la ricreazione dei gruppi di disponibilità del server di database SQL

La ricreazione del gruppo di disponibilità, i gruppi di disponibilità duplicati e gli elementi di backup vengono elencati come elementi protetti o elementi protetti negli scenari seguenti:

• Quando i gruppi di disponibilità già protetti vengono ricreati, appaiono come gruppi di disponibilità duplicati nella pagina Configura backup e nell'elenco Elementi protetti. Se si desidera conservare i dati di backup già presenti nel gruppo di disponibilità precedente, arrestare il backup usando l'opzione Arresta protezione e conservare i dati prima di creare e pianificare i backup nei nuovi elementi del gruppo di disponibilità.

  Per impostazione predefinita, Backup di Azure elenca gli elementi duplicati nell'elenco Elementi protetti e l'elenco Configura backup o Elementi proteggibili e visualizza questi elementi fino a quando non si desidera conservare i dati di backup.

• Se non si desiderano conservare i dati di backup del gruppo di disponibilità precedente, arrestare l'operazione di backup tramite l'opzione Arresta protezione ed elimina dati per tale gruppo prima di ricreare e pianificare i backup nel nuovo gruppo di disponibilità.

  Attenzione

  Arrestare la protezione e eliminare i dati è un'operazione distruttiva.

• È possibile ricreare il gruppo di disponibilità dopo aver eseguito uno dei processi di arresto della protezione precedenti per evitare errori di backup.

Passaggi successivi

Scopri come:

• Ripristinare i database di SQL Server di cui è stato eseguito il backup
• Gestire i database di SQL Server di cui è stato eseguito il backup

Contenuti correlati

• Eseguire il backup di database di SQL Server in macchine virtuali di Azure usando Backup di Azure tramite l'API REST.
• Ripristinare i database di SQL Server nelle macchine virtuali di Azure con l'API REST.
• Gestire i database di SQL Server in macchine virtuali di Azure con il portale di Azure, l'interfaccia della riga di comando di Azure, l'API REST.