Ripristinare un database SQL di Azure o eseguire il failover in un database secondarioRestore an Azure SQL Database or failover to a secondary

Il database SQL di Azure offre le funzionalità riportate di seguito per il ripristino da un'interruzione del servizio:Azure SQL Database offers the following capabilities for recovering from an outage:

Per informazioni sugli scenari di continuità aziendale e sulle funzionalità che supportano questi scenari, vedere Continuità aziendale del database SQL di Azure.To learn about business continuity scenarios and the features supporting these scenarios, see Business continuity.

Prepararsi per un evento di interruzione del servizioPrepare for the event of an outage

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.For success with recovery to another data region using either active geo-replication or geo-redundant backups, you need to prepare a server in another data center outage to become the new primary server should the need arise as well as have well-defined steps documented and tested to ensure a smooth recovery. La procedura di preparazione comprende:These preparation steps include:

  • Identificare il server logico in un'altra area perché diventi il nuovo server primario.Identify the logical server in another region to become the new primary server. Con la replica geografica attiva, questo sarà almeno uno o forse ognuno dei server secondari.With active geo-replication, this will be at least one and perhaps each of the secondary servers. Per il ripristino geografico, questo sarà in genere un server di un'area abbinata all'area in cui si trova il database.For geo-restore, this will generally be a server in the paired region for the region in which your database is located.
  • Identificare e definire, facoltativamente, le regole del firewall a livello di server necessarie agli utenti per accedere al nuovo database primario.Identify, and optionally define, the server-level firewall rules needed on for users to access the new primary database.
  • Determinare come si desidera reindirizzare gli utenti al nuovo server primario, ad esempio tramite modifica delle stringhe di connessione o delle voci del DNS.Determine how you are going to redirect users to the new primary server, such as by changing connection strings or by changing DNS entries.
  • 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.Identify, and optionally create, the logins that must be present in the master database on the new primary server, and ensure these logins have appropriate permissions in the master database, if any. Per altre informazioni, vedere Come gestire la sicurezza del database SQL di Azure dopo il ripristino di emergenzaFor more information, see SQL Database security after disaster recovery
  • Stabilire le regole di avviso che dovranno essere aggiornata per eseguire il mapping verso il nuovo database primario.Identify alert rules that will need to be updated to map to the new primary database.
  • Documentare la configurazione di controllo nel database primario correnteDocument the auditing configuration on the current primary database
  • Esercitazione per il ripristino di emergenza.Perform a disaster recovery drill. 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.To simulate an outage for geo-restore, you can delete or rename the source database to cause application connectivity failure. 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.To simulate an outage for active geo-replication, you can disable the web application or virtual machine connected to the database or failover the database to cause application connectivity failures.

Quando avviare il ripristinoWhen to initiate recovery

L'operazione di ripristino ha un impatto sull'applicazione.The recovery operation impacts the application. Richiede la modifica della stringa di connessione SQL o il reindirizzamento tramite DNS e può comportare una perdita di dati permanente.It requires changing the SQL connection string or redirection using DNS and could result in permanent data loss. Pertanto, è necessario eseguirla solo quando è probabile che l'interruzione del servizio duri più a lungo dell'obiettivo del tempo di ripristino dell'applicazione.Therefore, it should be done only when the outage is likely to last longer than your application's recovery time objective. 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:When the application is deployed to production you should perform regular monitoring of the application health and use the following data points to assert that the recovery is warranted:

  1. Si è verificato un errore di connettività permanente dal livello applicazione al database.Permanent connectivity failure from the application tier to the database.
  2. Il portale di Azure visualizza un avviso relativo a un evento imprevisto nell'area con un impatto importante.The Azure portal shows an alert about an incident in the region with broad impact.
  3. Il server di database SQL di Azure è contrassegnato come danneggiato.The Azure SQL Database server is marked as degraded.

A seconda della tolleranza dell'applicazione ai tempi di inattività e delle eventuali responsabilità aziendali è possibile prendere in considerazione le opzioni di ripristino seguenti.Depending on your application tolerance to downtime and possible business liability you can consider the following recovery options.

Usare Get Recoverable Database (LastAvailableBackupDate), che consente di ottenere l'ultimo punto di ripristino con replica geografica.Use the Get Recoverable Database (LastAvailableBackupDate) to get the latest Geo-replicated restore point.

