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

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

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 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. Usare questi backup per ripristinare un server in qualsiasi momento entro il periodo di conservazione dei backup configurato.

Il periodo di conservazione dei backup predefinito è di sette 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.

Non è possibile esportare questi file di backup o usarli per creare server esterni all'istanza del server flessibile 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 si apportano ulteriori modifiche ai database nel server dopo l'ultimo backup dello snapshot, il sistema sospende temporaneamente i backup degli snapshot. Non appena si modifica un database nel server, il sistema acquisisce immediatamente 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 ritardo dell'RPO (obiettivo del punto di ripristino) può arrivare fino a cinque minuti.

Opzioni di ridondanza per il backup

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.

Database di Azure per PostgreSQL offre tre opzioni:

• Archiviazione di backup con ridondanza della zona: Database di Azure per PostgreSQL seleziona automaticamente questa opzione per le aree che supportano le zone di disponibilità. Quando si archiviano i backup nell'archiviazione di backup con ridondanza della zona, il servizio mantiene tre copie dei dati all'interno della zona di disponibilità in cui è ospitato il server. Inoltre, il servizio replica i dati in un'altra zona di disponibilità per una maggiore protezione.

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

• Archiviazione di backup con ridondanza locale: Database di Azure per PostgreSQL seleziona automaticamente questa opzione per le aree che non supportano ancora le zone di disponibilità. Quando si archiviano i backup nell'archiviazione di backup con ridondanza locale, il servizio archivia più copie dei backup 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, il servizio imposta l'archiviazione di backup per i server con alta disponibilità nella stessa zona o senza configurazione di alta disponibilità come archiviazione con ridondanza locale.

• Archiviazione di backup con ridondanza geografica: è possibile scegliere questa opzione al momento della creazione del server. Quando si archivia i backup nell'archiviazione di backup con ridondanza geografica, oltre a tre copie di dati archiviati nell'area in cui è ospitato il server, il servizio replica i dati 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 abbinate 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 modificare l'opzione di ridondanza dello storage di backup.

Conservazione dei backup

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

Il periodo di conservazione dei backup determina l'intervallo di tempo per il recupero di un ripristino temporizzato (PITR) dai backup disponibili. È anche possibile considerare il periodo di conservazione dei backup come finestra di ripristino dal punto di vista del ripristino.

Lo spazio di archiviazione dei backup conserva tutti i backup necessari per eseguire un ripristino a un momento specifico (PITR) durante il periodo di conservazione dei backup. Ad esempio, se si imposta il periodo di conservazione dei backup su 7 giorni, la finestra di ripristino è gli ultimi 7 giorni. In questo scenario, l'archiviazione di backup conserva tutti i dati e i log necessari per ripristinare e ripristinare il server negli ultimi 7 giorni.

Costo dell'archiviazione dei backup

Azure Database per PostgreSQL offre fino al 100% dello spazio di archiviazione del server di cui è stato effettuato il provisioning come spazio di archiviazione di backup senza costi aggiuntivi. Si paga per qualsiasi spazio di archiviazione di backup aggiuntivo usato in gigabyte al mese.

Ad esempio, se si effettua il provisioning di un server con 250 gibibyte (GiB) di spazio di archiviazione, si ottengono 250 GiB di capacità di archiviazione di backup senza costi aggiuntivi. Se l'utilizzo giornaliero del backup è di 25 GiB, è possibile avere fino a 10 giorni di archiviazione di backup gratuita. Si paga per il consumo di archiviazione di backup superiore a 250 GiB, come definito nel modello di determinazione prezzi.

Se si configura il server con il backup con ridondanza geografica, i dati di backup vengono copiati anche nell'area associata Azure. Quindi, le dimensioni del backup sono due volte le dimensioni della copia di backup locale. La fatturazione viene calcolata come ((2 x dimensioni del backup locale) - spazio di archiviazione con provisioning) x prezzo a gigabyte al mese.

Usare la metrica Backup Storage Used (Archiviazione di backup usata) nel portale di Azure per monitorare l'archiviazione di backup utilizzata 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.

Recupero temporizzato

In un'istanza del 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 file di database fisici vengono prima ripristinati dai backup snapshot nella posizione 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 viene ripristinato fino alle 10:00 del 15 agosto utilizzando il backup del log delle transazioni dal 14 agosto alle 23:00 al 15 agosto alle 10:00.

Per ripristinare il server di database, vedere una delle opzioni seguenti:

• Ripristinare il punto di ripristino più recente.
• Ripristinare il punto di ripristino personalizzato.
• Ripristinare il backup completo (ripristino rapido).
• Eseguire il ripristino nell'area abbinata (ripristino geografico).

Il PITR è 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.

