Eseguire il backup e il ripristino in Database di Azure per PostgreSQL - Server flessibile

SI APPLICA A: Server flessibile di Database di Azure per PostgreSQL

I backup costituiscono una parte essenziale di qualsiasi strategia di continuità aziendale. Consentono di proteggere i dati da danneggiamenti o eliminazioni accidentali.

Il server flessibile di Database di Azure per PostgreSQL esegue automaticamente backup regolari del server. È quindi possibile eseguire un ripristino temporizzato (PITR) all'interno di un periodo di conservazione specificato. Il tempo complessivo per il ripristino e il ripristino dipende in genere dalle dimensioni dei dati e dalla quantità di recupero da eseguire.

Panoramica del servizio Backup

Il server flessibile di Database di Azure per PostgreSQL esegue backup snapshot dei file di dati e li archivia in modo sicuro nell'archiviazione con ridondanza della zona o nell'archiviazione con ridondanza locale, a seconda dell'area. Il server esegue anche il backup dei log delle transazioni quando il file di log write-ahead (WAL) è pronto per l'archiviazione. È possibile usare questi backup per ripristinare un server a qualsiasi momento specifico all'interno del periodo di conservazione dei backup configurato.

Il periodo di conservazione dei backup predefinito è di 7 giorni, ma è possibile estendere il periodo a un massimo di 35 giorni. Tutti i backup vengono crittografati tramite la crittografia AES a 256 bit per i dati archiviati inattivi.

Questi file di backup non possono essere esportati o usati per creare server esterni al server flessibile di Database di Azure per PostgreSQL. A tale scopo, è possibile usare gli strumenti PostgreSQL pg_dump e pg_restore/psql.

Frequenza di backup

I backup nelle istanze del server flessibile di Database di Azure per PostgreSQL sono basati su snapshot. Il primo backup dello snapshot viene pianificato subito dopo la creazione di un server. I backup degli snapshot vengono eseguiti una volta al giorno. Se non vengono apportate ulteriori modifiche ai database nel server dopo l'ultimo backup dello snapshot, i backup degli snapshot vengono sospesi temporaneamente. Non appena viene modificato un database nel server, viene immediatamente creato un nuovo snapshot per acquisire le modifiche più recenti. Il primo snapshot è un backup completo e gli snapshot consecutivi sono backup differenziali.

I backup del log delle transazioni vengono eseguiti a frequenze diverse, a seconda del carico di lavoro e del momento in cui il file WAL è pieno e pronto per l'archiviazione. In generale, il valore RPO ritardato (obiettivo del punto di ripristino) può essere fino a 5 minuti.

opzioni di ridondanza per il backup

Il server flessibile di Database di Azure per PostgreSQL archivia più copie dei backup per proteggere i dati da eventi pianificati e non pianificati. Questi eventi possono includere errori hardware temporanei, interruzioni di rete o interruzioni dell'alimentazione ed emergenze naturali. La ridondanza del backup garantisce che il database soddisfi le destinazioni di disponibilità e durabilità, anche in caso di errori.

Il server flessibile di Database di Azure per PostgreSQL offre tre opzioni:

• Archivio di backup con ridondanza della zona: questa opzione viene scelta automaticamente per le aree che supportano le zone di disponibilità. Quando i backup vengono archiviati nell'archiviazione di backup con ridondanza geografica, tre copie dei dati vengono mantenute all'interno dell'area in cui è ospitato il server. Inoltre, i dati vengono replicati in un'area abbinata per una protezione aggiuntiva.

  Questa opzione offre la disponibilità dei dati di backup tra zone di disponibilità e limita la replica dei dati all'interno di un paese/area geografica per soddisfare i requisiti di residenza dei dati. Questa opzione offre almeno il 99,9999999999 percento (12 nove) durabilità degli oggetti di backup in un anno.