Attendere il ripristino del servizioWait for service recovery

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.The Azure teams work diligently to restore service availability as quickly as possible but depending on the root cause it can take hours or days. Se l'applicazione può tollerare tempi di inattività significativi è possibile attendere semplicemente il completamento del ripristino.If your application can tolerate significant downtime you can simply wait for the recovery to complete. In tal caso, non è necessaria alcuna azione da parte dell'utente.In this case, no action on your part is required. È possibile vedere lo stato corrente del servizio nel dashboard per l'integrità dei servizi di Azure.You can see the current service status on our Azure Service Health Dashboard. Dopo il ripristino dell'area verrà ripristinata la disponibilità dell'applicazione.After the recovery of the region your application’s availability will be restored.

Failover al database secondario con replica geograficaFail over to geo-replicated secondary database

Se i tempi di inattività dell'applicazione possono comportare una responsabilità aziendale, è consigliabile usare database con replica geografica nell'applicazione.If your application’s downtime can result in business liability you should be using geo-replicated database(s) in your application. Questo permette all'applicazione di ripristinare rapidamente la disponibilità in un'area diversa in caso di interruzione del servizio.It will enable the application to quickly restore availability in a different region in case of an outage. Informazioni su come configurare la replica geografica.Learn how to configure geo-replication.

Per ripristinare la disponibilità dei database è necessario avviare il failover nel database secondario con replica geografica usando uno dei metodi supportati.To restore availability of the database(s) you need to initiate the failover to the geo-replicated secondary using one of the supported methods.

Per eseguire il failover in un database secondario con replica geografica, seguire una di queste procedure:Use one of the following guides to fail over to a geo-replicated secondary database:

Ripristino tramite il ripristino geograficoRecover using geo-restore

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.If your application’s downtime does not result in business liability you can use geo-restore as a method to recover your application database(s). Questo metodo crea una copia del database dal backup con ridondanza geografica più recente.It creates a copy of the database from its latest geo-redundant backup.

Configurare il database dopo il ripristinoConfigure your database after recovery

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.If you are using either geo-replication failover or geo-restore to recover from an outage, you must make sure that the connectivity to the new databases is properly configured so that the normal application function can be resumed. Di seguito è riportato un elenco di controllo di attività per fare in modo che il database ripristinato sia pronto per la produzione.This is a checklist of tasks to get your recovered database production ready.

Aggiornare le stringhe di connessioneUpdate connection strings

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.Because your recovered database will reside in a different server, you need to update your application’s connection string to point to that server.

Per altre informazioni sulla modifica delle stringhe di connessione, vedere il linguaggio di sviluppo appropriato per le raccolte di connessioni.For more information about changing connection strings, see the appropriate development language for your connection library.

Configurare le regole firewallConfigure Firewall Rules

Verificare che le regole firewall configurate nel server e nel database corrispondano a quelle configurate nel server primario e nel database primario.You need to make sure that the firewall rules configured on server and on the database match those that were configured on the primary server and primary database. Per altre informazioni, vedere Procedura: Configurare le impostazioni del firewall (Database SQL di Azure).For more information, see How to: Configure Firewall Settings (Azure SQL Database).

Configurare gli account di accesso e gli utenti del databaseConfigure logins and database users

Verificare che tutti gli account di accesso usati dall'applicazione siano presenti nel server che ospita il database ripristinato.You need to make sure that all the logins used by your application exist on the server which is hosting your recovered database. Per altre informazioni, vedere Configurazione della sicurezza per la replica geografica.For more information, see Security Configuration for geo-replication.

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.You should configure and test your server firewall rules and logins (and their permissions) during a disaster recovery drill. Questi oggetti a livello di server e la relativa configurazione potrebbero non essere disponibili durante l'interruzione del servizio.These server-level objects and their configuration may not be available during the outage.

Avvisi di telemetria di configurazioneSetup telemetry alerts

Verificare che le impostazioni della regola di avviso esistenti vengano aggiornate per il mapping al database ripristinato e al nuovo server.You need to make sure your existing alert rule settings are updated to map to the recovered database and the different server.

Per altre informazioni sulle regole di avviso per il database, vedere Ricevere notifiche di avviso e Tracciare l’integrità del servizio.For more information about database alert rules, see Receive Alert Notifications and Track Service Health.

Attivare il controlloEnable auditing

Se è necessario il controllo di accesso al database, occorre attivare il controllo dopo il ripristino del database.If auditing is required to access your database, you need to enable Auditing after the database recovery. Per altre informazioni, vedere l'articolo sul controllo del database.For more information, see Database auditing.

Passaggi successiviNext steps