Usando 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 ripristina il server al momento più recente.

• 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 ripristina il server nel tempo più veloce possibile entro il periodo di conservazione definito per l'istanza del server flessibile 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. Non richiede alcun ripristino dei log, che lo rende veloce. Selezionare una data e ora del backup successiva al punto di ripristino più remoto per completare correttamente l'operazione di ripristino.

Il tempo necessario per il ripristino tramite le opzioni dei punti di ripristino più recenti e personalizzati 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 recupero complessivo richiede in genere da alcuni minuti fino 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.

Backup e ripristino con ridondanza geografica

Per abilitare il backup con ridondanza geografica dal riquadro Calcolo e archiviazione nel portale di Azure, vedere Creare un database di Azure per PostgreSQL.

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 si configura il server con 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. Questo periodo di attesa 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 PITR (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, è possibile modificare le configurazioni del server che includono le impostazioni di rete virtuale e la possibilità di rimuovere il backup con ridondanza geografica dal server ripristinato. La modifica di altre configurazioni del server -such come calcolo, archiviazione o piano tariffario (burstable, utilizzo generico o ottimizzato per la memoria) non è supportata durante il ripristino geografico.

Per ulteriori informazioni, vedere il Ripristino nell'area abbinata (ripristino geografico).

Ripristino e rete

Recupero temporizzato

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

Se si configura il server di origine con una rete virtuale di accesso privato , è possibile ripristinare la stessa rete virtuale o in una rete virtuale diversa. Non è possibile eseguire il PITR tra l'accesso pubblico e privato.

Ripristino geografico

Se si configura il server di origine con una rete di accesso pubblico , è possibile ripristinare solo l'accesso pubblico. È inoltre necessario applicare le regole del firewall al termine dell'operazione di ripristino.

Se si configura il server di origine 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 il ripristino del server, eseguire le attività seguenti per ripristinare il funzionamento di utenti e applicazioni:

• Se il nuovo server sostituisce 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.

• I valori di tutti i parametri nel server originale non vengono applicati automaticamente al nuovo server. Assicurarsi di riconfigurare tutti i parametri nel nuovo server in base ai requisiti del nuovo server.

• Assicurarsi che siano presenti regole del firewall a livello di server, endpoint privati e regole di rete virtuale appropriate per le connessioni utente. Queste regole non vengono copiate dal server originale.

• 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 ripristinato è stato configurato con disponibilità elevata e si vuole configurare il server ripristinato con disponibilità elevata, seguire questa procedura.

• Se il server di origine da cui è stato ripristinato è stato configurato con repliche in lettura e si desidera configurare le repliche in lettura nel server ripristinato, seguire le istruzioni in Creare una replica di lettura.

Backup su richiesta

L'ista de server flessibile di Database di Azure per PostgreSQL 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. Questa opzione è ideale per scenari come la preparazione per un'operazione potenzialmente rischiosa o l'esecuzione di aggiornamenti periodici al di fuori della normale pianificazione dei backup.

Eseguire backup su richiesta oltre ai backup automatici pianificati. La finestra di conservazione dei backup determina per quanto tempo conservare questi backup. È possibile eliminare i backup su richiesta in qualsiasi momento, se non sono più necessari. Per avviare un backup su richiesta, 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 gli utenti possono eliminare i backup su richiesta. Il servizio gestisce e conserva i backup automatizzati per soddisfare i requisiti di conservazione dei backup.

Per altre informazioni, vedere Eseguire backup su richiesta.

Limitazioni

• Il livello di calcolo del server Burstable non supporta la funzionalità di backup su richiesta.
• Il livello di archiviazione SSDv2 non supporta la funzionalità di backup su richiesta.
• È possibile eseguire fino a sette backup su richiesta per ogni istanza del server flessibile. La finestra di conservazione dei backup determina per quanto tempo conservare questi backup.

Conservazione a lungo termine

Backup di Azure e servizi di Database di Azure per PostgreSQL offrono una soluzione di backup a lungo termine di livello aziendale per Database di Azure per PostgreSQL istanze di server flessibili che conservano i backup per un massimo di 10 anni. È possibile usare la conservazione a lungo termine (LTR) in modo indipendente o insieme alla soluzione di backup automatizzata offerta da Database di Azure per PostgreSQL, 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 (negli account di archiviazione gestiti da Backup di Azure).
• L'uso di pg_dump offre maggiore flessibilità nel ripristino dei dati in versioni diverse del database.
• I vault di backup di Azure supportano le funzionalità di immutabilità ed eliminazione temporanea (anteprima), proteggendo i tuoi dati.
• Supporto per il backup con conservazione a lungo termine per i server abilitati per CMK.

Limitazioni e considerazioni

• Testate il backup e il ripristino LTR subito dopo la configurazione per verificare che soddisfino i requisiti aziendali.
• I ripristini con conservazione a lungo termine sono attualmente disponibili solo tramite Ripristina come file negli account di archiviazione, mentre la funzionalità Ripristina come server è prevista in futuro.
• LTR esegue il backup di tutti i database nelle istanze di server flessibile e non è possibile selezionare i singoli database per la configurazione di LTR.
• Il backup LTR non è supportato sulle repliche, ma è possibile eseguirlo sui server primari.
• Le dimensioni massime supportate del database per i backup di conservazione a lungo termine (LTR) sono pari a 1 TiB.
• È possibile pianificare backup con conservazione a lungo termine su base settimanale, mensile o annuale. La pianificazione del backup giornaliero non è attualmente supportata.
• I backup con conservazione a lungo termine non supportano tabelle contenenti una riga con lunghezza BYTEA superiore a 500 MB.
• Quando si ripristinano i ruoli per gli utenti di Microsoft Entra, assicurarsi che l'autenticazione Microsoft Entra sia abilitata e che sia stato eseguito l'accesso come amministratore di Microsoft Entra per creare altri utenti. Il tentativo di creare ruoli Entra come utente normale genera errori.

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, Database di Azure per PostgreSQL abilita backup automatici dell'intero server (che include tutti i database creati) con un periodo di conservazione predefinito di sette giorni. I backup automatizzati includono uno snapshot incrementale giornaliero del database. I file di log (WAL) vengono archiviati continuamente nella Blob Storage di Azure.

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

  No. Database di Azure per PostgreSQL supporta attualmente un massimo di 35 giorni di conservazione. 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 di Azure per PostgreSQL usando il dump e il 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 dati dell'istanza del server flessibile di Database di Azure per PostgreSQL, i backup e i file temporanei 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 eliminare tabelle o database non necessari 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 automatizzati e come si gestiscono la conservazione?

  L'istanza del 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.

  Non è possibile esportare questi file di backup man mano che vengono archiviati in account di archiviazione gestiti da Microsoft. È possibile accedere in sola lettura per ripristinare questi file, ma non modificarli o eliminarli. I file di backup vengono eliminati automaticamente dopo il periodo di conservazione.

  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 si configura il server con 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.

• Posso eseguire il PITR nella regione 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 in un'istanza del server flessibile di Database 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 i backup vengano eseguiti 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. Le operazioni di backup o i file non sono esposti agli utenti finali.

• Dove è possibile visualizzare l'utilizzo del backup?

  Nel portale di Azure, in Monitoraggio selezionare Metriche. In Archiviazione di backup usata è 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. Il servizio mantiene tutti i backup meno recenti (all'interno della finestra di conservazione) al momento dell'arresto del server fino al riavvio del server. Successivamente, la conservazione dei backup per il server attivo è governata dalla relativa finestra di conservazione.

• Come vengono addebitati e fatturati i backup?

  Azure Database per PostgreSQL offre fino al 100% dello spazio di archiviazione del server di cui è stato effettuato il provisioning come spazio di archiviazione di backup senza costi aggiuntivi. Si paga per qualsiasi spazio di archiviazione di backup aggiuntivo usato, che viene addebitato in gigabyte al mese, come definito nel modello di determinazione prezzi.

  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 viene fatturato un server fermato?

  Mentre l'istanza del server viene arrestata, non vengono eseguiti nuovi backup. Si paga l'archiviazione di cui è stato effettuato il provisioning e l'archiviazione di backup (backup conservati entro il periodo di conservazione specificato).

  L'archiviazione di backup gratuita è limitata alle dimensioni del database di cui è stato effettuato il provisioning. Si paga per eventuali dati di backup in eccesso 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, il servizio gestisce un solo set di copie di backup. Si paga una sola volta.

Domande relative al ripristino

• Come si ripristina il server?

  Azure supporta il PITR per tutti i server. È possibile eseguire il ripristino al punto di ripristino più recente o a un punto di ripristino personalizzato usando il portale di Azure, il 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 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, la tempistica del processo di ripristino che applica i log (attività delle transazioni da rieseguire) può variare, a seconda del backup precedente relativo alla data e all'ora richieste e del numero di log da elaborare. Questa condizione si applica sia al ripristino all'interno della stessa zona che al 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. Database di Azure per PostgreSQL attualmente non supporta il ripristino dei server tra 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.

Contenuti correlati

• Ripristinare il punto di ripristino più recente.
• Ripristinare il punto di ripristino personalizzato.
• Ripristinare il backup completo (ripristino rapido).
• Eseguire il ripristino nell'area abbinata (ripristino geografico).