Condividi tramite

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

Il server flessibile di Database di Azure per MySQL crea automaticamente backup del server e li archivia in modo sicuro 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

Il 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 critici per l'azienda.

Backup automatico

Il 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 inoltre il backup dei log delle transazioni e archivia anch'essi 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 il backup del database da 1 a 35 giorni. Tutti i backup sono crittografati usando la crittografia AES a 256 bit per i dati archiviati inattivi.

Backup su richiesta

Il server flessibile di Database di Azure per MySQL consente inoltre di avviare backup su richiesta del carico di lavoro di produzione, oltre ai backup automatici eseguiti dal servizio, e di conservarli in conformità con i criteri di conservazione dei backup del server. È possibile usare questi backup come punto di ripristino più veloce per eseguire un ripristino temporizzato al fine di ridurre i tempi di ripristino fino al 90%. Il periodo di conservazione dei backup predefinito è di sette giorni. Facoltativamente, è possibile configurare il backup del database da 1 a 35 giorni. È possibile attivare un totale di 50 backup su richiesta dal portale. Tutti i backup sono crittografati usando la crittografia AES a 256 bit per i dati archiviati inattivi.

Questi file di backup non possono essere esportati. I 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 in 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.

Per migliorare la frequenza dei backup giornalieri automatizzati, è possibile aumentare l'intervallo di backup. Questa rettifica è particolarmente utile quando si prevedono transazioni di grandi dimensioni, in quanto riduce significativamente il tempo di ripristino in caso di errore. Per modificare l'intervallo di backup, passare alla sezione Impostazioni > Calcolo e archiviazione e impostare il campo Intervallo di backup di conseguenza. Mentre l'intervallo predefinito è impostato su 24 ore, può essere regolato su 12 o 6 ore. La conservazione di questi backup è determinata dal periodo di conservazione configurato a livello di server.

Questa funzionalità è attualmente disponibile in anteprima ed è limitata alle aree Stati Uniti orientali, Stati Uniti centro-occidentali, Giappone orientale e Asia orientale .

Screenshot della frequenza di modifica del backup.

Note

  • 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 o di grandi dimensioni possono impedire l'acquisizione del blocco a livello di istanza globale, necessaria per la riuscita del backup giornaliero. 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 più copie dei backup in modo che i dati siano protetti da eventi pianificati e non pianificati, inclusi errori hardware temporanei, interruzioni di rete o interruzioni dell'alimentazione e gravi calamità naturali. Il server flessibile di Database di Azure per MySQL offre la flessibilità di scegliere tra l'archiviazione di backup con ridondanza locale, con ridondanza della zona o con ridondanza geografica nei livelli Basic, per utilizzo generico e Business Critical. Per impostazione predefinita, l'archiviazione di backup del server flessibile del database di Azure per MySQL è ridondante in locale per i server con disponibilità elevata nella stessa zona o senza configurazione a disponibilità elevata, e con ridondanza della zona per i server con configurazione a disponibilità elevata con ridondanza della zona.

La ridondanza del backup garantisce che il database soddisfi i target di disponibilità e durabilità anche in caso di errori; il server flessibile di Database di Azure per MySQL estende tre opzioni agli utenti:

  • Archiviazione di backup con ridondanza locale: quando i backup vengono archiviati nell'archiviazione 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. Inoltre, 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.

  • Archiviazione di backup con ridondanza della zona: quando i backup vengono archiviati nell'archiviazione di backup con ridondanza della zona, più copie vengono archiviate non solo all'interno della zona di disponibilità in cui è ospitato il server, ma vengono replicate anche in un'altra zona di disponibilità nella 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. Inoltre, 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.

  • Archiviazione di backup con ridondanza geografica: quando i backup vengono archiviati nell'archiviazione di backup con ridondanza geografica, più copie vengono archiviate non solo all'interno dell'area in cui è ospitato il server, ma vengono replicate anche nell'area geografica 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,99999999999999% (16 9) di durabilità degli oggetti backup in un determinato anno. È possibile abilitare l'opzione con 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.

Note

L'alta disponibilità con ridondanza di zona è attualmente disponibile solo come operazione al momento della creazione. Attualmente, per un server con alta disponibilità a ridondanza di zona, la geo-ridondanza può essere abilitata o disabilitata solo al momento della creazione del server.

