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 (AG) 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 del gruppo di disponibilità sono distribuiti tra aree,sottoscrizioni/locali e Azure, è necessario tenere presenti alcune considerazioni.

Nota

• Il backup dei database del gruppo di disponibilità di base non è supportato da Backup di Azure.
• Per altre informazioni sulle configurazioni e sugli scenari supportati, vedere la matrice di supporto del backup di SQL.

La preferenza di backup usata dal gruppo di disponibilità SQL di Backup di Azure supporta backup completi e differenziali solo dalla replica primaria. Quindi, questi processi di backup vengono sempre eseguiti nel nodo Primario indipendentemente dalla preferenza di backup. Per i backup completi e del log delle transazioni di sola copia, la preferenza di backup del gruppo di disponibilità viene considerata durante la decisione del nodo in cui verrà eseguito il backup.

Preferenza di backup AG	Backup completi e diff eseguiti in	I backup di sola copia e di log vengono eseguiti da
Server/istanza primaria	Replica primaria	Replica primaria
Solo secondaria	Replica primaria	Qualsiasi replica secondaria
Preferisco secondario	Replica primaria	Le repliche secondarie sono preferite, ma i backup possono essere eseguiti anche nella replica primaria.
Nessuno/Nessuna	Replica primaria	Qualsiasi replica

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 push in tutti i nodi registrati del gruppo di disponibilità. Le pianificazioni vengono attivate in tutti i nodi del gruppo di disponibilità e le estensioni di backup del carico di lavoro in questi nodi vengono sincronizzate 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 salva, ovvero ignora il processo.

Nota

Backup di Azure non considera le priorità di backup o le repliche durante la scelta tra le repliche secondarie.

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 nella stessa area e nella stessa sottoscrizione dell'insieme di credenziali.

• 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 completi di sola registrazione/copia) se la preferenza di backup è solo secondaria.

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

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

In base alla distribuzione del gruppo di disponibilità di esempio specificata, di seguito sono riportate varie considerazioni:

• Poiché il nodo primario si trova nell'area 1 e nella sottoscrizione 1, l'insieme di credenziali di Servizi di ripristino (Insieme di credenziali 1) deve trovarsi nell'area 1 e nella sottoscrizione 1 per proteggere questo gruppo di disponibilità.
• VM3 non può essere registrato nell'insieme di credenziali 1 perché si trova in una sottoscrizione diversa.
• VM4 non può essere registrato nell'insieme di credenziali 1 perché si trova in un'area diversa.
• Se la preferenza di backup è solo secondaria, VM1 (primario) e VM2 (secondario) devono essere registrati nell'insieme di credenziali 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 nell'insieme di credenziali 1, VM2 è facoltativo (perché tutti i backup possono essere eseguiti nel nodo primario).
• Anche se VM3 potrebbe essere registrato nell'insieme di credenziali 2 nella sottoscrizione 2 e i database del gruppo di disponibilità verrebbero visualizzati per la protezione nell'insieme di credenziali 2, ma a causa dell'assenza del nodo primario nell'insieme di credenziali 2, la configurazione dei backup avrebbe esito negativo.
• 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 log e i backup completi di sola copia continueranno dal nodo primario/secondario in base alle preferenze di backup.

Nota

Le interruzioni della catena di log non si verificano durante il failover se il failover non coincide con un backup.

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