• Archivio di backup con ridondanza locale: questa opzione viene scelta automaticamente per le aree che non supportano ancora le zone di disponibilità. Quando i backup vengono memorizzati nell'archivio di backup con ridondanza locale, più copie dei backup vengono archiviate nello stesso data center.

  Questa opzione consente di proteggere i dati da errori di rack e unità del server. Fornisce almeno il 99,999999999% (11 nove) di durabilità degli oggetti di backup 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 di area geografica: è possibile scegliere questa opzione al momento della creazione del server. Quando i backup vengono archiviati nell'archiviazione di backup con ridondanza geografica, oltre a tre copie di dati archiviati nell'area in cui è ospitato il server, i dati vengono replicati in un'area geografica associata.

  Questa opzione consente di ripristinare il server in un'area diversa in caso di emergenza. Inoltre, in questo modo si ottiene almeno il 99,99999999999999% (16 nove) di durabilità degli oggetti di backup nell'arco di un anno specifico.

  La ridondanza geografica è supportata per i server ospitati in una delle aree associate di Azure.

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

È possibile configurare l'archiviazione con ridondanza geografica per il backup solo durante la creazione del server. Dopo il provisioning di un server, non è possibile cambiare l'opzione di ridondanza per l'archivio di backup.

Conservazione dei backup

I backup vengono conservati in base al periodo di conservazione impostato per il server. È possibile selezionare un periodo di conservazione compreso tra 7 (impostazione predefinita) e 35 giorni. È possibile impostare il periodo di conservazione durante la creazione del server o modificarlo in un secondo momento. I backup vengono conservati anche per i server arrestati.

Il periodo di conservazione dei backup determina l'intervallo di tempo da cui è possibile recuperare un ripristino temporizzato usando i backup disponibili. È anche 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 7 giorni, la finestra di ripristino è gli ultimi 7 giorni. In questo scenario vengono conservati tutti i dati e i log necessari per recuperare e ripristinare il server negli ultimi 7 giorni.

Costo dell'archiviazione dei backup

Il server flessibile di Database di Azure per PostgreSQL offre fino al 100% dell'archiviazione del server di cui è stato effettuato il provisioning come risorsa di archiviazione di backup senza costi aggiuntivi. Tutte le risorse di archiviazione di backup aggiuntive usate vengono addebitate in gigabyte al mese.

Ad esempio, se è stato effettuato il provisioning di un server con 250 gibibyte (GiB) di archiviazione, si dispone di 250 GiB di capacità di archiviazione di backup senza costi aggiuntivi. Se l'utilizzo giornaliero del backup è 25 GiB, è possibile avere fino a 10 giorni di archiviazione di backup gratuita. Il consumo di archiviazione di backup superiore a 250 GiB viene addebitato come definito nel modello di determinazione prezzi.

Se il server è stato configurato con il backup con ridondanza geografica, i dati di backup vengono copiati anche nell'area abbinata di Azure. Quindi, le dimensioni del backup saranno due volte le dimensioni della copia di backup locale. La fatturazione viene calcolata come ( (2 x dimensioni del backup locale) - dimensioni di archiviazione con provisioning ) x prezzo @ gigabyte al mese.

È possibile usare la metrica di archiviazione di backup usata 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.

Nota

Indipendentemente dalle dimensioni del database, l'attività transazionale pesante nel server genera più file WAL. L'aumento dei file aumenta a sua volta l'archiviazione di backup.

Recupero temporizzato

Nel server flessibile di Database di Azure per PostgreSQL, l'esecuzione di un ripristino temporizzato crea un nuovo server nella stessa area del server di origine, ma è possibile scegliere la zona di disponibilità. Viene creato con la configurazione del server di origine per il piano tariffario, la generazione di calcolo, il numero di core virtuali, le dimensioni di archiviazione, il periodo di conservazione dei backup e l'opzione di ridondanza del backup. I tag e le impostazioni, come ad esempio le impostazioni delle reti virtuali e del firewall, vengono anche ereditati dal server di origine.

I file di database fisici vengono prima ripristinati dai backup dello snapshot nel percorso dei dati del server. Il backup appropriato eseguito prima del momento desiderato viene scelto e ripristinato automaticamente. Viene quindi avviato un processo di ripristino usando i file WAL per portare il database a uno stato coerente.

