Eseguire il backup e il ripristino in Database di Azure per MySQL

  • Articolo

SI APPLICA A: Database di Azure per MySQL - Server singolo

Importante

Database di Azure per MySQL server singolo si trova nel percorso di ritiro. È consigliabile eseguire l'aggiornamento a Database di Azure per MySQL server flessibile. Per altre informazioni sulla migrazione a Database di Azure per MySQL server flessibile, vedere Che cosa accade a Database di Azure per MySQL server singolo?

Database di Azure per MySQL crea automaticamente backup del server e li archivia in un archivio con ridondanza locale o geografica configurato dall'utente. I backup possono essere usati per ripristinare il server a un momento specifico. Il backup e il ripristino sono una parte essenziale di qualsiasi strategia di continuità aziendale, perché proteggono i dati dal danneggiamento o dall'eliminazione accidentale.

Backup

Database di Azure per MySQL esegue il backup dei file di dati e del log delle transazioni. Questi backup consentono di ripristinare un server a qualsiasi momento specifico all'interno del periodo di conservazione dei backup configurato. Il periodo di conservazione dei backup predefinito è di sette giorni. Facoltativamente, è possibile configurarla fino a 35 giorni. Tutti i backup vengono crittografati con crittografia AES a 256 bit.

Questi file di backup non sono esposti dall'utente e non possono essere esportati. Questi backup possono essere usati solo per le operazioni di ripristino in Database di Azure per MySQL. È possibile usare mysqldump per copiare un database.

Il tipo di backup e la frequenza dipendono dall'archiviazione back-end per i server.

Tipo e frequenza di backup

Server di archiviazione di base

L'archiviazione Basic è l'archiviazione back-end che supporta i server di livello Basic. I backup nei server di archiviazione Basic sono basati su snapshot. Uno snapshot completo del database viene eseguito ogni giorno. Non sono presenti backup differenziali eseguiti per i server di archiviazione di base e tutti i backup di snapshot sono solo backup completi del database.

I backup del log delle transazioni vengono eseguiti ogni cinque minuti.

Server di archiviazione per utilizzo generico v1 (supporta fino a 4 TB di archiviazione)

L'archiviazione per utilizzo generico è l'archiviazione back-end che supporta il server livello Utilizzo generico e Ottimizzato per la memoria. Per i server con archiviazione per utilizzo generico fino a 4 TB, i backup completi vengono eseguiti una volta ogni settimana. I backup differenziali vengono eseguiti due volte al giorno. I backup del log delle transazioni vengono eseguiti ogni cinque minuti. I backup nell'archiviazione per utilizzo generico fino a 4 TB di archiviazione non sono basati su snapshot e utilizzano la larghezza di banda di I/O al momento del backup. Per i database di grandi dimensioni (> 1 TB) nell'archiviazione da 4 TB, è consigliabile prendere in considerazione

  • Provisioning di più operazioni di I/O per l'account per operazioni di I/O di backup
  • In alternativa, eseguire la migrazione all'archiviazione per utilizzo generico che supporta fino a 16 TB di archiviazione se l'infrastruttura di archiviazione sottostante è disponibile nelle aree di Azure preferite. Non sono previsti costi aggiuntivi per l'archiviazione per utilizzo generico che supporta fino a 16 TB di archiviazione. Per assistenza per la migrazione all'archiviazione da 16 TB, aprire un ticket di supporto da portale di Azure.

Server di archiviazione per utilizzo generico v2 (supporta fino a 16 TB di archiviazione)

In un subset di aree di Azure, tutti i nuovi server di cui è stato effettuato il provisioning possono supportare l'archiviazione per utilizzo generico fino a 16 TB di archiviazione. In altre parole, l'archiviazione fino a 16 TB di archiviazione è l'archiviazione per utilizzo generico predefinita per tutte le aree in cui è supportata. I backup in questi server di archiviazione da 16 TB sono basati su snapshot. Il primo backup dello snapshot viene pianificato subito dopo la creazione di un server. I backup dello snapshot vengono eseguiti una volta al giorno. I backup del log delle transazioni vengono eseguiti ogni cinque minuti.

Per altre informazioni sull'archiviazione di base e per utilizzo generico, vedere la documentazione sull'archiviazione.

