Ripristinare un database SQL di Azure o eseguire il failover in un database secondario

Il database SQL di Azure offre le funzionalità riportate di seguito per il ripristino da un'interruzione del servizio:

Per informazioni sugli scenari di continuità aziendale e sulle funzionalità che supportano questi scenari, vedere Continuità aziendale del database SQL di Azure.

Prepararsi per un evento di interruzione del servizio

Per completare correttamente il ripristino su un'altra area dati tramite la replica geografica attiva o i backup con ridondanza geografica, è necessario preparare un server in un altro data center perché diventi il nuovo server primario in caso di necessità, nonché procedure ben definite, documentate e testate per garantire un ripristino senza problemi. La procedura di preparazione comprende:

  • Identificare il server logico in un'altra area perché diventi il nuovo server primario. Con la replica geografica attiva, questo sarà almeno uno o forse ognuno dei server secondari. Per il ripristino geografico, questo sarà in genere un server di un'area abbinata all'area in cui si trova il database.
  • Identificare e definire, facoltativamente, le regole del firewall a livello di server necessarie agli utenti per accedere al nuovo database primario.
  • Determinare come si desidera reindirizzare gli utenti al nuovo server primario, ad esempio tramite modifica delle stringhe di connessione o delle voci del DNS.
  • Identificare e, facoltativamente, creare gli account di accesso presenti nel database master nel nuovo server primario e verificare che questi account di accesso dispongano delle autorizzazioni appropriate nel database master, se necessarie. Per altre informazioni, vedere Come gestire la sicurezza del database SQL di Azure dopo il ripristino di emergenza
  • Stabilire le regole di avviso che dovranno essere aggiornata per eseguire il mapping verso il nuovo database primario.
  • Documentare la configurazione di controllo nel database primario corrente
  • Esercitazione per il ripristino di emergenza. Per simulare un'interruzione del servizio di ripristino geografico, è possibile eliminare o rinominare il database di origine per provocare un errore di connettività dell'applicazione. Per simulare un'interruzione del servizio per la replica geografica attiva, è possibile disabilitare l'applicazione Web o la macchina virtuale connessa al database o il failover del database per causare errori di connettività dell'applicazione.

Quando avviare il ripristino

L'operazione di ripristino ha un impatto sull'applicazione. Richiede la modifica della stringa di connessione SQL o il reindirizzamento tramite DNS e può comportare una perdita di dati permanente. Pertanto, è necessario eseguirla solo quando è probabile che l'interruzione del servizio duri più a lungo dell'obiettivo del tempo di ripristino dell'applicazione. Quando l'applicazione viene distribuita nell'ambiente di produzione, è consigliabile eseguire il monitoraggio regolare dell'integrità dell'applicazione e usare i punti dati seguenti per determinare se il ripristino è possibile:

  1. Si è verificato un errore di connettività permanente dal livello applicazione al database.
  2. Il portale di Azure visualizza un avviso relativo a un evento imprevisto nell'area con un impatto importante.
  3. Il server di database SQL di Azure è contrassegnato come danneggiato.

A seconda della tolleranza dell'applicazione ai tempi di inattività e delle eventuali responsabilità aziendali è possibile prendere in considerazione le opzioni di ripristino seguenti.

Usare Get Recoverable Database (LastAvailableBackupDate), che consente di ottenere l'ultimo punto di ripristino con replica geografica.

Attendere il ripristino del servizio

I team di Azure puntano a ripristinare la disponibilità del servizio quanto più rapidamente possibile, ma questo può richiedere ore o giorni a seconda della causa radice. Se l'applicazione può tollerare tempi di inattività significativi è possibile attendere semplicemente il completamento del ripristino. In tal caso, non è necessaria alcuna azione da parte dell'utente. È possibile vedere lo stato corrente del servizio nel dashboard per l'integrità dei servizi di Azure. Dopo il ripristino dell'area verrà ripristinata la disponibilità dell'applicazione.

Failover al database secondario con replica geografica

Se i tempi di inattività dell'applicazione possono comportare una responsabilità aziendale, è consigliabile usare database con replica geografica nell'applicazione. Questo permette all'applicazione di ripristinare rapidamente la disponibilità in un'area diversa in caso di interruzione del servizio. Informazioni su come configurare la replica geografica.

Per ripristinare la disponibilità dei database è necessario avviare il failover nel database secondario con replica geografica usando uno dei metodi supportati.

Per eseguire il failover in un database secondario con replica geografica, seguire una di queste procedure:

Ripristino tramite il ripristino geografico

Se i tempi di inattività dell'applicazione non comportano una responsabilità aziendale è possibile usare il ripristino geografico come metodo per il ripristino dei database dell'applicazione. Questo metodo crea una copia del database dal backup con ridondanza geografica più recente.

Configurare il database dopo il ripristino

Se si esegue il ripristino da un'interruzione del servizio usando il failover con replica geografica o il ripristino geografico, è necessario assicurarsi che la connettività ai nuovi database sia configurata correttamente per poter riprendere il normale funzionamento dell'applicazione. Di seguito è riportato un elenco di controllo di attività per fare in modo che il database ripristinato sia pronto per la produzione.

Aggiornare le stringhe di connessione

Poiché il database ripristinato si troverà in un server diverso, è necessario aggiornare la stringa di connessione dell'applicazione in modo che punti a tale server.

Per altre informazioni sulla modifica delle stringhe di connessione, vedere il linguaggio di sviluppo appropriato per le raccolte di connessioni.

Configurare le regole firewall

Verificare che le regole firewall configurate nel server e nel database corrispondano a quelle configurate nel server primario e nel database primario. Per altre informazioni, vedere Procedura: Configurare le impostazioni del firewall (Database SQL di Azure).

Configurare gli account di accesso e gli utenti del database

Verificare che tutti gli account di accesso usati dall'applicazione siano presenti nel server che ospita il database ripristinato. Per altre informazioni, vedere Configurazione della sicurezza per la replica geografica.

Nota

È necessario configurare e testare le regole del firewall del server e gli account di accesso (con le relative autorizzazioni) durante un'analisi di ripristino di emergenza. Questi oggetti a livello di server e la relativa configurazione potrebbero non essere disponibili durante l'interruzione del servizio.

Avvisi di telemetria di configurazione

Verificare che le impostazioni della regola di avviso esistenti vengano aggiornate per il mapping al database ripristinato e al nuovo server.

Per altre informazioni sulle regole di avviso per il database, vedere Ricevere notifiche di avviso e Tracciare l’integrità del servizio.

Attivare il controllo

Se è necessario il controllo di accesso al database, occorre attivare il controllo dopo il ripristino del database. Per altre informazioni, vedere l'articolo sul controllo del database.

Passaggi successivi