Configurazione del backup gestito di SQL Server in Azure per i gruppi di disponibilità
Questo argomento illustra come configurare SQL Server Backup gestito in Microsoft Azure per i database che partecipano ai gruppi di disponibilità AlwaysOn.
Configurazioni del gruppo di disponibilità
SQL Server Backup gestito in Microsoft Azure è supportato per i database del gruppo di disponibilità, indipendentemente dal fatto che le repliche siano tutte configurate in locale o completamente in Azure o in un'implementazione ibrida tra le macchine virtuali locali e in una o più macchine virtuali di Azure. Tuttavia potrebbe essere necessario prendere in considerazione quanto riportato di seguito per una o più implementazioni.
Frequenza di backup del log: la frequenza di backup del log viene calcolata sia in termini di tempo sia in base all'aumento delle dimensioni del log. Ad esempio, il backup del log viene eseguito una volta ogni 2 ore, a meno che lo spazio del log utilizzato entro questo periodo di tempo non sia di almeno 5 MB. Questo aspetto riguarda tutte le implementazioni, in locale, nel cloud o in una soluzione ibrida.
Larghezza di banda di rete: si applica alle implementazioni in cui le repliche si trovano in posizioni fisiche diverse, ad esempio in un cloud ibrido o in aree di Azure diverse in una configurazione solo cloud. La larghezza di banda di rete può influire sulla latenza delle repliche secondarie e l'eventuale impostazione di queste ultime sulla replica sincrona può determinare un aumento delle dimensioni del log nella replica primaria. Se le repliche secondarie sono impostate sulla replica sincrona, potrebbero non rimanere sincronizzate a causa della latenza di rete che può comportare la perdita di dati in caso di failover sulla replica secondaria.
Configurazione di SQL Server backup gestito in Microsoft Azure per i database di disponibilità.
Autorizzazioni:
Richiede l'appartenenza al ruolo del database db_backupoperator , con autorizzazioni ALTER ANY CREDENTIAL e
EXECUTE
autorizzazioni per sp_delete_backuphistorystored procedure.Richiede autorizzazioni SELECT per la funzione smart_admin.fn_get_current_xevent_settings.
Richiede
EXECUTE
autorizzazioni per la stored procedure smart_admin.sp_get_backup_diagnostics . È inoltre richiesta l'autorizzazioneVIEW SERVER STATE
poiché vengono chiamati internamente altri oggetti di sistema che richiedono tale autorizzazione.Richiede
EXECUTE
autorizzazioni per lesmart_admin.sp_set_instance_backup
stored procedure esmart_admin.sp_backup_master_switch
.
Di seguito sono riportati i passaggi di base per configurare un gruppo di disponibilità AlwaysOn con SQL Server Backup gestito in Microsoft Azure. Un'esercitazione dettagliata viene descritta più avanti in questo argomento.
Una volta creato il gruppo di disponibilità, configurare la replica di backup preferita. Questa impostazione per il gruppo di disponibilità viene usata anche da SQL Server Backup gestito in Microsoft Azure per determinare quale replica usare per il backup. Per istruzioni dettagliate su come configurare le preferenze di backup, vedere Configurare backup nelle repliche di disponibilità (SQL Server). Se si sta creando un nuovo gruppo di disponibilità AlwaysOn, vedere Introduzione con gruppi di disponibilità AlwaysOn (SQL Server).
Configurare l'accesso per la connessione in sola lettura alle repliche secondarie. Per istruzioni dettagliate su come configurare l'accesso in sola lettura, vedere Configurare l'accesso Read-Only in una replica di disponibilità (SQL Server)
Specificare la replica di backup. L'impostazione di replica di backup preferita viene usata da SQL Server Backup gestito in Microsoft Azure per determinare quale database usare per pianificare i backup da.. Per determinare se la replica corrente è la replica di backup preferita, usare la funzione sys.fn_hadr_backup_is_preferred_replica (Transact-SQL).
In ogni replica viene eseguito SQL Server Backup gestito nella configurazione di Microsoft Azure per il database usando la stored procedure smart-admin.sp_set_db_backup.
SQL Server comportamento del backup gestito in Microsoft Azure dopo un failover: SQL Server backup gestito in Microsoft Azure continuerà a funzionare e mantenere le copie di backup e la ripristinabilità dopo un evento di failover. Non è richiesta alcuna azione specifica dopo un failover.
Considerazioni e requisiti:
La configurazione di SQL Server Backup gestito in Microsoft Azure per i database che partecipano al gruppo di disponibilità AlwaysOn richiede considerazioni e requisiti specifici. Di seguito è riportato un elenco delle considerazioni e dei requisiti:
Le impostazioni di configurazione del backup gestito SQL Server in Microsoft Azure devono essere uguali per tutti i database in tutti i nodi di SQL Server che partecipano allo stesso gruppo di disponibilità. È possibile ottenere questo risultato impostando la stessa SQL Server Backup gestito su configurazioni di Microsoft Azure per le repliche primarie e tutte le repliche a livello di database oppure impostando le stesse impostazioni predefinite SQL Server Backup gestito su Microsoft Azure in tutti i nodi che partecipano ai gruppi di disponibilità. È consigliabile impostare SQL Server Backup gestito in Microsoft Azure nel database perché la configurazione di backup gestito SQL Server in Microsoft Azure a livello di database consente di isolare le impostazioni ai database e le modifiche alle impostazioni predefinite influiscono su tutti gli altri database nell'istanza.
Specificare la replica di backup. L'impostazione di replica di backup preferita viene usata da SQL Server Backup gestito in Microsoft Azure per pianificare i backup. Per determinare se la replica corrente è la replica di backup preferita, usare la funzione sys.fn_hadr_backup_is_preferred_replica (Transact-SQL).
Se la replica secondaria è configurata come replica preferita, deve essere configurata in modo da avere almeno l'accesso per la connessione in sola lettura. I gruppi di disponibilità privi di accesso per la connessione ai database secondari non sono supportati. Per altre informazioni, vedere Configurare l'accesso in sola lettura in una replica di disponibilità (SQL Server).
Se si configura SQL Server backup gestito in Microsoft Azure dopo aver configurato il gruppo di disponibilità, SQL Server backup gestito in Microsoft Azure tenterà di copiare eventuali backup esistenti basati e copiarli nel contenitore di archiviazione. Se SQL Server backup gestito in Microsoft Azure non è in grado di trovare o accedere ai backup esistenti, verrà pianificato un backup completo del database. Questa operazione viene eseguita in modo particolare per ottimizzare le operazioni di backup per i database del gruppo di disponibilità.
È possibile considerare la disabilitazione delle impostazioni a livello di istanza se si sta creando un nuovo database di disponibilità e non si intende applicare le impostazioni a livello di istanza al database
Quando si usa la crittografia, usare lo stesso certificato in tutte le repliche. In questo modo vengono facilitate le operazioni di backup continue e ininterrotte in caso di failover su una replica diversa o di ripristini in quest'ultima.
Abilitare e configurare il backup gestito di SQL Server in Microsoft Azure per un database di disponibilità
Questa esercitazione descrive i passaggi per abilitare e configurare SQL Server Backup gestito in Microsoft Azure per un database (AGTestDB) nei computer Node1 e Node2, seguito da passaggi per abilitare il monitoraggio dello stato di integrità del SQL Server gestito in Microsoft Azure.
Creare un account di archiviazione di Azure: I backup vengono archiviati nel servizio di archiviazione BLOB di Azure. È prima necessario creare un account di archiviazione di Azure, se non ne è già disponibile uno. Per altre informazioni, vedere Creazione di un account di archiviazione di Azure. Prendere nota del nome dell'account di archiviazione, delle chiavi di accesso e dell'URL dell'account di archiviazione. Le informazioni sul nome dell'account di archiviazione e sulla chiave di accesso vengono utilizzate per creare le credenziali SQL. Le credenziali SQL vengono usate da SQL Server Backup gestito in Microsoft Azure durante le operazioni di backup per l'autenticazione all'account di archiviazione.
Creare una credenziale SQL: Creare una credenziale SQL usando il nome dell'account di archiviazione come identità e la chiave di accesso all'archiviazione come password.
Assicurarsi che il servizio SQL Server Agent sia avviato e in esecuzione: se non è in esecuzione, avviare SQL Server Agent. Per eseguire le operazioni di backup, il backup gestito di SQL Server a Microsoft Azure richiede che SQL Server Agent sia eseguito nell'istanza. Per assicurarsi che le operazioni in questione vengano eseguite regolarmente, è possibile impostare l'esecuzione automatica di SQL Agent.
Determinare il periodo di conservazione: Determinare il periodo di conservazione desiderato per i file di backup. Il periodo di memorizzazione viene specificato in giorni in un intervallo compreso tra 1 e 30. Il periodo di memorizzazione determina l'intervallo di tempo di recuperabilità del database.
Creare un certificato o una chiave asimmetrica da usare per la crittografia durante il backup: Creare il certificato nel primo nodo Node1 e quindi esportarlo in un file usando BACKUP CERTIFICATE (Transact-SQL). Nel nodo 2 creare un certificato utilizzando il file esportato dal nodo 1. Per altre informazioni sulla creazione di un certificato da un file, vedere l'esempio in CREATE CERTIFICATE (Transact-SQL).
Abilitare e configurare SQL Server Backup gestito in Microsoft Azure per AGTestDB in Node1: Avviare SQL Server Management Studio e connettersi all'istanza in Node1 in cui è installato il database di disponibilità. Nella finestra Query eseguire l'istruzione riportata di seguito dopo aver modificato i valori per il nome del database, l'URL di archiviazione, le credenziali SQL e il periodo di memorizzazione in base alle esigenze:
Use msdb; GO EXEC smart_admin.sp_set_db_backup @database_name='AGTestDB' ,@retention_days=30 ,@credential_name='MyCredential' ,@encryption_algorithm ='AES_128' ,@encryptor_type= 'Certificate' ,@encryptor_name='MyBackupCert' ,@enable_backup=1; GO
Per altre informazioni sulla creazione di un certificato per la crittografia, vedere il passaggio Crea un certificato di backup in Creare un backup crittografato.
Abilitare e configurare SQL Server Backup gestito in Microsoft Azure per AGTestDB in Node2: Avviare SQL Server Management Studio e connettersi all'istanza in Node2 in cui è installato il database di disponibilità. Nella finestra Query eseguire l'istruzione riportata di seguito dopo aver modificato i valori per il nome del database, l'URL di archiviazione, le credenziali SQL e il periodo di memorizzazione in base alle esigenze:
Use msdb; GO EXEC smart_admin.sp_set_db_backup @database_name='AGTestDB' ,@retention_days=30 ,@credential_name='MyCredential' ,@encryption_algorithm ='AES_128' ,@encryptor_type= 'Certificate' ,@encryptor_name='MyBackupCert' ,@enable_backup=1; GO
SQL Server Backup gestito in Microsoft Azure è ora abilitato nel database specificato. L'inizio delle operazioni di backup nel database può richiedere fino a 15 minuti. Il backup verrà eseguito nella replica di backup preferita.
Esaminare la configurazione predefinita dell'evento esteso: Esaminare la configurazione dell'evento esteso eseguendo l'istruzione Transact-SQL seguente nella replica che SQL Server Backup gestito in Microsoft Azure usa per pianificare i backup da. Si tratta in genere dell'impostazione della replica di backup preferita per il gruppo di disponibilità a cui appartiene il database.
SELECT * FROM smart_admin.fn_get_current_xevent_settings();
Per impostazione predefinita, Amministrazione gli eventi del canale operativo e analitico sono abilitati per impostazione predefinita e non possono essere disabilitati. Questa verifica dovrebbe essere sufficiente per monitorare gli eventi per i quali è richiesto un intervento manuale. È possibile abilitare gli eventi di debug, ma questi canali includono eventi informativi e di debug che SQL Server Backup gestito in Microsoft Azure usa per rilevare i problemi e risolverli. Per altre informazioni, vedere Monitorare SQL Server Backup gestito in Azure.
Abilitare e configurare la notifica per lo stato di integrità: SQL Server backup gestito in Microsoft Azure ha una stored procedure che crea un processo agente per inviare notifiche di posta elettronica di errori o avvisi che potrebbero richiedere attenzione. Per ricevere notifiche di questo tipo, è necessario eseguire la stored procedure per creare un processo di SQL Server Agent. Nei passaggi seguenti viene illustrato il processo per abilitare e configurare le notifiche tramite posta elettronica:
Configurare Posta elettronica database se non è già abilitato nell'istanza. Per altre informazioni, vedere Configurare Posta elettronica database.
Configurare la notifica di SQL Server Agent per l'uso di Posta elettronica database. Per altre informazioni, vedere Configure SQL Server Agent Mail to Use Database Mail.
Abilitare le notifiche di posta elettronica per ricevere avvisi ed errori di backup: nella finestra di query eseguire le istruzioni Transact-SQL seguenti:
EXEC msdb.smart_admin.sp_set_parameter @parameter_name = 'SSMBackup2WANotificationEmailIds', @parameter_value = '<email>'
Per altre informazioni e uno script di esempio completo, vedere Monitorare SQL Server Backup gestito in Azure.
Visualizzare i file di backup nell'account di archiviazione di Azure: Connettersi all'account di archiviazione da SQL Server Management Studio o dal portale di gestione di Azure. Verrà visualizzato un contenitore per l'istanza di SQL Server che ospita il database configurato per l'uso di SQL Server Backup gestito in Microsoft Azure. È anche possibile visualizzare un database e un backup del log entro 15 minuti per abilitare SQL Server Backup gestito in Microsoft Azure per il database.
Monitorare lo stato di integrità: È possibile monitorare tramite notifiche di posta elettronica configurate in precedenza o monitorare attivamente gli eventi registrati. Di seguito sono riportate alcune istruzioni Transact-SQL di esempio utilizzate per visualizzare gli eventi:
-- view all admin events Use msdb; Go DECLARE @startofweek datetime DECLARE @endofweek datetime SET @startofweek = DATEADD(Day, 1-DATEPART(WEEKDAY, CURRENT_TIMESTAMP), CURRENT_TIMESTAMP) SET @endofweek = DATEADD(Day, 7-DATEPART(WEEKDAY, CURRENT_TIMESTAMP), CURRENT_TIMESTAMP) DECLARE @eventresult TABLE (event_type nvarchar(512), event varchar (512), timestamp datetime ) INSERT INTO @eventresult EXEC smart_admin.sp_get_backup_diagnostics @begin_time = @startofweek, @end_time = @endofweek SELECT * from @eventresult WHERE event_type LIKE '%admin%'
-- to enable debug events Use msdb; Go EXEC smart_admin.sp_set_parameter 'FileRetentionDebugXevent', 'True'
-- View all events in the current week Use msdb; Go DECLARE @startofweek datetime DECLARE @endofweek datetime SET @startofweek = DATEADD(Day, 1-DATEPART(WEEKDAY, CURRENT_TIMESTAMP), CURRENT_TIMESTAMP) SET @endofweek = DATEADD(Day, 7-DATEPART(WEEKDAY, CURRENT_TIMESTAMP), CURRENT_TIMESTAMP) EXEC smart_admin.sp_get_backup_diagnostics @begin_time = @startofweek, @end_time = @endofweek;
I passaggi descritti in questa sezione sono specifici per configurare SQL Server Backup gestito in Microsoft Azure per la prima volta nel database. È possibile modificare le configurazioni esistenti usando la stessa stored procedure di sistema smart_admin.sp_set_db_backup e fornire i nuovi valori. Per altre informazioni, vedere SQL Server Backup gestito in Azure - Conservazione e impostazioni di archiviazione.
Considerazioni in caso di rimozione di un database dalla configurazione del gruppo di disponibilità AlwaysOn
Se un database viene rimosso dalla configurazione del gruppo di disponibilità AlwaysOn ed è ora un database autonomo, è consigliabile eseguire il backup usando smart_admin.sp_backup_on_demand (Transact-SQL). Quando si crea un backup del database in questo modo, stabilisce una nuova catena di backup e il file verrà inserito nel contenitore specifico dell'istanza anziché nel contenitore di disponibilità in cui i backup sono stati archiviati quando il database fa parte del gruppo di disponibilità.
Avviso
La recuperabilità del database in questo scenario dai backup precedenti alla modifica dello stato del gruppo di disponibilità non è garantita.