Si supponga, ad esempio, che i backup vengano eseguiti alle 11:00 ogni notte. Se il punto di ripristino è per il 15 agosto alle 10:00, viene ripristinato il backup giornaliero del 14 agosto. Il database verrà ripristinato fino alle 10:00 del 15 agosto usando il backup del log delle transazioni dal 14 agosto alle 11:00 del 15 agosto 10:00.

Per ripristinare il server di database, vedere questi passaggi.

Importante

Un'operazione di ripristino nel server flessibile di Database di Azure per PostgreSQL crea sempre un nuovo server di database con il nome specificato. Non sovrascrive il server di database esistente.

Il ripristino temporizzato è utile in scenari come i seguenti:

• Un utente elimina accidentalmente dati, una tabella o un database.
• Un'applicazione sovrascrive accidentalmente dati validi con dati non validi a causa di un difetto dell'applicazione.
• Si vuole clonare il server per test, sviluppo o per la verifica dei dati.

Con il backup continuo dei log delle transazioni, è possibile eseguire il ripristino all'ultima transazione. È possibile scegliere tra le opzioni di ripristino seguenti:

• Punto di ripristino più recente (ora): questa è l'opzione predefinita, che consente di ripristinare il server all'ultimo punto nel tempo.

• Ppunto di ripristino personalizzato: questa opzione consente di scegliere qualsiasi punto nel tempo entro il periodo di conservazione definito per questa istanza del server flessibile di Database di Azure per PostgreSQL. Per impostazione predefinita, viene selezionata automaticamente l'ora più recente in formato UTC. La selezione automatica è utile se si desidera ripristinare l'ultima transazione sottoposta a commit a scopo di test. Facoltativamente, è possibile scegliere altri giorni e orari.

• 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 l'istanza del server flessibile di Database di Azure per PostgreSQL. Il ripristino più rapido è disponibile scegliendo direttamente il timestamp dall'elenco dei backup. Questa operazione di ripristino effettua il provisioning di un server e ripristina semplicemente il backup completo dello snapshot e non richiede alcun ripristino dei log, che lo rende veloce. È consigliabile selezionare un timestamp di backup maggiore del primo punto di ripristino per un'operazione di ripristino ottimale.

Il tempo necessario per il ripristino usando le opzioni del punto di ripristino più recente e personalizzato varia in base a fattori quali il volume dei log delle transazioni da elaborare dopo l'ultimo backup e il numero totale di database recuperati contemporaneamente nella stessa area Il tempo di ripristino complessivo in genere richiede da pochi minuti a poche ore.

Se si configura il server all'interno di una rete virtuale, è possibile eseguire il ripristino nella stessa rete virtuale o in una rete virtuale diversa. Tuttavia, non è possibile ripristinare l'accesso pubblico. Analogamente, se il server è stato configurato con accesso pubblico, non è possibile ripristinare l'accesso alla rete virtuale privata.

Importante

I server eliminati non possono essere ripristinati. Se si elimina il server, è possibile seguire le indicazioni riportate in Ripristinare un server flessibile di Database di Azure per Database di Azure per PostgreSQL. Usare il blocco delle risorse di Azure per impedire l'eliminazione accidentale del server.

Backup e ripristino con ridondanza geografica

Per abilitare il backup con ridondanza geografica dal riquadro Calcolo e archiviazione nel portale di Azure, vedere la guida introduttiva.

Importante

Il backup con ridondanza geografica può essere configurato solo al momento della creazione del server.

Dopo aver configurato il server con il backup con ridondanza geografica, è possibile ripristinarlo in un'area geografica associata. Per altre informazioni, vedere le aree supportate per il backup con ridondanza geografica.

Quando il server è configurato con il backup con ridondanza geografica, i dati di backup e i log delle transazioni vengono copiati nell'area abbinata in modo asincrono tramite la replica di archiviazione. Dopo aver creato un server, attendere almeno un'ora prima di avviare un ripristino geografico. Ciò consente la replica del primo set di dati di backup nell'area abbinata.

Successivamente, i log delle transazioni e i backup giornalieri vengono copiati in modo asincrono nell'area abbinata. Potrebbero esserci fino a un'ora di ritardo nella trasmissione dei dati. È quindi possibile prevedere fino a un'ora di RPO quando si esegue il ripristino. È possibile ripristinare solo gli ultimi dati di backup disponibili nell'area abbinata. Attualmente, il ripristino temporizzato dei backup con ridondanza geografica non è disponibile.

