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.

Comportamento delle preferenze di backup in base alla versione di SQL Server

Il supporto del backup completo e differenziale nelle repliche secondarie dipende dalla versione SQL Server. La preferenza di backup dell'AG e la versione di SQL Server determinano il nodo selezionato per ogni tipo di backup.

SQL Server 2022 e versioni precedenti

La preferenza di backup utilizzata da Backup di Azure 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.

SQL Server 2025 e versioni successive

In SQL Server 2025 e versioni successive, le repliche secondarie supportano anche backup completi e differenziali. La preferenza di backup ora regola entrambi i tipi di backup in modo uniforme. Quando si imposta Solo secondario o Preferisci secondario, i backup completi e differenziali non richiedono più l'uso del nodo primario.

Quando si registra un nodo con il servizio Backup di Azure, si installa l'estensione di backup del carico di lavoro in tale nodo. Quando si configura un database del gruppo di disponibilità per il backup, le pianificazioni di backup vengono spostate in tutti i nodi registrati del gruppo di disponibilità. Le pianificazioni si attivano su tutti i nodi 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 descritta in Comportamento delle preferenze di backup per SQL Server versione.

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.

SQL Server 2022 e versioni precedenti:

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

SQL Server 2025 e versioni successive:

• La registrazione del nodo primario non è più obbligatoria per la configurazione del backup AG. Poiché i backup completi e differenziali possono ora essere eseguiti nelle repliche secondarie, è possibile configurare i backup con solo i nodi secondari registrati (quando la preferenza di backup è Solo secondaria o Preferisce secondario).
• Per la preferenza di backup primario , il nodo primario deve comunque essere registrato.
• Registrare almeno un nodo che soddisfi la preferenza di backup scelta.

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, registrare VM1 (Primario) e VM2 (Secondario) in Vault 1. Nei SQL Server 2022 e versioni precedenti, i backup completi richiedono il nodo primario in modo da registrare entrambi i nodi. In SQL Server 2025 e versioni successive, VM2 è sufficiente. Per altre preferenze di backup, registrare la VM1 (primaria) nell'insieme di credenziali 1; la VM2 è facoltativa.
• Sebbene sia possibile registrare la VM3 nell'insieme di credenziali 2 nella sottoscrizione 2 e i database del gruppo di disponibilità verrebbero quindi visualizzati per la protezione nell'insieme di credenziali 2, la configurazione dei backup non riuscirebbe in SQL Server 2022 e versioni precedenti a causa dell'assenza del nodo primario nell'insieme di credenziali 2. In SQL Server 2025 e versioni successive, è possibile configurare i backup in vault 2 se la preferenza per il backup è Solo secondario o Preferisci secondario.
• Analogamente, anche se è possibile registrare VM4 nell'insieme di credenziali 4 nell'area 2, la configurazione dei backup avrà esito negativo in SQL Server 2022 e versioni precedenti perché il nodo primario non è registrato nell'insieme di credenziali 4. In SQL Server 2025 e versioni successive è possibile configurare i backup nel vault 4 se la preferenza di backup è Solo secondario o Preferisci secondario.

Gestione del failover

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

• SQL Server 2022 e versioni precedenti: i backup completi e differenziali continuano a essere eseguiti dal nuovo nodo primario se è registrato nell'insieme di credenziali.
• SQL Server 2025 e versioni successive: i backup completi e differenziali continuano dal nodo che soddisfa le preferenze di backup. Con Solo secondario o Preferisci secondario, questi backup possono essere eseguiti su una replica secondaria.
• 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.
  • In SQL Server 2022 e versioni precedenti, se la preferenza di backup non è impostata su esclusivamente secondaria, ora è possibile configurare i backup in Vault 2 perché il nodo primario è registrato in questo vault. In SQL Server 2025 e versioni successive, è anche possibile configurare i backup quando il nodo registrato in Vault 2 soddisfa le preferenze di backup selezionate. Questa condizione può causare conflitti o errori di backup. Per altre informazioni, vedere Configurare i backup per un gruppo di disponibilità per più aree geografiche.
