Backup e ripristino in Database di Azure per MySQL - Server flessibile

  • Articolo

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

Database di Azure per MySQL: il Server Flessibile crea automaticamente i backup archiviati in modo sicuro e li archivia nell'archiviazione con ridondanza locale all'interno dell'area. 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.

Panoramica del servizio Backup

Server Flessibile di Database di Azure per MySQL supporta due tipi di backup per offrire una maggiore flessibilità per la gestione dei backup dei dati business critical.

Backup automatizzato

Server Flessibile di Database di Azure per MySQL esegue backup snapshot dei file di dati e li archivia in una risorsa di archiviazione con ridondanza locale. Il server esegue anche il backup dei log delle transazioni e li archivia nell'archiviazione con ridondanza locale. 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 configurare la conservazione dei backup da 1 a 35 giorni. Tutti i backup vengono crittografati usando la crittografia AES a 256 bit per i dati archiviati inattivi.

Backup su richiesta

La funzionalità di backup su richiesta consente ai clienti di attivare backup su richiesta del carico di lavoro di produzione, oltre ai backup automatizzati eseguiti dal servizio, e di archiviarli in linea con i criteri di conservazione dei backup del server. È possibile usare questi backup come punto di ripristino più veloce per eseguire un ripristino temporizzato per ridurre i tempi di ripristino fino al 90%. Il periodo di conservazione dei backup predefinito è di sette giorni. Facoltativamente, è possibile configurare la conservazione dei backup da 1 a 35 giorni. È possibile attivare un totale di 50 backup su richiesta dal portale. Tutti i backup vengono crittografati usando la crittografia AES a 256 bit per i dati archiviati inattivi.

Questi file di backup non possono essere esportati. Questi backup possono essere usati solo per le operazioni di ripristino nel Server Flessibile di Database di Azure per MySQL. È anche possibile usare mysqldump da un client MySQL per copiare un database.

Frequenza di backup

I backup nei server flessibili 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. Se un backup pianificato non riesce, il servizio di backup tenta ogni 20 minuti di eseguire un backup fino a quando l'operazione non riesce. Questi errori di backup possono verificarsi a causa di carichi di produzione transazionali elevati nell'istanza del server.

Nota

  • Se il server riscontra un carico elevato di transazioni, con un conseguente aumento dei file binlog, il servizio di backup eseguirà più backup al giorno per garantire un ripristino affidabile e più rapido usando questi backup.
  • Per i server 5.7, le transazioni a esecuzione prolungata/Large possono impedire l'acquisizione del blocco a livello di istanza globale, necessaria per il backup giornaliero riuscito. In questi scenari, i backup giornalieri possono avere esito negativo. Per risolvere questo problema, terminare la transazione a esecuzione prolungata OPPURE riavviare il server. Per garantire operazioni più fluide, è consigliabile aggiornare i server MySQL 5.7 alla versione 8.0 usando un aggiornamento della versione principale.

opzioni di ridondanza per il backup

Il Server Flessibile di Database di Azure per MySQL archivia sempre più copie dei dati in modo che siano protetti da eventi pianificati e non pianificati, inclusi errori hardware temporanei, interruzioni della rete o dell'alimentazione e forti calamità naturali. Nei livelli Utilizzo generico e Con ottimizzazione per la memoria, Server Flessibile di Database di Azure per MySQL offre la possibilità di scegliere tra archiviazione dei backup con ridondanza locale, di zona o con ridondanza geografica nei livelli Basic, General Purpose e Business Critical. Per impostazione predefinita, Database di Azure per MySQL l'archiviazione di backup del Server Flessibile è ridondante in locale per i server con disponibilità elevata nella stessa zona o nessuna configurazione a disponibilità elevata e ridondanza della zona per i server con configurazione a disponibilità elevata con ridondanza della zona.