Passare 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 metodi 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 dal portale di Azure in modo da abilitare la ridondanza geografica per il server di origine con ridondanza locale. Anche i server con alta disponibilità a ridondanza nella stessa zona possono essere ripristinati come server geo-ridondanti in modo analogo, poiché l'archiviazione dei backup sottostante è con ridondanza locale per tali casi.

  • Passaggio dall'archiviazione con ridondanza della zona all'archiviazione di backup con ridondanza geografica: il server flessibile di Database di Azure per MySQL non supporta la conversione dall'archiviazione con ridondanza della zona all'archiviazione con ridondanza geografica tramite le impostazioni di calcolo e archiviazione 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: a) usare il recupero 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 dump e ripristino.

Conservazione 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 tramite il portale di Azure.

Il periodo di conservazione dei backup determina quanto indietro nel tempo è possibile eseguire un'operazione di ripristino a un punto nel tempo, poiché si basa 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 (1 giorno prima della finestra).

Costo dell'archiviazione dei backup

Il server flessibile di Database di Azure per MySQL offre fino al 100% dell'archiviazione del server di cui è stato effettuato il provisioning come risorsa di archiviazione 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 Monitoraggio del server flessibile di Database di Azure per MySQL in Monitoraggio di Azure disponibile nel portale di Azure per monitorare l'archiviazione di backup usata 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. Lo spazio di archiviazione dei backup utilizzato per un server con ridondanza geografica è il doppio rispetto a quello di un server con ridondanza locale.

Il metodo principale per controllare il costo dell'archiviazione di backup consiste nell'impostare il periodo di conservazione dei backup appropriato. È possibile selezionare un periodo di conservazione compreso tra 1 e 35 giorni.

Importante

I backup da un server di database configurato in una configurazione a disponibilità elevata con ridondanza della zona si verificano dal server di database primario, poiché 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 i timestamp di completamento per tutti i backup completi disponibili entro il periodo di conservazione del server e per eseguire operazioni di ripristino usando tali backup completi. L'elenco dei backup disponibili include tutti i backup completi all'interno del periodo di conservazione, un timestamp che mostra il completamento corretto, un timestamp che indica per quanto tempo verrà conservato un backup e un'azione di ripristino.

Restore

Nel 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:

  • Ripristino temporizzato: è disponibile con entrambe le opzioni di ridondanza per il backup e crea un nuovo server nella stessa area del server originario.
  • Ripristino geografico: è disponibile solo se il server è stato configurato per l'archiviazione con ridondanza geografica e consente di ripristinare il server in un'area geografica abbinata o in qualsiasi altra area supportata di Azure in cui è disponibile il 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.

Note

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 quello geografico.

Ripristino temporizzato

Nel server flessibile di Database di Azure per MySQL, l'esecuzione di un ripristino temporizzato crea un nuovo server dai backup del server flessibile nella stessa area del server di origine. Viene creato con la configurazione del server originale per il livello di calcolo, il numero di vCore, le dimensioni di archiviazione, il periodo di conservazione dei backup e l'opzione di ridondanza del backup. Inoltre, i tag e le impostazioni, ad esempio la rete virtuale e il firewall, vengono 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.

Note

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: valore da impostare sul valore predefinito SYSTEM
  • vent_scheduler: per i server MySQL versione 5.7, il parametro del server event_scheduler viene automaticamente disattivato quando viene avviato il backup e il parametro del server event_scheduler viene riattivato dopo il completamento 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. Alcuni dei casi d'uso comuni includono:

  • Quando un utente elimina accidentalmente i dati nel database
  • L'utente elimina una tabella o un database importante
  • L'applicazione utente sovrascrive accidentalmente dati validi con dati non validi 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ù rapido (ripristino con backup completo) tramite il ripristino temporizzato in Database di Azure per MySQL - Server flessibile con il portale di Azure.

  • Punto di ripristino più recente: l'opzione più recente del punto di ripristino consente di ripristinare il server al timestamp di 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 in modo da riparare a un errore dell'utente.
  • Punto di ripristino più rapido: questa opzione consente di ripristinare il server nel minor tempo possibile per un determinato giorno, all'interno del periodo di conservazione definito per il server. Il ripristino più veloce è possibile selezionando il punto nel tempo in cui è stato completato il backup completo. Questa operazione di ripristino si limita a ripristinare il backup completo tramite snapshot e non richiede il ripristino o il recupero dei log, il che la rende più veloce. È consigliabile selezionare un timestamp di backup completo successivo al primo punto di ripristino disponibile nel tempo, per garantire il successo dell’operazione di ripristino.