Conservazione dei backup

I backup vengono conservati in base all'impostazione del periodo di conservazione dei backup nel server. È possibile selezionare un periodo di conservazione compreso tra 7 e 35 giorni. Il periodo di conservazione predefinito è 7 giorni. È possibile impostare il periodo di conservazione durante la creazione del server o versioni successive aggiornando la configurazione del backup usando portale di Azure o l'interfaccia della riga di comando di Azure.

Il periodo di conservazione dei backup determina quanto è possibile tornare indietro nel tempo con un ripristino temporizzato, essendo il ripristino basato sui backup disponibili. Il periodo di conservazione dei backup può anche essere considerato come una finestra di ripristino dal punto di vista del ripristino. Tutti i backup necessari per eseguire un ripristino temporizzato entro il periodo di conservazione dei backup vengono conservati nell'archiviazione di backup. Ad esempio, se il periodo di conservazione dei backup è impostato su 7 giorni, la finestra di ripristino viene considerata gli ultimi 7 giorni. In questo scenario vengono conservati tutti i backup necessari per ripristinare il server negli ultimi 7 giorni. Con una finestra di conservazione dei backup di sette giorni:

  • I server di archiviazione per utilizzo generico v1 (che supportano fino a 4 TB di archiviazione) manterranno fino a 2 backup completi del database, tutti i backup differenziali e i backup del log delle transazioni eseguiti dal primo backup completo del database.
  • I server di archiviazione per utilizzo generico v2 (che supportano fino a 16 TB di archiviazione) manterranno gli snapshot completi del database e i backup del log delle transazioni negli ultimi 8 giorni.

Conservazione a lungo termine

La conservazione a lungo termine dei backup oltre 35 giorni non è attualmente supportata in modo nativo dal servizio. È possibile usare mysqldump per eseguire backup e archiviarli per la conservazione a lungo termine. Il team di supporto ha registrato un articolo dettagliato per condividere il modo in cui è possibile ottenerlo.

opzioni di ridondanza per il backup

Nei livelli Utilizzo generico e Con ottimizzazione per la memoria, Database di Azure per MySQL offre la possibilità di scegliere tra archiviazione dei backup con ridondanza locale o con ridondanza geografica. Quando vengono archiviati in un archivio di backup con ridondanza geografica, i backup non solo vengono archiviati nell'area in cui è ospitato il server, ma vengono anche replicati in un data center abbinato. Questa ridondanza geografica offre una migliore protezione e la possibilità di ripristinare il server in un'area diversa in caso di emergenza. Il livello Basic offre solo l'archiviazione dei backup con ridondanza locale.

Nota

Per le aree seguenti- India centrale, Francia centrale, Emirati Arabi Uniti settentrionali, Sudafrica settentrionale; L'archiviazione per utilizzo generico v2 è disponibile in anteprima pubblica. Se si crea un server di origine nell'archiviazione per utilizzo generico v2 (supporto fino a 16 TB di archiviazione) nelle aree indicate in precedenza, l'abilitazione del backup con ridondanza geografica non è supportata.

Passaggio dall'archiviazione di backup con ridondanza locale a quella con ridondanza geografica

La configurazione dell'archiviazione con ridondanza locale o geografica per il backup è consentita solo durante la creazione del server. Dopo il provisioning del server, non è possibile modificare l'opzione di ridondanza per l'archivio di backup. Per spostare l'archiviazione di backup dall'archiviazione con ridondanza locale all'archiviazione con ridondanza geografica, la creazione di un nuovo server e la migrazione dei dati tramite dump e ripristino è l'unica opzione supportata.

Costo dell'archiviazione dei backup

Database di Azure per MySQL offre fino al 100% delle risorse di archiviazione del server di cui è stato effettuato il provisioning come archivio di backup senza costi aggiuntivi. Tutte le risorse di archiviazione di backup aggiuntive usate vengono addebitate in GB al mese. Ad esempio, se è stato effettuato il provisioning di un server con 250 GB di spazio di archiviazione, sono disponibili 250 GB di spazio di archiviazione aggiuntivo per i backup del server senza costi aggiuntivi. Archiviazione utilizzati per i backup più di 250 GB viene addebitato in base al modello tariffario.

