Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Backup di Azure ti permette di proteggere server flessibili e cluster elastici di Azure PostgreSQL con backup fisici (snapshot su disco). Questo articolo riassume le regioni, gli scenari, le configurazioni e i limiti supportati dell'esperienza v2.
Regioni supportate per Azure PostgreSQL server flessibile e backup vaulted elastic cluster (v2)
I backup vaulted sono disponibili in tutte le regioni pubbliche tranne Austria Est, Belgio Centrale, Cile Centrale, Indonesia Centrale, Israele Nord-Ovest, Malesia Sud, Malesia Ovest, Messico Centrale, Qatar Centrale, Sud Centrale US 2, Sud-Est degli Stati Uniti, Sud-Est US 3, Sud-Est US 5, Sud-Ovest degli Stati Uniti e India Occidentale.
Fonti dati e configurazioni supportate per Azure PostgreSQL flexible server e elastic cluster vaulted backup (v2)
La tabella seguente elenca le sorgenti dati e le configurazioni supportate per Azure PostgreSQL server flessibile e backup vaulted elastic cluster (v2):
| Item | Support |
|---|---|
| Server flessibile di Azure Database per PostgreSQL | Supportato |
| Database di Azure per PostgreSQL elastic cluster | Supportato |
| Versione maggiore di PostgreSQL | PostgreSQL 15 e successivi |
| Livello di calcolo | Uso generale e ottimizzazione della memoria |
| Tipo di disco e dimensione massima | SSD premium v1 fino a 32 TB; SSD premium v2 fino a 64 TB |
| Ruolo del server | Solo server primari |
| Chiave gestita dal cliente sul server o sul cluster | Supportato |
| Alta disponibilità abilitata sul server sorgente | Supportato |
| Rete virtuale o endpoint privato sul server sorgente o cluster | Supportato tramite Trusted Access |
| Posizione del vault di backup | Deve trovarsi nella stessa regione della sorgente dati |
| Abbonamento al vault di backup | Stesso abbonamento o diverso, all'interno dello stesso tenant della sorgente dati |
| Vault di backup con crittografia della chiave gestita dal cliente | Supportato |
| Immutabilità del vault di backup (WORM) | Supportato. I punti di recupero possono essere resi immutabili in modo da non poter essere alterati o cancellati prima della loro scadenza. |
| Cancellazione soft, autorizzazione multiutente e autenticazione multifattore sul vault | Supportato |
| Identità gestita assegnata dall'utente | Supportato per concedere permessi sulla sorgente dati e sul vault di backup |
Scenari di backup supportati per Azure PostgreSQL server flessibile e backup vaulted elastic cluster (v2)
Azure PostgreSQL server flexible e backup vaulted cluster elastic (v2) supportano i seguenti scenari di backup:
- L'intero server o cluster viene salvato in backup. Il backup di singoli database non è supportato.
- È supportato un cluster elastico fino a 8 nodi.
- Il primo backup di una sorgente dati è un backup completo; ogni backup successivo è incrementale. Backup di Azure esegue nuovamente automaticamente una replica iniziale se la catena di snapshot viene interrotta.
- Sono supportati programmi di backup giornalieri o settimanali, con un obiettivo minimo di punti di recupero di un giorno.
- La ritenzione può essere impostata da 7 giorni fino a 10 anni, con durate indipendenti per i punti di recupero giornalieri, settimanali, mensili e annuali.
- I backup on-demand (ad hoc) sono supportati dopo la configurazione della protezione.
- Un'istanza di backup è supportata per ogni fonte dati. La protezione multipla dello stesso server non è supportata, quindi un server è protetto o dallo stack v1 o dallo stack v2, mai da entrambi.
- La policy di backup associata a un'istanza di backup può essere modificata dopo la configurazione della protezione.
- Un lavoro di backup viene contrassegnato come Riuscito una volta che lo snapshot del disco gestito è stato copiato nel vault.
- I metadati dei punti di recupero, inclusa la versione PostgreSQL su cui è stato effettuato il backup, sono visibili su ogni punto di recupero.
- Sono supportati i backup immutabili di WORM. Quando l'immutabilità è abilitata e bloccata sul vault di backup, i punti di recupero non possono essere alterati, sovrascritti o cancellati prima che scada il loro periodo di conservazione configurato, da qualsiasi utente, incluso l'amministratore del vault.
Scenari di ripristino supportati per Azure PostgreSQL flexible server e elastic cluster vaulted backup (v2)
Azure PostgreSQL server flexible e backup vaulted cluster elastic (v2) supportano i seguenti scenari di ripristino:
- I ripristini vengono eseguiti come Ripristino come Server in una posizione alternativa. Il server flessibile target o il cluster elastico deve essere creato prima che venga attivato il ripristino.
- I dati nelle tabelle non logate non vengono conservati e si perdono al ripristino.
- L'obiettivo può essere in un abbonamento diverso all'interno dello stesso tenant.
- Il ripristino tra le regioni è supportato.
- Le operazioni di ripristino da backup effettuati su versioni PostgreSQL non più supportate non sono garantite.
- Il ripristino è supportato anche dopo che la fonte di origine è stata eliminata.
- Un lavoro di ripristino viene segnalato come Riuscito solo quando l'intero punto di recupero è stato ripristinato.
- Un punto di recupero preso su un server SSD Premium v1 viene ripristinato su un target SSD Premium v1. Un punto di recupero preso su un server SSD Premium v2 viene ripristinato su un target SSD Premium v2.
Requisiti target per il ripristino
Il server flessibile target o il cluster elastico deve soddisfare tutti i seguenti criteri, che Backup di Azure convalida prima dell'inizio dell'operazione di ripristino:
- Il server o il cluster deve essere vuoto.
- Il server o il cluster non devono trovarsi nel livello di calcolo di Burstable.
- Il server o cluster di destinazione deve utilizzare la stessa versione maggiore di PostgreSQL del server sorgente al momento del backup. Il ripristino fallisce se le versioni non corrispondono.
- Il server o cluster target deve avere la stessa dimensione del disco del server sorgente. Il ripristino fallisce se la dimensione del disco target è inferiore a quella sorgente, anche se il punto di recupero richiede meno spazio sul disco di destinazione.
- Il server o il cluster non devono avere alta disponibilità configurata.
- Il server o il cluster non deve avere una geo-replica configurata, e non deve essere esso stesso una geo-replica.
- Il server o il cluster deve trovarsi nella stessa regione del vault di backup.
Limitazioni per Azure PostgreSQL flexible server e elastic cluster vaulted backup (v2)
L'esperienza v2 presenta le seguenti limitazioni:
- Il backup e il ripristino a livello di oggetto non sono supportati. Non puoi fare il backup o ripristinare un singolo database, tabella o oggetto.
- Il livello di calcolo Burstable non è supportato. Configurare il backup su un server Burstable fallisce a causa di un errore utente. Scala il server prima su General Purpose o Ottimizzato per la Memoria.
- PostgreSQL 14 e versioni precedenti non sono supportate. La configurazione di backup fallisce per i server che utilizzano queste versioni. Devi aggiornare a una versione maggiore supportata prima di configurare il backup, oppure continuare a proteggere il server con la v1.
- Il backup è supportato solo per i server primari. Non puoi configurare il backup per repliche di lettura o geo-replica. Se provi a configurare il backup di una replica, l'operazione fallisce con un errore utente.
- L'obiettivo del punto di recupero di un giorno (RPO) non è garantito in tutti gli scenari. Il backup iniziale e la successiva replica iniziale trasferiscono l'intero contenuto del disco e possono richiedere più di un giorno per server e cluster di grandi dimensioni. I backup possono anche superare un giorno per server con elevati turni giornalieri di dati o server che utilizzano SSD Premium v2.
- Spostare un oggetto protetto dalla v1 alla v2 è un modo. Per tornare alla v1, ferma la protezione e riconfigura il backup sullo stack v1.
- La configurazione di backup non si applica automaticamente al nuovo server primario dopo un geo-failover pianificato. La configurazione di backup esistente rimane associata al server primario precedente e i suoi backup iniziano a fallire dopo il failover. Per proteggere il nuovo server primario, configura il backup su quel server.