Il tempo stimato per il ripristino dipende da diversi fattori, tra cui le dimensioni del database, le dimensioni del backup del log delle transazioni, le dimensioni di calcolo dello SKU e il tempo del ripristino. Il ripristino del log delle transazioni è la fase più lunga del processo di ripristino. Se il tempo di ripristino viene scelto vicino all’orario previsto per il backup tramite snapshot, le operazioni di ripristino risulteranno più rapide poiché l’applicazione dei log delle transazioni è minima. Per stimare il tempo di recupero accurato per il server, è consigliabile testarlo nell'ambiente, in quanto dipende da troppe variabili specifiche dell'ambiente.

Importante

Se si ripristina un'istanza del server flessibile di 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 a disponibilità elevata con ridondanza della zona per il Server flessibile.

Importante

È possibile ripristinare una risorsa Server flessibile di Database di Azure per MySQL eliminata entro 5 giorni dal momento dell'eliminazione del server. Per una guida dettagliata su come ripristinare un server eliminato, vedere i passaggi documentati. Per proteggere le risorse del server dopo la distribuzione da modifiche accidentali o impreviste, gli amministratori possono usare blocchi di gestione.

Ripristino geografico

È possibile ripristinare un server nell'area geografica associata in cui il servizio è disponibile se è stato configurato il server per backup con ridondanza geografica o qualsiasi altra area supportata di Azure in cui è disponibile il server flessibile di Database di Azure per MySQL. La possibilità di eseguire il ripristino in qualsiasi area supportata da Azure non abbinata, ad eccezione di Brazil South, USGov Virginia e West US 3), è nota 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. Si verifica un ritardo tra l'esecuzione di un backup e 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. Leggere Ripristino temporizzato in Database di Azure per MySQL - Server flessibile con 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.

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.

Note

Se si esegue il ripristino geografico di un'istanza del server flessibile di Database di Azure per MySQL configurata con disponibilità elevata con ridondanza della zona, il server ripristinato viene configurato nell'area geografica abbinata e nella stessa zona del server primario e distribuito come singola istanza del server flessibile di Database di Azure per MySQL in modalità non a disponibilità elevata. Vedere disponibilità elevata con ridondanza della zona per il server flessibile di 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 nelle impostazioni di configurazione Calcolo e archiviazione nell'esperienza del portale di ripristino, e ripristinare come server con ridondanza locale per garantire la continuità aziendale.

Eseguire le attività post-ripristino

Dopo aver eseguito un ripristino dal punto di ripristino più recente o dal punto di ripristino personalizzato , è consigliabile eseguire le seguenti operazioni per riportare utenti e applicazioni al pieno funzionamento:

  • Se il nuovo server è destinato a sostituire il server originale, reindirizzare i client e le applicazioni client al nuovo server.
  • Assicurarsi che siano presenti firewall a livello di server e regole di rete virtuale appropriate per consentire agli utenti di connettersi.
  • 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)

Note

La funzionalità di anteprima: la soluzione di conservazione a lungo termine per la protezione dei server flessibili di Database di Azure per MySQL tramite Backup di Azure è attualmente sospesa. Evitare di configurare nuovi backup fino a nuovo avviso. Assicurarsi che tutti i dati di backup esistenti siano sicuri e disponibili per il ripristino.

I servizi server flessibili di Backup di Azure e 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 di snapshot adatti per i ripristini operativi, soprattutto quando si vuole eseguire il ripristino da 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 relativi ai backup tra server, gruppi di risorse, aree geografiche, sottoscrizioni e tenant da un'unica interfaccia centralizzata chiamata Centro di backup.
  • I backup vengono archiviati in 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 (negli account di archiviazione gestiti da Backup di Azure).

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.
  • La creazione e la gestione della conservazione a lungo termine tramite l'interfaccia della riga di comando di Azure non sono attualmente supportate.

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