• Failover nella macchina virtuale 4 (un'altra area)
  • Poiché i backup non sono configurati in Vault 4, non verrebbero eseguiti backup.
  • In SQL Server 2022 e versioni precedenti, se la preferenza di backup non è impostata su solo secondaria, ora è possibile configurare i backup in Vault 4 perché il nodo primario è registrato in questo vault. In SQL Server 2025 e versioni successive è anche possibile configurare i backup quando il nodo registrato in Vault 4 soddisfa le preferenze di backup selezionate. Questa condizione può causare conflitti o errori di backup. Per altre informazioni, vedere Configurare i backup per un gruppo di disponibilità per più aree geografiche.

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.

• SQL Server 2022 e versioni precedenti: i backup completi e differenziali funzionano solo nel vault che contiene il nodo primario. Tali backup in altri insiemi di credenziali continuano ad avere esito negativo. In SQL Server 2025 e versioni successive, questo comportamento cambia per le preferenze Solo secondaria e Preferisci secondaria - vedere SQL Server 2025: modifiche al backup dei gruppi di disponibilità per più aree geografiche.

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

SQL Server 2025: modifiche al backup dei gruppi di disponibilità per più aree geografiche

Con SQL Server 2025, i backup completi e differenziali non richiedono più il nodo primario. Questa modifica significa:

• La registrazione del nodo primario non è obbligatoria : se la preferenza di backup è Solo secondaria o Preferisce secondaria, è possibile configurare ed eseguire backup da qualsiasi nodo secondario registrato, anche se il nodo primario si trova in un'area o una sottoscrizione diversa.

• Impatto ridotto del failover — dopo il failover su un nodo in un'area geografica diversa, i backup possono continuare nell'insieme di credenziali originale purché sia disponibile un nodo registrato che soddisfi la preferenza di backup.

Tuttavia, la limitazione fondamentale del coordinamento tra insiemi di credenziali rimane: i backup non possono essere coordinati tra più insiemi di credenziali. Se si registrano nodi del gruppo di disponibilità in insiemi di credenziali diversi in aree geografiche diverse, le pianificazioni di backup simultanei possono entrare in conflitto e causare interruzioni nella catena dei log o backup duplicati.

Raccomandazione per evitare conflitti tra insiemi di credenziali:

• AG a 2 nodi: Impostare la preferenza di backup su Solo secondario o Primario.
• AG a 3 o più nodi: Impostare la preferenza di backup su Primario.

Questa configurazione garantisce che solo un nodo dell'insieme di credenziali sia idoneo per i backup in qualsiasi momento.

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.

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 AG vengono messi in coda su un nodo e vengono eseguiti su un altro, la sincronizzazione dei backup non funziona correttamente. Il nodo 2 potrebbe presupporre che il nodo 1 sia inattivo e quindi i processi del nodo 1 non siano in arrivo per la sincronizzazione. Questo problema 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:

Spostare 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 o 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à.

Dopo questo passaggio, il nuovo nodo sincronizza le informazioni sulla pianificazione del backup AG con il 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, durante la rimozione del nodo, le estensioni del carico di lavoro rilevano la modifica della topologia dell'AG e informano il servizio Backup di Azure. Il servizio avvia un flusso di lavoro di annullamento della configurazione sul 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 AG 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.

Considerazioni sui backup del gruppo di disponibilità SQL Server 2025

Modifiche alle preferenze di backup dopo la configurazione

Se si modifica la preferenza del backup del gruppo di disponibilità ma non si registra il nodo necessario nell'insieme di credenziali, i backup non riescono. Ad esempio, se si modifica la preferenza da Primaria a Secondaria, ma non viene registrato alcun nodo secondario, il log e i backup completi/diff hanno esito negativo. Verificare sempre che i nodi che soddisfano la nuova preferenza di backup siano registrati nell'insieme di credenziali prima di apportare la modifica.

Coordinamento del backup del gruppo di disponibilità in più aree geografiche

Quando si proteggono i nodi del gruppo di disponibilità in più insiemi di credenziali in aree geografiche diverse, gli insiemi di credenziali non possono coordinare i backup tra di essi, indipendentemente dalla versione di SQL Server. Per indicazioni su come configurare le impostazioni delle preferenze di backup in modo da evitare interruzioni della catena di log e i backup duplicati in questo scenario, vedere SQL Server 2025: modifiche al backup dei gruppi di disponibilità in più aree geografiche.

Supporto per il backup di snapshot

I backup degli snapshot non sono supportati sulle repliche secondarie di un gruppo di disponibilità. Quando si abilita il backup degli snapshot nei criteri di backup, la registrazione del nodo primario rimane obbligatoria indipendentemente dalla versione SQL Server.

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.