Il tempo stimato per il recupero dell'RTO del server (obiettivo del tempo di ripristino) dipende da fattori quali le dimensioni del database, l'ora dell'ultimo backup del database e la quantità di wal da elaborare fino all'ultimo backup ricevuto. Il tempo di recupero complessivo richiede in genere da alcuni minuti fino a poche ore.

Durante il ripristino geografico, le configurazioni del server che possono essere modificate includono le impostazioni della rete virtuale e la possibilità di rimuovere il backup con ridondanza geografica dal server ripristinato. La modifica di altre configurazioni del server, ad esempio calcolo, archiviazione o piano tariffario (possibilità di burst, utilizzo generico o ottimizzato per la memoria) durante il ripristino geografico non è supportata.

Per altre informazioni sull'esecuzione di un ripristino geografico, vedere la guida pratica.

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. Prima di poter effettuare il provisioning di server con ridondanza geografica nell'area geografica associata, è necessario attendere che l'area primaria sia attiva.

Con l'area primaria inattiva, è comunque possibile ripristinare geograficamente il server di origine nell'area geografica associata. Per altre informazioni sull'esecuzione di un ripristino geografico, vedere la guida pratica. È consigliabile usare le repliche geografiche come strategia di ripristino di emergenza se è necessario configurare il ripristino di emergenza in qualsiasi area o se l'area primaria non supporta i backup con ridondanza geografica

Ripristino e rete

Recupero temporizzato

Se il server di origine è configurato con una rete di accesso pubblico, è possibile ripristinare solo l'accesso pubblico.

Se il server di origine è configurato con una rete virtuale di accesso privato, è possibile ripristinare la stessa rete virtuale o una rete virtuale diversa. Non è possibile eseguire il ripristino temporizzato tra l'accesso pubblico e privato.

Ripristino geografico

Se il server di origine è configurato con una rete di accesso pubblico, è possibile ripristinare solo l'accesso pubblico. Le regole del firewall esistenti nel server di origine vengono copiate nel server ripristinato. Gli endpoint privati non vengono acquisiti. Al termine dell'operazione di ripristino, verificare se è necessario modificare una delle regole del firewall eseguite e creare eventuali endpoint privati necessari.

Se il server di origine è configurato con una rete virtuale di accesso privato, è possibile eseguire il ripristino solo in una rete virtuale diversa, perché le reti virtuali non possono estendersi su aree. Non è possibile eseguire il ripristino geografico tra l'accesso pubblico e privato.

Attività successive al ripristino

Dopo aver ripristinato il server, è possibile eseguire le attività seguenti per effettuare il backup e l'esecuzione di utenti e applicazioni:

• Se il nuovo server è destinato a sostituire il server originale, reindirizzare i client e le applicazioni client al nuovo server. Modificare il nome del server della stringa di connessione in modo che punti al nuovo server.

• Assicurarsi che siano presenti regole di rete virtuale, firewall a livello di server e endpoint privati appropriati per le connessioni utente. Nella rete di accesso pubblico le regole vengono copiate dal server originale, ma queste potrebbero non essere quelle necessarie nell'ambiente ripristinato. Quindi, modificarli in base alle esigenze. Gli endpoint privati non vengono trasportati. Creare tutti gli endpoint privati necessari nel server ripristinato. Nella rete virtuale di accesso privato, il ripristino non copia in alcun elemento dell'infrastruttura di rete dall'origine alle reti server ripristinate. Qualsiasi elemento correlato alla configurazione della rete virtuale (Rete virtuale), delle subnet o dei gruppi di sicurezza di rete deve essere presa in considerazione come attività di post-ripristino.

• Aumentare o ridurre le prestazioni di calcolo del server ripristinato in base alle esigenze.

• Assicurarsi che siano presenti gli account di accesso e le autorizzazioni a livello di database appropriati.

• Configurare gli avvisi in base alle proprie esigenze.