Backup ed esportazione su richiesta (Anteprima)

Note

La funzionalità "Backup ed esportazione su richiesta" nel server flessibile di Database di Azure per MySQL, attualmente in anteprima, è stata sospesa temporaneamente. Questa decisione è stata presa per risolvere determinati blocchi tecnici identificati durante la fase di anteprima, che influiscono sulla ripristinabilità dei backup esportati. Di conseguenza, l'esportazione dei backup in account di archiviazione esterni non sarà disponibile fino a nuovo avviso.

Il server flessibile di Database di Azure per MySQL offre ora la possibilità di attivare un backup fisico su richiesta del server 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 si esegue 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 metodo per eseguire manualmente un backup consiste nell'usare strumenti della community quali mysqldump, come documentato qui o mydumper, come documentato qui. Per eseguire il backup di un'istanza del server flessibile di Database di Azure per MySQL in un archivio BLOB, fare riferimento al blog della community tecnica Backup del server flessibile di Database di Azure per MySQL in un archivio BLOB.

  • È possibile configurare backup automatici da conservare a lungo termine?

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

  • Quali sono le finestre di backup per il server? Può essere personalizzata?

    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 del 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 un singolo/pochi database?

    Il ripristino di uno o più database o tabelle singole 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 effetto sulla finestra di manutenzione gestita.

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

    Il server flessibile di Database di Azure per MySQL crea automaticamente backup del server e li archivia nell'archiviazione con ridondanza locale e configurata dall'utente o nell'archiviazione con ridondanza geografica. Questi file di backup non possono essere esportati. Il periodo di conservazione dei backup predefinito è di sette giorni. Facoltativamente, è possibile configurare il backup del database 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 sarà presente nell'elenco dei backup disponibili e il servizio di backup tenterà ogni 20 minuti di eseguire un backup fino a quando l'operazione non viene completata con successo. Questi errori di backup sono dovuti a carichi di produzione transazionali elevati nel server.

  • Dove è possibile visualizzare l'utilizzo del backup?

    Nel portale di Azure, nella scheda Monitoraggio, sezione Metriche, è possibile trovare la metrica Monitoraggio del server flessibile di Database di Azure per MySQL, 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 dopo la distribuzione da modifiche accidentali o impreviste, gli amministratori possono usare blocchi di gestione.

  • Cosa accade ai backup quando si ripristina un server?

    Se si ripristina un server, viene sempre creata una rete di un nuovo server ripristinato usando i backup del server originale. Il backup precedente dal 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 del server e il servizio garantisce l'esecuzione quotidiana di backup automatici, conservati secondo il periodo di conservazione configurato per il server.

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

    Il server flessibile di Database di Azure per MySQL offre fino al 100% dell'archiviazione del server di cui è stato effettuato il provisioning come risorsa di archiviazione di backup senza costi aggiuntivi. L'archiviazione di backup usata viene addebitata in GB al mese in base al modello tariffario. La fatturazione dell'archiviazione di backup è determinata 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.

  • 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, dopo il quale la conservazione dei backup per il server attivo è determinata dalla finestra di conservazione dei backup.

  • Come verranno fatturati i backup per un server arrestato?

    Mentre l'istanza del server è arrestata, vengono addebitati i costi per l'archiviazione con provisioning (incluse le operazioni IOPS con provisioning) e per l'archiviazione dei backup (backup conservati 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 di ripristino e vengono eliminati dopo il periodo di conservazione. Inoltre, tutti i backup nel 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 è 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 tornerà 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 nei 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 del database. Come parte del processo di recupero, il database deve essere idratato dall'ultimo backup fisico; di conseguenza, il tempo impiegato per il ripristino sarà proporzionale alle dimensioni del database.
    • La 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 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 di ripristino temporizzato, poiché queste modifiche non vengono registrate nel log binario usato per l'operazione di backup e ripristino. Ad esempio, foreign_key_checks sono 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 di ripristino temporizzato. L’unica soluzione alternativa in uno scenario del genere consiste nel selezionare un momento di ripristino a un punto nel tempo precedente al momento in cui foreign_key_checks è stato disabilitato. È consigliabile NON modificare le variabili di sessione per un'operazione PITR riuscita.

Contenuti correlati