• Failover in VM2
  • 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 in VM3 (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 insieme di credenziali. Questo può tuttavia causare conflitti/errori di backup. Per altre informazioni, vedere Configurare i backup per un AG in più aree.
• Failover in VM4 (un'altra area)
  • Poiché i backup non sono configurati nell'insieme di credenziali 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 insieme di credenziali. Questo può tuttavia causare conflitti/errori di backup. Per altre informazioni, vedere Configurare i backup per un AG in più aree.

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

L'insieme di credenziali di servizi di ripristino non supporta i backup tra più sottoscrizioni o regioni. 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 la maggior parte dei nodi del gruppo di disponibilità e il failover in altri nodi avviene raramente, la configurazione del backup in tale prima area 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 insieme di credenziali in cui il backup viene abilitato avrà un proprio set di catene di punti di ripristino. I ripristini da questi punti di ripristino possono essere eseguiti solo nelle macchine virtuali registrate in tale insieme di credenziali.

• I backup completi/differenziali verranno eseguiti correttamente solo nell'insieme di credenziali con il nodo primario. Questi backup in altri insiemi di credenziali continueranno a non riuscire.

• I backup del log continueranno a funzionare nell'insieme di credenziali precedente fino a quando non viene eseguito un backup del log nel nuovo insieme di credenziali (ovvero nell'insieme di credenziali in cui è presente il nuovo nodo primario) e interrompe la catena di log per l'insieme di credenziali 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 gli insiemi di credenziali.

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

Per evitare conflitti di backup del log tra i due insiemi di credenziali, è consigliabile impostare la preferenza di backup su Primario. A questo scopo, anche l'insieme di credenziali con il nodo primario eseguirà i 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 nell'area 1, sottoscrizione 1 (insieme di credenziali 1)

Poiché il nodo primario si trova nell'area e nella sottoscrizione, i normali passaggi per abilitare i backup funzioneranno.

Passaggio 2: Abilitare i backup nell'area 1, sottoscrizione 2 (insieme di credenziali 2)

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

Passaggio 3: Abilitare i backup nell'area 2, sottoscrizione 1 (insieme di credenziali 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 nel nodo locale, i backup completi e differenziali in Azure avranno esito negativo. I backup del log possono continuare fino a quando non si verifica l'interruzione della catena di log/15 giorni.

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

Attualmente, i limiti 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. Al termine dei processi in esecuzione, i processi in coda inizieranno a essere in esecuzione.

È 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 del gruppo di disponibilità sbilanciati può causare problemi di sincronizzazione del backup. Per comprendere questo problema, prendere in considerazione un gruppo di disponibilità di 2 nodi, ad esempio.

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 verranno attivati nel Nodo 1 e 35 di questi verranno accodati. Alcuni di questi sono i backup del database del gruppo di disponibilità. Ma nel nodo 2, i backup del database del gruppo di disponibilità andrebbero avanti senza accodamento.

Poiché i processi del database del gruppo di disponibilità vengono accodati in un nodo e in esecuzione su un altro, la sincronizzazione dei backup (menzionata nella sezione 6) non funzionerà correttamente. Il nodo 2 potrebbe presupporre che il nodo 1 sia inattivo e quindi 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 al limite di limitazione. In questo caso, il backup per, ad esempio, DB1 può essere accodato nel nodo 1, mentre viene eseguito nel 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 Solo primario o secondario, quindi solo un nodo può eseguire i backup, l'altro verrà sempre salvato.
• Per un gruppo di disponibilità con più di 2 nodi, impostare La preferenza di backup su Primario, quindi solo il nodo primario può eseguire i backup, altri verranno salvata.

Fatturazione per i backup del gruppo di disponibilità

Come un'istanza di SQL autonoma, un'istanza del gruppo di disponibilità di cui è stato eseguito il backup viene considerata come un'istanza protetta. Vengono addebitate le dimensioni front-end totali di tutti i database protetti in un'istanza. Si consideri la distribuzione seguente:

Le istanze protette vengono calcolate come segue:

Istanza protetta/Istanza di fatturazione	Database considerati per il calcolo delle dimensioni front-end
AG1	DB1, DB2
AG2	DB4
VM2	DB3
VM3	DB6
VM4	DB5

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

Backup di Azure considera l'istanza SQL o il nome del gruppo di disponibilità\Nome database come nome univoco del database. Quando il database autonomo è stato protetto, il nome univoco era StandAloneInstanceName\DBName. Quando si sposta in un gruppo di disponibilità, 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 dal gruppo di disponibilità. Questa operazione verrà considerata come una nuova origine dati con una catena di punti di ripristino separata. La protezione precedente del database autonomo può essere arrestata con la conservazione dei dati per evitare backup futuri dall'attivazione e dall'esito negativo. Analogamente, quando un database del gruppo di disponibilità protetto esce dal gruppo di disponibilità e diventa un database autonomo, i relativi backup iniziano a non riuscire con codice errore: UserErrorBackupFailedDatabaseMovedOutOfAG.

Il database deve essere configurato per la protezione dall'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 arrestata con la conservazione dei dati per evitare backup futuri dall'attivazione e dall'esito negativo.

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 questo nuovo nodo con i metadati necessari per l'esecuzione di backup del gruppo di disponibilità.

Successivamente, il nuovo nodo sincronizza le informazioni di pianificazione del backup del gruppo di disponibilità dal servizio Backup di Azure e avvia la partecipazione al processo di backup sincronizzato. Se il nuovo nodo non è in grado di sincronizzare le pianificazioni di backup e partecipare ai backup, attivando una nuova registrazione sul nodo forza anche la riconfigurazione del nodo per i backup del gruppo di disponibilità. Analogamente, l'aggiunta di nodi, le estensioni del carico di lavoro rilevano la modifica 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 del nodo nel nodo rimosso per cancellare le pianificazioni di backup per i database del gruppo di disponibilità ed eliminare i metadati correlati al gruppo di disponibilità.

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 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 dal gruppo di disponibilità. 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 gruppi di disponibilità SQL del gruppo di disponibilità non supporta il ripristino diretto di un database nel gruppo di disponibilità. Il database deve essere ripristinato in un'istanza SQL autonoma e deve quindi essere aggiunto a un gruppo di disponibilità.

Scenari di ricreazione del gruppo di disponibilità per il server di database SQL

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

• La ricreazione dei gruppi di disponibilità già protetti viene visualizzata 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 conserva 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 nella pagina Configura backup o nell'elenco Elementi proteggibili e visualizza questi elementi fino a quando non si desidera conservare i dati di backup.

• Se non si desidera che i dati di backup del gruppo di disponibilità meno recente vengano interrotti, arrestare l'operazione di backup usando l'opzione Arresta protezione ed elimina dati per l'elemento precedente prima di creare 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 protezione di arresto precedenti per evitare errori di backup.

Passaggi successivi

Scopri come:

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