La ridondanza del backup garantisce che il database soddisfi gli obiettivi di disponibilità e durabilità anche in caso di errori e Server Flessibile di Database di Azure per MySQL estende tre opzioni agli utenti:

  • Archivio di backup con ridondanza locale: Quando i backup vengono memorizzati nell'archivio di backup con ridondanza locale, più copie dei backup vengono archiviate nello stesso data center. Questa opzione protegge i dati da errori di rack e unità del server. In questo modo si ottiene almeno il 99,999999999% (11 9) di durabilità degli oggetti nell'arco di un anno specifico. Per impostazione predefinita, l'archiviazione di backup per i server con disponibilità elevata della stessa zona o nessuna configurazione a disponibilità elevata è impostata su ridondanza locale.

  • Archivio di backup con ridondanza della zona: Quando i backup vengono archiviati nell'archiviazione di backup con ridondanza della zona, più copie non vengono archiviate solo all'interno della zona di disponibilità dov’è ospitato il server, ma anche replicate in altre zone di disponibilità all'interno della stessa area. Questa opzione può essere sfruttata per scenari che richiedono disponibilità elevata o per limitare la replica dei dati all'interno di un paese o area geografica per soddisfare i requisiti di residenza dei dati. In questo modo si ottiene almeno il 99,9999999999% (12 9) di durabilità degli oggetti nell'arco di un anno specifico. È possibile selezionare l'opzione Disponibilità elevata con ridondanza della zona al momento della creazione del server per garantire l'archiviazione di backup con ridondanza della zona. La disponibilità elevata per un server può essere disabilitata dopo la creazione, ma l'archiviazione di backup rimane con ridondanza della zona.

  • Archivio di backup con ridondanza geografica: Quando i backup vengono archiviati in un archivio di backup con ridondanza geografica, non solo vengono archiviate diverse copie dei dati nell'area in cui è ospitato il server ma anche replicate nell'area associata. Questo garantisce una migliore protezione e la possibilità di ripristinare il server in un'area diversa in caso di emergenza. Ciò garantisce inoltre almeno il 99,99999999999999999% (16 9) durabilità degli oggetti Backup in un determinato anno. È possibile abilitare l'opzione Ridondanza geografica al momento della creazione del server per garantire l'archiviazione di backup con ridondanza geografica. È anche possibile passare dall'archiviazione con ridondanza locale all'archiviazione con ridondanza geografica dopo la creazione del server. La ridondanza geografica è supportata per i server ospitati in una delle aree associate di Azure.

Nota

La disponibilità elevata con ridondanza della zona per supportare la ridondanza della zona viene rilevata come operazione di creazione solo ora. Attualmente, per una ridondanza geografica del server a disponibilità elevata con ridondanza della zona può essere abilitata/disabilitata solo in fase di creazione del server.

Passaggio da altre opzioni di archiviazione di backup all'archiviazione di backup con ridondanza geografica

È possibile spostare l'archiviazione dei backup esistenti nell'archiviazione con ridondanza geografica usando i modi consigliati seguenti:

  • Passaggio dall'archiviazione con ridondanza locale all'archiviazione con ridondanza geografica: per spostare l'archiviazione di backup dall'archiviazione con ridondanza locale all'archiviazione con ridondanza geografica, è possibile modificare la configurazione del server di calcolo e archiviazione da portale di Azure per abilitare la ridondanza geografica per il server di origine con ridondanza locale. Gli stessi server a disponibilità elevata con ridondanza della zona possono essere ripristinati come un server con ridondanza geografica in modo analogo a quello dell'archiviazione di backup sottostante con ridondanza locale per lo stesso.

  • Passaggio dall'archiviazione con ridondanza della zona all'archiviazione con ridondanza geografica: Server Flessibile di Database di Azure per MySQL non supporta l'archiviazione con ridondanza della zona alla conversione dell'archiviazione con ridondanza geografica tramite le impostazioni di calcolo e archiviazione cambiano dopo il provisioning del server. Per spostare l'archiviazione di backup dall'archiviazione con ridondanza della zona all'archiviazione con ridondanza geografica, sono disponibili due opzioni: usare PITR (ripristino temporizzato) per ripristinare il server con la configurazione desiderata. b) Creare un nuovo server con la configurazione desiderata ed eseguire la migrazione dei dati usando backup e ripristino.

Conservazione dei backup

I backup vengono conservati in base al periodo di conservazione dei backup impostato sul server. È possibile selezionare un periodo di conservazione compreso tra 1 e 35 giorni con un periodo di conservazione predefinito: sette giorni. È possibile impostare il periodo di conservazione durante la creazione del server o successivamente aggiornando la configurazione del backup attraverso l’utilizzo del portale 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. È inoltre possibile considerare il periodo di conservazione dei backup come 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'archivio di backup. Ad esempio, se il periodo di conservazione dei backup è impostato su sette giorni, la finestra di ripristino prende in considerazione gli ultimi sette giorni. In questo scenario vengono conservati tutti i backup necessari per ripristinare il server negli ultimi sette giorni. Con una finestra di conservazione dei backup di sette giorni, gli snapshot del database e i backup del log delle transazioni vengono archiviati per gli ultimi otto giorni (un giorno prima della finestra).