È possibile usare la metrica Backup Archiviazione usata in Monitoraggio di Azure disponibile tramite il portale di Azure per monitorare l'archiviazione di backup utilizzata da un server. La metrica Backup Archiviazione usata rappresenta la somma dello spazio di archiviazione utilizzato da tutti i backup completi del database, i backup differenziali e i backup del log conservati in base al periodo di conservazione dei backup impostato per il server. La frequenza dei backup è gestita dal servizio e spiegata in precedenza. Un'intensa attività transazionale sul server può causare un aumento dell'uso dell'archivio di backup indipendentemente dalle dimensioni totali del database. Per l'archiviazione con ridondanza geografica, l'utilizzo dell'archiviazione di backup è due volte quello dell'archiviazione con ridondanza locale.

Il mezzo principale per controllare il costo dell'archiviazione di backup consiste nell'impostare il periodo di conservazione dei backup appropriato e scegliere le opzioni di ridondanza del backup appropriate per soddisfare gli obiettivi di ripristino desiderati. È possibile selezionare un periodo di conservazione compreso tra 7 e 35 giorni. I server per utilizzo generico e ottimizzato per la memoria possono scegliere di disporre di archiviazione con ridondanza geografica per i backup.

Ripristino

In Database di Azure per MySQL, l'esecuzione di un ripristino crea un nuovo server dai backup del server originale e ripristina tutti i database contenuti nel server. Il ripristino non è attualmente supportato se lo stato del server originale è arrestato.

Sono disponibili due tipi di ripristino:

  • Il ripristino temporizzato è disponibile con entrambe le opzioni di ridondanza del backup e crea un nuovo server nella stessa area del server originale usando la combinazione di backup completi e del log delle transazioni.
  • Il ripristino geografico è disponibile solo se il server è stato configurato per l'archiviazione con ridondanza geografica e consente di ripristinare il server in un'area diversa usando il backup più recente eseguito.

Il tempo stimato per il ripristino del server dipende da diversi fattori:

  • Dimensioni dei database
  • Il numero dei log delle transazioni interessate
  • La quantità di attività che deve essere ripetuta per il ripristino al punto di ripristino
  • La larghezza di banda di rete se il ripristino avviene in un'area diversa
  • Il numero di richieste simultanee di ripristino in corso di elaborazione nell'area di destinazione
  • Presenza di chiave primaria nelle tabelle del database. Per un ripristino più rapido, è consigliabile aggiungere la chiave primaria per tutte le tabelle nel database. Per verificare se le tabelle hanno la chiave primaria, è possibile usare la query seguente:
select tab.table_schema as database_name, tab.table_name from information_schema.tables tab left join information_schema.table_constraints tco on tab.table_schema = tco.table_schema and tab.table_name = tco.table_name and tco.constraint_type = 'PRIMARY KEY' where tco.constraint_type is null and tab.table_schema not in('mysql', 'information_schema', 'performance_schema', 'sys') and tab.table_type = 'BASE TABLE' order by tab.table_schema, tab.table_name;

Per un database molto di grandi dimensioni o molto attivo il ripristino potrebbe richiedere diverse ore. Se si verifica un'interruzione prolungata in un'area, è possibile che venga avviato un numero elevato di richieste di ripristino geografico per il ripristino di emergenza. In presenza di numerose richieste, i tempi di recupero dei database in tale area possono aumentare. Per la maggior parte dei database, il ripristino richiede meno di 12 ore.

Importante

I server eliminati possono essere ripristinati solo entro cinque giorni dall'eliminazione dopo la quale i backup vengono eliminati. È possibile accedere e ripristinare il backup del database solo dalla sottoscrizione di Azure che ospita il server. Per ripristinare un server eliminato, vedere i passaggi documentati. Per proteggere le risorse del server, post-distribuzione, da eliminazioni accidentali o modifiche impreviste, gli amministratori possono sfruttare blocchi di gestione.

Ripristino temporizzato

Indipendentemente dall'opzione di ridondanza per il backup scelta, è possibile eseguire il ripristino a qualsiasi momento specifico all'interno del periodo di conservazione dei backup. Verrà creato un nuovo server nella stessa area di Azure del server originale, nonché con la stessa configurazione in termini di piano tariffario, generazione di calcolo, numero di vCore, dimensioni di archiviazione, periodo di conservazione dei backup e opzione di ridondanza per il backup.

