Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo argomento è un'esercitazione sulla configurazione del backup gestito di SQL Server in Microsoft Azure per i database che partecipano ai gruppi di disponibilità AlwaysOn.
Configurazioni del gruppo di disponibilità
Il backup gestito di SQL Server in Microsoft Azure è supportato per i database del gruppo di disponibilità, indipendentemente dal fatto che le repliche siano tutte configurate in locale o interamente in Azure o un'implementazione ibrida tra l'ambiente locale e una o più macchine virtuali di Azure. Tuttavia, potrebbe essere necessario considerare quanto segue per una o più implementazioni:
Frequenza di backup del log: la frequenza del backup del log dipende sia dal tempo che dall'aumento del log. Ad esempio, il backup del log viene eseguito una volta ogni 2 ore, a meno che lo spazio del log usato entro il periodo di due ore sia di 5 MB o più. Questo vale per tutte le implementazioni, locali, cloud o ibrido.
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 dei database secondari e se i database secondari sono impostati sulla replica sincrona, questo può causare una crescita dei log nel database primario. Se le repliche secondarie sono impostate sulla replica sincrona, i database secondari potrebbero non essere in grado di rimanere aggiornati a causa della latenza di rete, con conseguente perdita di dati in caso di failover nella replica secondaria.
Configurazione del backup gestito di SQL Server in Microsoft Azure per i database di disponibilità.
Autorizzazioni :
Richiede l'appartenenza a db_backupoperator ruolo del database, con autorizzazioni ALTER ANY CREDENTIAL e
EXECUTE
autorizzazioni per sp_delete_backuphistorystored procedure.Sono necessarie autorizzazioni SELECT per la funzione smart_admin.fn_get_current_xevent_settings.
Sono necessarie
EXECUTE
autorizzazioni per la stored procedure smart_admin.sp_get_backup_diagnostics . Inoltre, richiedeVIEW SERVER STATE
autorizzazioni perché chiama internamente altri oggetti di sistema che richiedono questa autorizzazione.Sono necessarie
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 il backup gestito di SQL Server in Microsoft Azure. Una guida dettagliata passo passo è descritta più avanti in questo argomento.
Dopo aver creato il gruppo di disponibilità, configurare la replica di backup preferita. Questa impostazione per il gruppo di disponibilità viene usata anche da Backup gestito di SQL Server in Microsoft Azure per determinare quale replica usare per il backup. Per istruzioni dettagliate su come configurare le preferenze di backup, vedere Configurare il backup nelle repliche di disponibilità (SQL Server). Se si sta creando un nuovo gruppo di disponibilità AlwaysOn, vedere Introduzione ai gruppi di disponibilità AlwaysOn (SQL Server).
Configurare l'accesso alla connessione di 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 Replica di backup. L'impostazione della replica di backup preferita viene usata da SQL Server Managed Backup su Microsoft Azure per determinare quale database usare per la pianificazione dei backup. 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, eseguire Backup gestito di SQL Server in Microsoft Azure per il database utilizzando la stored procedure smart-admin.sp_set_db_backup.
Comportamento di Backup gestito di SQL Server in Microsoft Azure dopo un failover: Il backup gestito di SQL Server in Microsoft Azure continuerà a funzionare e manterrà le copie di backup e la recuperabilità dopo un evento di failover. Non è necessaria alcuna azione specifica dopo un failover.
Considerazioni e requisiti:
La configurazione del backup gestito di SQL Server in Microsoft Azure per i database che fanno parte del gruppo di disponibilità AlwaysOn richiede considerazioni e requisiti specifici. Di seguito è riportato un elenco di considerazioni e requisiti:
Le impostazioni di configurazione di Backup gestito di 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à. A tale scopo, è possibile impostare le stesse configurazioni di Backup gestito di SQL Server su Microsoft Azure per il database primario e tutte le repliche a livello di database oppure impostando le stesse impostazioni predefinite di Backup gestito di SQL Server su Microsoft Azure in tutti i nodi che partecipano ai gruppi di disponibilità. È consigliabile impostare Backup gestito di SQL Server su Microsoft Azure nel database perché la configurazione di Backup gestito di SQL Server in Microsoft Azure a livello di database consente di isolare le impostazioni per i database e le modifiche apportate alle impostazioni predefinite influiscono su tutti gli altri database nell'istanza di .
Specificare la replica di backup. L'impostazione preferita per la replica di backup viene utilizzata 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 per avere almeno l'accesso alla connessione in sola lettura. I gruppi di disponibilità che non hanno accesso alla 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 il backup gestito di SQL Server in Microsoft Azure dopo aver configurato il gruppo di disponibilità, backup gestito di SQL Server in Microsoft Azure tenterà di copiare eventuali backup esistenti basati e copiarli nel contenitore di archiviazione. Se il backup gestito di SQL Server in Microsoft Azure non riesce a trovare o accedere ai backup esistenti, pianifica un backup completo del database. Questa operazione viene eseguita in modo specifico per ottimizzare le operazioni di backup per i database del gruppo di disponibilità.
È consigliabile disabilitare le 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. Ciò facilita le operazioni di backup continue e ininterrotte in caso di failover o ripristini in una replica diversa.
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 backup gestito di SQL Server in Microsoft Azure per un database (AGTestDB) nei computer Node1 e Node2, seguiti da passaggi per abilitare il monitoraggio dello stato di integrità del backup gestito di SQL Server 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 e sulla chiave di accesso dell'account di archiviazione vengono usate per creare credenziali SQL. Le credenziali SQL vengono usate dal backup gestito di SQL Server in Microsoft Azure durante le operazioni di backup per l'autenticazione nell'account di archiviazione.
Creare credenziali SQL: Creare una credenziale SQL usando il nome dell'account di archiviazione come identità e la chiave di accesso alle risorse di archiviazione come password.
Assicurarsi che il servizio SQL Server Agent sia avviato e in esecuzione : avviare SQL Server Agent se non è in esecuzione. Il backup gestito di SQL Server in Microsoft Azure richiede l'esecuzione di SQL Server Agent nell'istanza per eseguire operazioni di backup. È possibile impostare SQL Agent per l'esecuzione automatica per assicurarsi che le operazioni di backup possano verificarsi regolarmente.
Determinare il periodo di conservazione: Determinare il periodo di conservazione desiderato per i file di backup. Il periodo di conservazione viene specificato in giorni e può variare da 1 a 30. Il periodo di conservazione determina l'intervallo di tempo di ripristino per il 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 usando 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 il backup gestito di SQL Server 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 di query eseguire l'istruzione seguente dopo aver modificato i valori per il nome del database, l'URL di archiviazione, le credenziali SQL e il periodo di conservazione in base ai requisiti:
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 Creare un certificato di backup in Creare un backup crittografato.
Abilitare e configurare il backup gestito di SQL Server 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 di query eseguire l'istruzione seguente dopo aver modificato i valori per il nome del database, l'URL di archiviazione, le credenziali SQL e il periodo di conservazione in base ai requisiti:
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
Backup gestito di SQL Server 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 degli eventi estesi eseguendo l'istruzione transact-SQL seguente nella replica da cui viene usato il backup gestito di SQL Server in Microsoft Azure per pianificare i backup. Si tratta in genere dell'impostazione di replica di backup preferita per il gruppo di disponibilità a cui appartiene il database.
SELECT * FROM smart_admin.fn_get_current_xevent_settings();
Si noterà che gli eventi del canale admin, 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 usati da Backup gestito di SQL Server in Microsoft Azure per rilevare i problemi e risolverli. Per altre informazioni, vedere Monitorare il backup gestito di SQL Server in Azure.
Abilitare e configurare la notifica per lo stato di integrità: Backup gestito di SQL Server in Microsoft Azure include una stored procedure che crea un'attività dell'agente per inviare tramite e-mail notifiche di errori o avvisi che potrebbero richiedere attenzione. Per ricevere tali notifiche, è necessario abilitare l'esecuzione della stored procedure che crea un processo di SQL Server Agent. Nei passaggi seguenti viene illustrato il processo per abilitare e configurare le notifiche tramite posta elettronica:
Configurare Mail di Database qualora non sia già abilitato nell'istanza. Per altre informazioni, vedere Configurare Posta elettronica database.
Configurare la notifica di SQL Server Agent per utilizzare Database Mail. Per altre informazioni, vedere Configure SQL Server Agent Mail to Use Database Mail.
Abilitare notifiche tramite posta elettronica per ricevere errori e avvisi di backup : nella finestra Query eseguire le istruzioni Transact-SQL riportate di seguito:
EXEC msdb.smart_admin.sp_set_parameter @parameter_name = 'SSMBackup2WANotificationEmailIds', @parameter_value = '<email>'
Per altre informazioni e uno script di esempio completo, vedere Monitorare il backup gestito di SQL Server 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 Backup gestito di SQL Server in Microsoft Azure. È anche possibile visualizzare un database e un backup del log entro 15 minuti dall'abilitazione del backup gestito di SQL Server in Microsoft Azure per il database.
Monitorare lo stato di integrità : è possibile eseguire il monitoraggio attraverso 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 la configurazione del backup gestito di SQL Server 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 specificare i nuovi valori. Per altre informazioni, vedere Backup gestito di SQL Server in Azure - Impostazioni di conservazione e archiviazione.
Considerazioni sulla 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, viene stabilita una nuova catena di backup e il file verrà inserito nel contenitore specifico dell'istanza anziché nel contenitore di disponibilità in cui sono stati archiviati i backup quando il database faceva parte del gruppo di disponibilità.
Avvertimento
La recuperabilità del database in questo scenario dai backup precedenti alla modifica dello stato del gruppo di disponibilità non è garantita.