Costo dell'archiviazione dei backup

Server Flessibile di 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. Per lo spazio di archiviazione aggiuntivo usato per i backup è previsto un addebito in GB al mese. Ad esempio, se è stato effettuato il provisioning di un server con 250 GB di spazio di archiviazione, saranno disponibili 250 GB di spazio di archiviazione per backup del server senza costi aggiuntivi. Se l'utilizzo giornaliero del backup è 25 GB, è possibile avere fino a 10 giorni di archiviazione di backup gratuita. L'archiviazione consumata per backup superiori ai 250 GB viene addebitata in base al modello tariffario.

È possibile usare la metrica archivio di backup utilizzata in Monitoraggio di Azure disponibile nel portale di Azure per monitorare l'archivio di backup utilizzato da un server. La metrica di archiviazione di backup usata rappresenta la somma dello spazio di archiviazione utilizzato da tutti i backup del database e dei backup del log mantenuti in base al periodo di conservazione dei backup impostato per il server. Un'intensa attività transazionale sul server può causare un aumento dell'uso dell'archivio di backup indipendentemente dalle dimensioni totali del database. L'archiviazione di backup usata per un server con ridondanza geografica è due volte quella di un server con ridondanza locale.

Il mezzo principale per controllare il costo dell'archivio di backup consiste nell'impostare il periodo di conservazione dei backup appropriato e scegliere le opzioni di ridondanza del backup appropriate. È possibile selezionare un periodo di conservazione compreso tra 1 e 35 giorni.

Importante

I backup da un server database configurato in una configurazione a disponibilità elevata con ridondanza della zona si verificano dal server di database primario perché il sovraccarico è minimo con i backup di snapshot.

Visualizzare i backup completi disponibili

Il pannello Backup e ripristino nel portale di Azure fornisce un elenco completo dei backup completi disponibili per l'utente in un determinato momento. Sono inclusi i backup automatici e i backup su richiesta. È possibile usare questo pannello per visualizzare data e ora di completamento per tutti i backup completi disponibili entro il periodo di conservazione del server e per eseguire operazioni di ripristino usando questi backup completi. L'elenco dei backup disponibili include tutti i backup completi all'interno del periodo di conservazione, data e ora che mostra il completamento corretto, data e ora che indica per quanto tempo verrà conservato un backup e un'azione di ripristino.

Recupera

In Server Flessibile di Database di Azure per MySQL, l'esecuzione di un ripristino crea un nuovo server dai backup del server originale. Sono disponibili due tipi di ripristino:

  • Il ripristino temporizzato è disponibile con entrambe le opzioni di ridondanza per il backup e crea un nuovo server nella stessa area del server originale.
  • Il ripristino geografico è disponibile solo se il server è stato configurato per l'archiviazione con ridondanza geografica o qualsiasi altra regione supportata da Azure dov’è disponibile Server Flessibile.

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

  • Le dimensioni del 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.

Nota

Un server abilitato per la disponibilità elevata diventerà non a disponibilità elevata (disponibilità elevata disabilitata) dopo il ripristino sia per il ripristino temporizzato che per il ripristino geografico.

Ripristino temporizzato

Nei server flessibili di Database di Azure per MySQL, l'esecuzione di un ripristino temporizzato consente di creare un nuovo server dai backup del Server Flessibile nella stessa area del server di origine, nonché con la stessa configurazione in termini di livello di calcolo, numero di vCore, dimensioni di archiviazione, periodo di conservazione dei backup e opzione di ridondanza per il backup. I tag e le impostazioni, come ad esempio le impostazioni delle reti virtuali e del firewall, vengono anche ereditati dal server di origine. Il livello di calcolo e archiviazione del server ripristinato, la configurazione e le impostazioni di sicurezza possono essere modificate al termine del ripristino.

Nota