• Se il server di origine da cui è stato eseguito il ripristino è stato configurato con disponibilità elevata e si vuole configurare il server ripristinato con disponibilità elevata, è possibile seguire questa procedura.

• Se il server di origine da cui è stato eseguito il ripristino è stato configurato con repliche di lettura elevata e si vuole configurare le repliche di lettura nel server ripristinato, è possibile seguire questa procedura.

Backup su richiesta (anteprima)

Database di Azure per PostgreSQL server flessibile genera automaticamente snapshot del volume di archiviazione dell'intera istanza del database, che copre tutti i database, come parte dei backup pianificati. Inoltre, è possibile creare un backup su richiesta ogni volta che è necessario, ideale per scenari come la preparazione per un'operazione potenzialmente rischiosa o l'esecuzione di aggiornamenti periodici al di fuori della normale pianificazione del backup.

I backup su richiesta possono essere eseguiti oltre ai backup automatici pianificati. Questi backup vengono conservati in base alla finestra di conservazione dei backup. È possibile eliminare questi backup su richiesta in qualsiasi momento, se non sono più necessari. Per avviare un backup su richiesta, è sufficiente selezionare l'istanza del database di cui si vuole eseguire il backup e specificare un nome di backup. Questi backup vengono archiviati insieme ai backup automatizzati, ma solo i backup su richiesta possono essere eliminati dagli utenti, poiché i backup automatizzati vengono gestiti e conservati dal servizio Server flessibile per soddisfare i requisiti di conservazione dei backup.

Per altre informazioni sull'esecuzione di un backup su richiesta, vedere la guida pratica.

Limiti

La funzionalità di backup su richiesta non è attualmente supportata con il livello di calcolo del server con burst.

Problemi noti

Microsoft è a conoscenza di un bug esistente che consente di eseguire backup su richiesta nelle repliche, anche se il ripristino temporizzato non è supportato in questo contesto. Questo problema verrà risolto per garantire che i backup su richiesta possano essere eseguiti solo nel server primario.

Conservazione a lungo termine

I servizi server flessibili di Backup di Azure e Database di Azure per PostgreSQL hanno creato una soluzione di backup a lungo termine di livello aziendale per le istanze del server flessibile di Database di Azure per PostgreSQL che conservano i backup per un massimo di 10 anni. È possibile usare la conservazione a lungo termine (LTR) in modo indipendente o oltre alla soluzione di backup automatizzata offerta da Database di Azure per PostgreSQL server flessibile, che offre la conservazione fino a 35 giorni. I backup automatizzati sono backup fisici 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à, sono più granulari e vengono eseguiti come backup logici usando i pg_dump nativi. Oltre alla conservazione a lungo termine, la soluzione offre le funzionalità seguenti:

• Backup pianificato e su richiesta controllato dal cliente a livello di singoli database.
• Monitoraggio centralizzato di tutte le operazioni e di tutti i processi.
• 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).
• L'uso di pg_dump consente una maggiore flessibilità nel ripristino dei dati in versioni diverse del database.
• Gli insiemi di credenziali di Backup di Azure supportano funzionalità di eliminazione temporanea e di eliminazione temporanea (anteprima), proteggendo i dati.
• Supporto per il backup con conservazione a lungo termine per i server abilitati per CMK

Limitazioni e considerazioni

• I ripristini con conservazione a lungo termine sono attualmente disponibili solo come "Ripristina come file" negli account di archiviazione, con la funzionalità "Ripristina come server" prevista per il futuro.
• La conservazione a lungo termine esegue il backup di tutti i database in istanze del server flessibili e non è possibile selezionare singoli database per la configurazione con conservazione a lungo termine.
• Il backup con conservazione a lungo termine non è supportato nelle repliche geografiche, ma può essere eseguito dai server primari.
• La dimensione massima supportata del database per il backup con conservazione a lungo termine è 4 TiB.
• I backup con conservazione a lungo termine possono essere pianificati settimanalmente, mensili o annuali. La pianificazione del backup giornaliero non è attualmente supportata.

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

Domande frequenti

Domande relative al backup