Nota

Esistono due parametri del server che vengono reimpostati sui valori predefiniti (e non vengono copiati dal server primario) dopo l'operazione di ripristino

  • time_zone : questo valore da impostare su DEFAULT value SYSTEM
  • event_scheduler: il event_scheduler è impostato su OFF nel server ripristinato

È necessario impostare questi parametri del server riconfigurando il parametro del server

Il ripristino temporizzato è utile in più scenari, ad esempio quando un utente per errore elimina dati o rimuove un database o una tabella importante oppure se un'applicazione sovrascrive accidentalmente dati corretti con dati non validi a causa di un difetto dell'applicazione.

Per poter eseguire il ripristino a un momento specifico negli ultimi cinque minuti, potrebbe essere prima necessario attendere l'esecuzione del backup del log delle transazioni successivo.

Ripristino geografico

Se il server è stato configurato per backup con ridondanza geografica, è possibile ripristinare un server in un'altra area di Azure in cui il servizio è disponibile.

  • I server di archiviazione per utilizzo generico v1 (che supportano fino a 4 TB di archiviazione) possono essere ripristinati nell'area geografica associata o in qualsiasi area di Azure che supporta Database di Azure per MySQL - Servizio server singolo.
  • I server di archiviazione per utilizzo generico v2 (che supportano fino a 16 TB di archiviazione) possono essere ripristinati solo nelle aree di Azure che supportano l'infrastruttura dei server per utilizzo generico v2. Esaminare i piani tariffari di Database di Azure per MySQL per un elenco delle aree supportate.

Il ripristino geografico è l'opzione di ripristino predefinita quando il server non è disponibile a causa di un evento imprevisto nell'area in cui è ospitato. Se un evento imprevisto su larga scala determina la mancata disponibilità dell'applicazione di database, è possibile ripristinare un server dai backup con ridondanza geografica in un server in un'altra area. Il ripristino geografico usa il backup più recente del server. Esiste un ritardo tra il momento in cui un backup viene creato e quando ne viene eseguita la replica in un'area diversa. Questo ritardo può essere al massimo di un'ora, quindi, in caso di emergenza, può verificarsi una perdita massima di un'ora di dati.

Importante

Se viene eseguito un ripristino geografico per un server appena creato, la sincronizzazione iniziale del backup può richiedere più di 24 ore a seconda delle dimensioni dei dati perché il tempo di copia del backup completo iniziale dello snapshot è molto superiore. I backup di snapshot successivi sono la copia incrementale e di conseguenza i ripristini sono più veloci dopo 24 ore di creazione del server. Se si valutano i ripristini geografici per definire l'RTO, è consigliabile attendere e valutare il ripristino geografico solo dopo 24 ore di creazione del server per stime migliori.

Durante il ripristino geografico è possibile modificare le seguenti opzioni relative alle configurazioni del server: generazione delle risorse di calcolo, vCore, periodo di conservazione dei backup e ridondanza per il backup. La modifica del piano tariffario (Basic, Utilizzo generico o Con ottimizzazione per la memoria) o delle dimensioni della risorsa di archiviazione non è supportata durante il ripristino geografico.

Il tempo stimato per il ripristino dipende da diversi fattori, tra cui le dimensioni dei database, le dimensioni dei log delle transazioni, la larghezza di banda di rete e il numero totale di database ripristinati contemporaneamente nella stessa area. Il tempo di recupero di solito è inferiore a 12 ore.

Eseguire le attività post-ripristino

Dopo il ripristino con uno dei due meccanismi, per rendere nuovamente operativi gli utenti e le applicazioni è consigliabile eseguire queste attività:

  • Se il nuovo server è destinato a sostituire il server originale, reindirizzare i client e le applicazioni client al nuovo server
  • Assicurarsi che siano presenti regole di rete virtuale appropriate per consentire agli utenti di connettersi. Queste regole non vengono copiate dal server originale.
  • Verificare che siano presenti gli account di accesso e le autorizzazioni a livello di database appropriati
  • Configurare gli avvisi in base alle proprie esigenze.

Passaggi successivi