Sono presenti due parametri del server che vengono reimpostati sui valori predefiniti (e non sono copiati dal server primario) dopo l’operazione di ripristino

  • time_zone: questo valore deve essere impostato sul valore predefinito SYSTEM
  • event_scheduler: per i server MySQL versione 5.7, il parametro event_scheduler del server viene automaticamente disattivato all'avvio del backup e il parametro event_scheduler del server viene riattivato "ON" al termine del backup. In MySQL versione 8.0 per Database di Azure per MySQL - Server flessibile il event_scheduler rimane invariato durante i backup. Per garantire operazioni più fluide, è consigliabile aggiornare i server MySQL 5.7 alla versione 8.0 usando un aggiornamento della versione principale.

Il ripristino temporizzato è utile in più scenari, Ecco alcuni casi d'uso comuni:

  • Quando un utente elimina accidentalmente i dati nel database
  • L'utente elimina una tabella o un database importante
  • L’applicazione dell’utente potrebbe sovrascrivere accidentalmente dei dati con dati errati a causa di un difetto dell'applicazione.

È possibile scegliere tra il punto di ripristino più recente, il punto di ripristino personalizzato e il punto di ripristino più veloce (ripristino tramite backup completo) tramite portale di Azure.

  • Punto di ripristino più recente: l'opzione più recente del punto di ripristino consente di ripristinare il server alla data e ora quando è stata attivata l'operazione di ripristino. Questa opzione è utile per ripristinare rapidamente lo stato più aggiornato del server.
  • Punto di ripristino personalizzato: questa opzione consente di scegliere qualsiasi punto nel tempo entro il periodo di conservazione definito per questo server. Questa opzione è utile per ripristinare il server nel momento preciso per il ripristino da un errore dell'utente.
  • Punto di ripristino rapido: questa opzione consente agli utenti di ripristinare il server nel tempo più veloce possibile entro il periodo di conservazione definito per il proprio server. Il ripristino più rapido è possibile scegliendo il punto di ripristino nel tempo in cui viene completato il backup completo. Questa operazione di ripristino ripristina semplicemente il backup completo dello snapshot e non richiede alcun ripristino dei log, il che la rende veloce. È consigliabile selezionare data e ora di un backup completo maggiore del primo punto di ripristino per un'operazione di ripristino ottimale.

Il tempo stimato per il ripristino dipende da diversi fattori, tra cui le dimensioni dei database, le dimensioni del backup del log delle transazioni, le dimensioni di calcolo dello SKU e l’ora del ripristino. Il ripristino del log delle transazioni è la parte più lunga del processo di ripristino. Se l’ora di ripristino viene scelta più vicina alla pianificazione del backup dello snapshot, le operazioni di ripristino sono più veloci perché l'applicazione del log delle transazioni è minima. Per stimare il tempo di recupero accurato per il server, è consigliabile testarlo nell'ambiente perché le variabili specifiche dell'ambiente sono troppe.

Importante

Se si ripristina un'istanza del Server Flessibile Database di Azure per MySQL configurata con disponibilità elevata con ridondanza della zona, il server ripristinato viene configurato nella stessa area e zona del server primario e distribuito come server singolo in modalità non a disponibilità elevata. Fare riferimento alla disponibilità elevata con ridondanza della zona per il Server Flessibile.

Importante

Ora è possibile ripristinare una risorsa eliminata del Server Flessibile di Database di Azure per MySQL entro cinque giorni dal momento dell'eliminazione del server. Per una guida dettagliata al ripristino di un server eliminato, fare riferimento ai passaggi documentati. Per proteggere le risorse del server, post-distribuzione, da eliminazioni accidentali o modifiche impreviste, gli amministratori possono sfruttare blocchi di gestione.

Ripristino geografico

È possibile ripristinare il server alla sua regione abbinata geograficamente, dove il servizio è disponibile se il server è stato configurato per backup con ridondanza geografica o altre regioni supportate da Azure dov’è disponibile server flessibile per Database di Azure per MySQL. Possibilità di eseguire il ripristino in qualsiasi area non associata supporto tecnico di Azure (ad eccezione di Brazil South, USGov Virginia e West US 3) è noto come "ripristino geografico universale".

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.

È anche possibile eseguire il ripristino geografico in un server arrestato usando l'interfaccia della riga di comando di Azure. Per altre informazioni sul ripristino geografico di un server con l'interfaccia della riga di comando di Azure, vedere Ripristinare Server Flessibile di Database di Azure per MySQL con l'interfaccia della riga di comando di Azure.

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.