• In che modo Azure gestisce il backup del server?

  Per impostazione predefinita, il server flessibile di Database di Azure per PostgreSQL consente backup automatici dell'intero server, che includono tutti i database creati, con un periodo di conservazione predefinito di 7 giorni. I backup automatizzati includono uno snapshot incrementale giornaliero del database. I file di log (WAL) vengono archiviati in Archiviazione BLOB di Azure in modo continuo.

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

  No. Attualmente, il server flessibile di Database di Azure per PostgreSQL supporta un massimo di 35 giorni di conservazione. È possibile usare i backup manuali per un requisito di conservazione a lungo termine usando Backup di Azure.

• Come si esegue manualmente il backup delle istanze del server flessibile di Database di Azure per PostgreSQL?

  È possibile creare manualmente uno snapshot fisico usando la funzionalità di backup su richiesta, è anche possibile eseguire backup logici usando lo strumento PostgreSQL pg_dump. Per esempi, vedere Eseguire la migrazione del database del server flessibile di Database di Azure per PostgreSQL usando dump e ripristino.

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

  Azure gestisce le finestre di backup e non è possibile personalizzarle. Il primo backup completo dello snapshot viene pianificato subito dopo la creazione di un server. I backup di snapshot successivi sono incrementali e vengono eseguiti una volta al giorno.

• I backup sono crittografati?

  Sì. Tutti i Database di Azure per PostgreSQL dati, backup e file temporanei del server flessibili creati durante l'esecuzione delle query vengono crittografati tramite crittografia AES (Advanced Encryption Standard) a 256 bit. La crittografia dell'archiviazione è sempre attiva e non può essere disabilitata.

• È possibile ripristinare un database singolo o alcuni database in un server?

  Il ripristino di un database singolo o di alcune tabelle o database non è supportato direttamente. È tuttavia possibile ripristinare l'intero server in un nuovo server e quindi estrarre tabelle o database e importarli nel nuovo server.

• Il server è disponibile mentre è in corso un backup?

  Sì. I backup sono operazioni online che usano snapshot. L'operazione sugli snapshot richiede solo alcuni secondi e non interferisce con i carichi di lavoro di produzione, per garantire 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.

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

  Il server flessibile di Database di Azure per PostgreSQL crea automaticamente backup del server e li archivia in:

  • Archiviazione con ridondanza della zona, in aree in cui sono supportate più zone.
  • Archiviazione con ridondanza locale, in aree che non supportano ancora più zone.
  • Area abbinata, se si configura il backup con ridondanza geografica.

  Questi file di backup non possono essere esportati.

  I backup possono essere usati per ripristinare il server solo a un momento specifico. Il periodo di conservazione dei backup predefinito è di sette giorni, Facoltativamente, è possibile configurare la conservazione dei backup fino a 35 giorni.

• Con il backup con ridondanza geografica, con quale frequenza viene copiato il backup nell'area abbinata?

  Quando il server è configurato con il backup con ridondanza geografica, i dati di backup vengono archiviati in un account di archiviazione con ridondanza geografica. L'account di archiviazione copia i file di dati nell'area abbinata quando viene eseguito il backup giornaliero nel server primario. I file WAL vengono sottoposti a backup quando sono pronti per l'archiviazione.

  I dati di backup vengono copiati in modo asincrono in modo continuo nell'area abbinata. È possibile prevedere fino a un'ora di ritardo nella ricezione dei dati di backup.

• È possibile eseguire il ripristino temporizzato nell'area remota?

  No. I dati vengono recuperati negli ultimi dati di backup disponibili nell'area remota.

• Come vengono eseguiti i backup in server abilitati per la disponibilità elevata?

  I volumi di dati nel server flessibile di Database di Azure per PostgreSQL vengono sottoposti a backup tramite snapshot incrementali del disco gestito dal server primario. Il backup WAL viene eseguito dal server primario o dal server di standby.

• Come è possibile verificare che vengono eseguiti i backup nel server?

  Il modo migliore per controllare i backup consiste nell'eseguire il ripristino temporizzato periodico e assicurarsi che i backup siano validi e ripristinabili. I file o le operazioni di backup non vengono divulgati agli utenti finali.

• Dove è possibile visualizzare l'utilizzo del backup?

  Nel portale di Azure, in Monitoraggio selezionare Metriche. In Archivio di backup usatoè possibile monitorare l'utilizzo totale del backup.

• Cosa accade ai backup se si elimina il server?

  Se si elimina un 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 dopo la distribuzione, gli amministratori possono usare i blocchi di gestione.

• 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. Successivamente, la conservazione dei backup per il server attivo è governata dalla relativa finestra di conservazione.

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

  Il server flessibile di Database di Azure per PostgreSQL offre fino al 100% dell'archiviazione del server di cui è stato effettuato il provisioning come risorsa di archiviazione di backup senza costi aggiuntivi. Qualsiasi altra risorsa di archiviazione di backup usata viene addebitata in gigabyte al mese, come definito nel modello tariffario.

  L'opzione di conservazione dei backup e ridondanza del backup selezionata, insieme all'attività transazionale nel server, influisce direttamente sull'archivio e sulla fatturazione totali dei backup.

• Come verrà addebitato un server arrestato?

  Mentre l'istanza del server viene arrestata, non vengono eseguiti nuovi backup. Vengono addebitati costi per l'archiviazione di cui è stato effettuato il provisioning 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. Tutti i dati di backup in eccesso verranno addebitati in base al prezzo di backup.

• Il server è stato configurato con disponibilità elevata con ridondanza della zona. Si eseguono due backup e verranno addebitati due volte?

  No. Indipendentemente dai server a disponibilità elevata o non a disponibilità elevata, viene mantenuto un solo set di copie di backup. L'addebito viene addebitato una sola volta.

Domande relative al ripristino

• Come si ripristina il server?

  Azure supporta il ripristino temporizzato per tutti i server. Gli utenti possono eseguire il ripristino al punto di ripristino più recente o a un punto di ripristino personalizzato usando il portale di Azure, l'interfaccia della riga di comando di Azure e l'API.

  Per ripristinare il server da backup manuali usando strumenti come pg_dump, è prima possibile creare un'istanza del server flessibile di Database di Azure per PostgreSQL e quindi ripristinare i database nel server usando pg_restore.

• È possibile eseguire il ripristino in un'altra zona di disponibilità all'interno della stessa area?

  Sì. Se l'area supporta più zone di disponibilità, il backup viene archiviato in un account di archiviazione con ridondanza della zona in modo da poter eseguire il ripristino in un'altra zona.

• Quanto tempo richiede un PITR? Perché il ripristino richiede molto tempo?

  L'operazione di ripristino dei dati da uno snapshot non dipende dalle dimensioni dei dati. Tuttavia, l'intervallo del processo di ripristino che applica i log (attività delle transazioni alla riproduzione) può variare a seconda del backup precedente della data/ora richiesta e del numero di log da elaborare. Questo vale sia per il ripristino all'interno della stessa zona che per il ripristino dei dati in una zona diversa.

• Se si ripristina il server abilitato per la disponibilità elevata, il server di ripristino viene configurato automaticamente con disponibilità elevata?

  No. Il server viene ripristinato come istanza singola del server flessibile di Database di Azure per PostgreSQL. Al termine del ripristino, è possibile configurare facoltativamente il server con disponibilità elevata.

• Il server è stato configurato all'interno di una rete virtuale. È possibile eseguire il ripristino in un'altra rete virtuale?

  Sì. Al momento del ripristino, scegliere una rete virtuale diversa in cui eseguire il ripristino.

• È possibile ripristinare il server di accesso pubblico a una rete virtuale o viceversa?

  No. Il server flessibile di Database di Azure per PostgreSQL attualmente non supporta il ripristino dei server attraverso l'accesso pubblico e privato.

• Come è possibile tenere traccia dell'operazione di ripristino?

  Attualmente, non è possibile tenere traccia dell'operazione di ripristino. È possibile monitorare il log attività per verificare se l'operazione è in corso o completa.

Passaggi successivi

• Informazioni sulla continuità aziendale.
• Informazioni sulla disponibilità elevata con ridondanza della zona.
• Informazioni sulle modalità di ripristino.