Nota

Se si esegue il ripristino geografico di un'istanza del Server Flessibile Database di Azure per MySQL configurata con disponibilità elevata con ridondanza della zona, il server ripristinato viene configurato nell'area geografica associata e nella stessa zona del server primario e distribuito come singola istanza del Server Flessibile Database di Azure per MySQL in modalità non a disponibilità elevata. Fare riferimento a Disponibilità elevata con ridondanza della zona per il Server Flessibile del Database di Azure per MySQL

Importante

Quando l'area primaria è inattiva, non è possibile creare server con ridondanza geografica nella rispettiva area geografica abbinata, perché non è possibile effettuare il provisioning dell'archiviazione nell'area primaria. È necessario attendere che l'area primaria sia in grado di effettuare il provisioning di server con ridondanza geografica nell'area geografica abbinata. Con l'area primaria inattiva, è comunque possibile ripristinare geograficamente il server di origine nell'area geografica abbinata disabilitando l'opzione di ridondanza geografica in Calcolo e archiviazione. Configurare le impostazioni del server nell'esperienza del portale di ripristino e ripristinare come server con ridondanza locale per garantire la continuità aziendale.

Eseguire le attività post-ripristino

Dopo il ripristino dall’ultimo punto di ripristino o dal punto di ripristino personalizzato, 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 e firewall a livello di server appropriate per le connessioni utente.
  • Verificare che siano presenti gli account di accesso e le autorizzazioni a livello di database appropriati.
  • Configurare gli avvisi in base alle proprie esigenze.

Conservazione a lungo termine (anteprima)

I servizi server flessibili di Backup di Azure e Server Flessibile di Database di Azure per MySQL hanno creato una soluzione di backup a lungo termine di livello aziendale per le istanze del Server Flessibile di Database di Azure per MySQL che conservano i backup per un massimo di 10 anni. È possibile usare la conservazione a lungo termine in modo indipendente o oltre alla soluzione di backup automatizzata offerta dal Server Flessibile di Database di Azure per MySQL, che offre la conservazione fino a 35 giorni. I backup automatizzati sono backup snapshot adatti per i ripristini operativi, soprattutto quando si vuole eseguire il ripristino dai backup più recenti. I backup a lungo termine consentono di soddisfare le esigenze di conformità e di controllo. Oltre alla conservazione a lungo termine, la soluzione offre le funzionalità seguenti:

  • Backup su richiesta e pianificati controllati dal cliente.
  • Gestire e monitorare tutte le operazioni e i processi correlati al backup tra server, gruppi di risorse, posizioni, sottoscrizioni e tenant da un unico riquadro di vetro denominato Centro backup.
  • I backup sono archiviati in un domini di sicurezza e di errore separati. Se il server o la sottoscrizione di origine sono compromessi, i backup rimangono sicuri nell'insieme di credenziali di backup (in Backup di Azure account di archiviazione gestiti).

Limitazioni e considerazioni

  • In anteprima il ripristino con conservazione a lungo termine è attualmente disponibile come RestoreasFiles negli account di archiviazione. La funzionalità RestoreasServer verrà aggiunta in futuro.
  • Il supporto per la creazione e la gestione della conservazione a lungo termine tramite l'interfaccia della riga di comando di Azure non è attualmente supportato.

Per altre informazioni sull'esecuzione di un backup a lungo termine, vedere la guida pratica.

Backup ed esportazione su richiesta (Anteprima)

Il Server Flessibile di Database di Azure per MySQL consente ora di attivare un backup fisico del server su richiesta ed esportarlo in un account di archiviazione di Azure (archiviazione BLOB di Azure). Dopo l'esportazione, questi backup possono essere usati per il ripristino, la migrazione e la ridondanza dei dati. Questi file di backup fisici esportati possono essere usati per ripristinare un server MySQL locale per soddisfare le esigenze di controllo/conformità/archiviazione di un'organizzazione. La funzionalità è attualmente disponibile in anteprima pubblica e solo nelle aree del cloud pubblico.

Per altre informazioni sul backup dell'esportazione, vedere la guida pratica

Domande frequenti (FAQ)

  • Come eseguire il backup del server?

    Per impostazione predefinita, il Server Flessibile di Database di Azure per MySQL consente backup automatici dell'intero server, che includono tutti i database creati, con un periodo di conservazione predefinito di 7 giorni. È anche possibile attivare un backup manuale usando la funzionalità di backup su richiesta. L'altro modo per eseguire manualmente un backup consiste nell'usare strumenti della community come mysqldump, come documentato qui o mydumper, come documentato qui. Per eseguire il backup del Server Flessibile di Database di Azure per MySQL nell'archiviazione BLOB, vedere Eseguire il backup di Database di Azure per MySQL nell'archiviazione BLOB nel blog della community tecnica.

  • È possibile configurare i backup automatici per conservare i dati a lungo termine?

    No, attualmente è supportato solo un massimo di 35 giorni di conservazione automatica dei backup. È possibile usare i backup manuali per un requisito di conservazione a lungo termine.

  • Quali sono le finestre di backup per il server? È possibile personalizzarli?

    Il primo backup dello snapshot viene pianificato subito dopo la creazione di un server. I backup degli snapshot vengono eseguiti una volta al giorno. I backup del log delle transazioni vengono eseguiti ogni cinque minuti. Le finestre di backup sono intrinsecamente gestite da Azure e non possono essere personalizzate.

  • I backup sono crittografati?

    Tutti i dati, i backup e i file temporanei creati durante l'esecuzione di query di Server Flessibile di Database di Azure per MySQL vengono crittografati usando la crittografia AES a 256 bit. La crittografia dell'archiviazione è sempre attiva e non può essere disabilitata.

  • È possibile ripristinare uno o più database?

    Il ripristino di uno o più database o di una o più tabelle non è supportato. Se si desidera ripristinare database specifici, eseguire un ripristino temporizzato e quindi estrarre le tabelle o i database necessari.

  • Il server è disponibile durante la finestra di backup?

    Sì. I backup sono operazioni online e sono basati su snapshot. L'operazione sugli snapshot richiede solo alcuni secondi e non interferisce con i carichi di lavoro di produzione, garantendo la disponibilità elevata del server.

  • Quando si configura la finestra di manutenzione per il server, è necessario tenere conto della finestra di backup?

    No, i backup vengono attivati internamente come parte del servizio gestito e non hanno alcun impatto sulla finestra di manutenzione gestita.

  • Dove vengono archiviati i backup automatici e come si gestisce la loro conservazione?

    Server flessibile di Database di Azure per MySQL crea automaticamente backup del server e li archivia in uno spazio di archiviazione con ridondanza locale o geografica configurato dall'utente. Questi file di backup non possono essere esportati. Il periodo di conservazione dei backup predefinito è di sette giorni. Facoltativamente, è possibile configurare la conservazione dei backup da 1 a 35 giorni.

  • Come è possibile convalidare i backup?

    Il modo migliore per convalidare la disponibilità dei backup completati correttamente consiste nel visualizzare i backup completamente automatizzati eseguiti entro il periodo di conservazione nel pannello Backup e ripristino. Se un backup non riesce, non è elencato nell'elenco dei backup disponibili e il servizio di backup tenterà ogni 20 minuti di eseguire un backup fino a quando non viene eseguito un backup corretto. Questi errori di backup sono dovuti a carichi di produzione transazionali elevati nel server.

  • Dove è possibile visualizzare l'utilizzo del backup?

    Nella sezione Monitoraggio - Metriche del portale di Azure è possibile trovare la metrica Archiviazione di backup usata che consente di monitorare l'utilizzo totale del backup.

  • Cosa accade ai backup se si elimina il server?

    Se si elimina il server, vengono eliminati anche tutti i backup appartenenti al server e non sarà possibile recuperarli. Per proteggere le risorse del server da eliminazioni accidentali o modifiche impreviste, post-distribuzione, gli amministratori possono usare i blocchi di gestione.

  • Cosa accade ai backup quando si ripristina un server?

    Se si ripristina un server, viene sempre creato un nuovo server ripristinato usando i backup del server originale. Il backup precedente del server originale non viene copiato nel server appena ripristinato e rimane con il server originale. Tuttavia, per il server appena creato, il primo backup snapshot viene pianificato immediatamente dopo la creazione di un server e il servizio garantisce che i backup automatici giornalieri vengano eseguiti e archiviati in base al periodo di conservazione del server configurato.

  • Come verranno addebitati e fatturati i costi per i backup?

    Server Flessibile di 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. Qualsiasi altra risorsa di archiviazione di backup usata viene addebitata in gigabyte al mese, come definito nel modello tariffario. La fatturazione dell'archiviazione di backup è disciplinata anche dal periodo di conservazione dei backup selezionato e dall'opzione di ridondanza del backup scelta, oltre all'attività transazionale nel server, che influisce direttamente sull'archiviazione di backup totale usata direttamente.

  • Come vengono conservati i backup per i server arrestati?

    Non vengono eseguiti nuovi backup per i server arrestati. Tutti i backup precedenti (all'interno della finestra di conservazione) al momento dell'arresto del server vengono mantenuti fino al riavvio del server; dopodiché, la conservazione del backup del server attivo viene governata dalla sua finestra di conservazione dei backup.

  • Come verrà addebitato il backup di un server arrestato?

    Mentre l’istanza di server è ferma, vengono addebitati costi per l'archiviazione di cui è stato effettuato il provisioning (IOPS) e l'archiviazione di backup (backup archiviati all'interno della finestra di conservazione specificata). L'archiviazione di backup gratuita è limitata alle dimensioni del database di cui è stato effettuato il provisioning e si applica solo ai server attivi.

  • Come sono protetti i dati di backup?

    Il Server Flessibile del database di Azure per MySQL protegge i dati di backup bloccando le operazioni che potrebbero causare la perdita di punti di ripristino per la durata del periodo di conservazione configurato. I backup eseguiti durante il periodo di conservazione possono essere letti solo allo scopo del ripristino e vengono eliminati dopo il periodo di conservazione. Tutti i backup di Server Flessibile di Database di Azure per MySQL vengono crittografati usando la crittografia AES a 256 bit per i dati archiviati inattivi.

  • In che modo un'operazione di ripristino temporizzato (Point-In-Time Restore, PITR) influisce sull'utilizzo delle operazioni IOPS?

    Durante un'operazione PITR in Database di Azure per MySQL - Server flessibile, viene creato un nuovo server e i dati vengono copiati dall'archiviazione del server di origine alla risorsa di archiviazione del nuovo server. Tale processo comporta un aumento dell'utilizzo delle operazioni IOPS nel server di origine. Questo aumento dell'utilizzo delle operazioni IOPS è un'occorrenza normale e non è indice di problemi con il server di origine o con l'operazione PITR. Al termine dell'operazione PITR, l'utilizzo delle operazioni IOPS nel server di origine torna ai livelli consueti.

  • Come si ripristina il server? Il portale di Azure supporta il ripristino temporizzato per tutti i server, consentendo agli utenti di eseguire il ripristino ai punti di ripristino più recenti o personalizzati. Per ripristinare manualmente il server dai backup eseguiti da mysqldump/myDumper, vedere Ripristinare il database usando myLoader.

  • Perché il ripristino richiede molto tempo?

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

    • Le dimensioni dei database. Come parte del processo di recupero, il database deve essere idratato dall'ultimo backup fisico e quindi il tempo impiegato per il ripristino sarà proporzionale alle dimensioni del database.
    • Parte attiva dell'attività di transazione che deve essere riprodotta per il ripristino. Il ripristino può richiedere più tempo a seconda dell'attività della transazione aggiunta dall'ultimo checkpoint riuscito.
    • 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 chiavi primarie nelle tabelle del database. Per un ripristino più rapido, è consigliabile aggiungere le chiavi primarie per tutte le tabelle nel database.

  • La modifica delle variabili di database a livello di sessione influisce sul ripristino?

    La modifica delle variabili a livello di sessione e l'esecuzione di istruzioni DML in una sessione client MySQL possono influire sull'operazione PITR (ripristino temporizzato), perché queste modifiche non vengono registrate nel log binario usato per l'operazione di backup e ripristino. Ad esempio, foreign_key_checks è una di queste variabili a livello di sessione, che se disabilitate per l'esecuzione di un'istruzione DML che viola il vincolo di chiave esterna genera un errore pitr (ripristino temporizzato). L'unica soluzione alternativa in uno scenario di questo tipo consiste nel selezionare un'ora di ripristino tempo precedente al momento in cui foreign_key_checks sono stati disabilitati. È consigliabile NON modificare le variabili di sessione per un'operazione PITR corretta.

Passaggi successivi