Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Säkerhetskopior utgör en viktig del av alla strategier för affärskontinuitet. De hjälper till att skydda data från oavsiktlig skada eller borttagning.
Azure Database for PostgreSQL utför automatiskt regelbundna säkerhetskopieringar av servern. Du kan sedan göra en återställning till en viss tidpunkt (PITR) inom en lagringsperiod som du anger. Den totala tiden för återställning beror vanligtvis på storleken på data och hur mycket återställning som ska utföras.
Översikt över Backup
Azure Database for PostgreSQL tar säkerhetskopior av ögonblicksbilder av datafiler och lagrar dem säkert i zonredundant lagring eller lokalt redundant lagring, beroende på region. Servern säkerhetskopierar även transaktionsloggar när wal-filen (write-ahead log) är redo att arkiveras. Du kan använda dessa säkerhetskopior för att återställa en server till valfri tidpunkt inom den konfigurerade kvarhållningsperioden för säkerhetskopior.
Standardperioden för kvarhållning av säkerhetskopior är 7 dagar, men du kan förlänga perioden till högst 35 dagar. Alla säkerhetskopior krypteras via AES 256-bitars kryptering för vilande data.
De här säkerhetskopieringsfilerna kan inte exporteras eller användas för att skapa servrar utanför din flexibla Azure Database for PostgreSQL-serverinstans. Därför kan du använda PostgreSQL-verktygen pg_dump och pg_restore/psql.
Säkerhetskopieringsfrekvens
Säkerhetskopior i Azure Database for PostgreSQL– flexibla serverinstanser är ögonblicksbildbaserade. Den första säkerhetskopieringen schemaläggs omedelbart efter att en server har skapats. Säkerhetskopior av ögonblicksbilder tas för närvarande en gång om dagen. Om inga ytterligare ändringar görs i några databaser på servern efter den senaste säkerhetskopieringen av ögonblicksbilden pausas säkerhetskopieringar tillfälligt. Så snart en databas på servern har ändrats tas en ny ögonblicksbild omedelbart för att samla in de senaste ändringarna. Den första ögonblicksbilden är en fullständig säkerhetskopia och på varandra följande ögonblicksbilder är differentiella säkerhetskopior.
Säkerhetskopior av transaktionsloggar tas med varierande frekvens beroende på arbetsbelastningen och när WAL-filen är full och redo att arkiveras. Generellt sett kan fördröjningen för RPO (recovery point objective) vara upp till 5 minuter.
Alternativ för säkerhetskopieringsredundans
Azure Database for PostgreSQL lagrar flera kopior av dina säkerhetskopior för att skydda dina data från planerade och oplanerade händelser. Dessa händelser kan omfatta tillfälliga maskinvarufel, nätverks- eller strömavbrott och naturkatastrofer. Säkerhetskopieringsredundans hjälper till att säkerställa att databasen uppfyller sina tillgänglighets- och hållbarhetsmål, även om fel inträffar.
Azure Database for PostgreSQL erbjuder tre alternativ:
- Zonredundant lagring av säkerhetskopiering: Det här alternativet väljs automatiskt för regioner som stöder tillgänglighetszoner. När säkerhetskopior lagras i zonredundant säkerhetskopieringslagring lagras tre kopior av data i tillgänglighetszonen där servern finns. Dessutom replikeras data till en annan tillgänglighetszon för extra skydd. - Det här alternativet ger tillgänglighet för säkerhetskopieringsdata mellan tillgänglighetszoner och begränsar replikering av data till inom ett land/en region för att uppfylla kraven på datahemvist. Det här alternativet ger minst 99,9999999999999 procent (12 nior) hållbarhet för säkerhetskopieringsobjekt under ett år. 
- Lokalt redundant säkerhetskopieringslagring: Det här alternativet väljs automatiskt för regioner som ännu inte har stöd för tillgänglighetszoner. När säkerhetskopiorna lagras i lokalt redundant säkerhetskopieringslagring lagras flera kopior av säkerhetskopior i samma datacenter. - Det här alternativet hjälper till att skydda dina data mot serverrack och enhetsfel. Det ger minst 99,999999999999 procent (11 nior) hållbarhet för säkerhetskopieringsobjekt under ett år. - Som standard är säkerhetskopieringslagring för servrar med hög tillgänglighet i samma zon (HA) eller ingen konfiguration med hög tillgänglighet inställd på lokalt redundant. 
- Geo-redundant säkerhetskopieringslagring: Du kan välja det här alternativet när servern skapas. När säkerhetskopiorna lagras i geo-redundant lagring av säkerhetskopior, utöver tre kopior av data som lagras i den region där servern finns, replikeras data till en geo-länkad region. - Med det här alternativet kan du återställa servern i en annan region i händelse av en katastrof. Det ger också minst 99,99999999999999999999 procent (16 nior) hållbarhet för säkerhetskopieringsobjekt under ett år. - Geo-redundans stöds för servrar som finns i någon av de Azure-kopplade regionerna. 
Flytta från andra lagringsalternativ för säkerhetskopiering till geo-redundant lagring av säkerhetskopior
Du kan konfigurera geo-redundant lagring för säkerhetskopiering endast när servern skapas. När en server har etablerats kan du inte ändra redundansalternativet för lagring av säkerhetskopior.
Kvarhållningsperiod för säkerhetskopior
Säkerhetskopior behålls baserat på den kvarhållningsperiod som du har angett för servern. Du kan välja en kvarhållningsperiod mellan 7 (standard) och 35 dagar. Du kan ange kvarhållningsperioden när servern skapas eller ändra den vid ett senare tillfälle. Säkerhetskopior behålls även för stoppade servrar.
Kvarhållningsperioden för säkerhetskopior styr den tidsram från vilken en PITR kan hämtas med hjälp av tillgängliga säkerhetskopior. Du kan också behandla kvarhållningsperioden för säkerhetskopior som ett återställningsfönster ur ett återställningsperspektiv.
Alla säkerhetskopior som krävs för att utföra en PITR inom kvarhållningsperioden för säkerhetskopior behålls i lagringen för säkerhetskopior. Om kvarhållningsperioden för säkerhetskopior till exempel har angetts till 7 dagar är återställningsfönstret de senaste 7 dagarna. I det här scenariot behålls alla data och loggar som krävs för att återställa servern under de senaste 7 dagarna.
Kostnad för lagring av säkerhetskopior
Azure Database for PostgreSQL tillhandahåller upp till 100 procent av din etablerade serverlagring som lagring av säkerhetskopior utan extra kostnad. All extra lagring av säkerhetskopior som du använder debiteras i gigabyte per månad.
Om du till exempel har etablerat en server med 250 gibibyte (GiB) lagringsutrymme har du 250 GiB-lagringskapacitet för säkerhetskopiering utan extra kostnad. Om den dagliga säkerhetskopieringsanvändningen är 25 GiB kan du ha upp till 10 dagars kostnadsfri säkerhetskopieringslagring. Lagringsförbrukning för säkerhetskopiering som överskrider 250 GiB debiteras enligt definitionen i prismodellen.
Om du konfigurerade servern med geo-redundant säkerhetskopiering kopieras även säkerhetskopieringsdata till den Azure-kopplade regionen. Storleken på säkerhetskopieringen blir därför dubbelt så stor som den lokala säkerhetskopian. Fakturering beräknas som ( (2 x lokal säkerhetskopieringsstorlek) – etablerad lagringsstorlek ) x pris @ gigabyte per månad.
Du kan använda måttet Backup Storage Used i Azure Portal för att övervaka lagringen av säkerhetskopior som en server använder. Måttet Backup Storage Used representerar summan av lagringen som förbrukas av alla kvarhållna databassäkerhetskopieringar och loggsäkerhetskopior, baserat på den kvarhållningsperiod för säkerhetskopiering som angetts för servern.
Anmärkning
Oavsett databasstorlek genererar tung transaktionsaktivitet på servern fler WAL-filer. Ökningen av filer ökar i sin tur lagringen av säkerhetskopior.
Återställning till specifik tidpunkt
I en flexibel Azure Database for PostgreSQL-serverinstans skapar en PITR en ny server i samma region som källservern, men du kan välja tillgänglighetszon. Den skapas med källserverns konfiguration för prisnivån, beräkningskraft, antal virtuella kärnor, lagringsstorlek, kvarhållningsperiod för säkerhetskopiering och säkerhetskopieringsredundans.
De fysiska databasfilerna återställs först från säkerhetskopieringar av ögonblicksbilder till serverns dataplats. Lämplig säkerhetskopia som togs tidigare än den önskade tidpunkten väljs och återställs automatiskt. En återställningsprocess startar sedan med hjälp av WAL-filer för att föra databasen till ett konsekvent tillstånd.
Anta till exempel att säkerhetskopiorna utförs kl. 23:00 varje natt. Om återställningspunkten gäller den 15 augusti kl. 10:00 återställs den dagliga säkerhetskopieringen den 14 augusti. Databasen återställs fram till 10:00 den 15 augusti med hjälp av säkerhetskopieringen av transaktionsloggen från 14 augusti 23:00 till 15 augusti kl. 10:00.
För att återställa din databasserver, se någon av följande:
- Återställ till senaste återställningspunkt.
- Återställ till anpassad återställningspunkt.
- Återställ till fullständig säkerhetskopia (snabb återställning).
- Återställ till parad region (geo-återställning).
Viktigt!
En återställningsåtgärd i din flexibla Azure Database for PostgreSQL-serverinstans skapar alltid en ny databasserver med det namn som du anger. Den skriver inte över den befintliga databasservern.
PITR är användbart i scenarier som dessa:
- En användare tar av misstag bort data, en tabell eller en databas.
- Ett program skriver av misstag över bra data med felaktiga data på grund av ett programfel.
- Du vill klona servern för test, utveckling eller för dataverifiering.
Med kontinuerlig säkerhetskopiering av transaktionsloggar kan du återställa till den senaste transaktionen. Du kan välja mellan följande återställningsalternativ:
- Senaste återställningspunkten (nu): Det här är standardalternativet, som gör att du kan återställa servern till den senaste tidpunkten. 
- Anpassad återställningspunkt: Med det här alternativet kan du välja valfri tidpunkt inom den kvarhållningsperiod som definierats för den här flexibla Azure Database for PostgreSQL-serverinstansen. Som standard väljs den senaste tiden i UTC automatiskt. Automatiskt val är användbart om du vill återställa till den senaste kommiterade transaktionen i testsyfte. Du kan också välja andra dagar och tider. 
- Snabb återställningspunkt: Med det här alternativet kan användarna återställa servern så snabbt som möjligt inom den kvarhållningsperiod som definierats för deras azure database for PostgreSQL– flexibel serverinstans. Snabbaste återställning är möjligt genom att välja tidsstämpeln direkt från listan över säkerhetskopior. Den här återställningsåtgärden etablerar en server och återställer helt enkelt den fullständiga säkerhetskopieringen av ögonblicksbilder och kräver ingen återställning av loggar, vilket gör den snabb. Vi rekommenderar att du väljer en tidsstämpel för säkerhetskopiering, vilket är större än den tidigaste återställningspunkten för en lyckad återställningsåtgärd. 
Den tid som krävs för att återställa med de senaste och anpassade återställningspunktsalternativen varierar beroende på faktorer som volymen av transaktionsloggar som ska bearbetas sedan den senaste säkerhetskopieringen och det totala antalet databaser som återställs samtidigt i samma region Den totala återställningstiden tar vanligtvis från några minuter upp till några timmar.
Om du konfigurerar servern i ett virtuellt nätverk kan du återställa till samma virtuella nätverk eller till ett annat virtuellt nätverk. Du kan dock inte återställa till offentlig åtkomst. På samma sätt kan du inte återställa till privat virtuell nätverksåtkomst om du har konfigurerat servern med offentlig åtkomst.
Viktigt!
Borttagna servrar kan återställas. Om du tar bort servern kan du följa vår vägledning Återställa en borttagen flexibel Azure Database for Azure Database for PostgreSQL-server för återställning. Använd Azure-resurslås för att förhindra oavsiktlig borttagning av servern.
Geografiskt redundant säkerhetskopiering och återställning
Information om hur du aktiverar geo-redundant säkerhetskopiering från fönstret Compute + Storage i Azure-portalen finns i Skapa en Azure Database for PostgreSQL.
Viktigt!
Geo-redundant säkerhetskopiering kan endast konfigureras när servern skapas.
När du har konfigurerat servern med geo-redundant säkerhetskopiering kan du återställa den till en geo-länkad region. Mer information finns i de regioner som stöds för geo-redundant säkerhetskopiering.
När servern har konfigurerats med geo-redundant säkerhetskopiering kopieras säkerhetskopieringsdata och transaktionsloggar till den kopplade regionen asynkront via lagringsreplikering. När du har skapat en server väntar du minst en timme innan du påbörjar en geo-återställning. Det gör att den första uppsättningen säkerhetskopierade data kan replikeras till den kopplade regionen.
Senare kopieras transaktionsloggarna och de dagliga säkerhetskopiorna asynkront till den kopplade regionen. Det kan finnas upp till en timmes fördröjning i dataöverföringen. Därför kan du förvänta dig upp till en timme med RPO när du återställer. Du kan bara återställa till de senast tillgängliga säkerhetskopieringsdata som är tillgängliga i den kopplade regionen. PITR för geo-redundanta säkerhetskopior är för närvarande inte tillgängligt.
Den uppskattade tiden för att återställa serverns RTO (mål för återställningstid) beror på faktorer som databasens storlek, den senaste säkerhetskopieringstiden för databasen och mängden WAL som ska bearbetas fram till den senaste mottagna säkerhetskopieringsdata. Den totala återställningstiden tar vanligtvis några minuter upp till några timmar.
Under geo-återställningen är de serverkonfigurationer som kan ändras bland annat virtuella nätverksinställningar och möjligheten att ta bort geo-redundanta säkerhetskopior från den återställda servern. Det stöds inte att ändra andra serverkonfigurationer, såsom beräkningskapacitet, lagringsutrymme eller prisnivå (Burstable, Generell användning eller Minnesoptimerad) under geo-återställning.
För mer information, se Återställ till parregion (geografisk återställning).
Viktigt!
När den primära regionen är nere kan du inte skapa geo-redundanta servrar i respektive geo-kopplade region, eftersom lagring inte kan etableras i den primära regionen. Innan du kan tillhandahålla geografisk redundanta servrar i den geosammanlänkade regionen måste du vänta tills den primära regionen är igång.
Med den primära regionen otillgänglig kan du fortfarande återställa källservern till den geo-kopplade regionen. För mer information, se Återställ till parregion (geografisk återställning). Du bör använda geo-replikor som din krisåterställningsstrategi (DR) om du behöver konfigurera DR till någon region, eller om den primära regionen inte har stöd för geo-redundant backup.
Vi rekommenderar att du använder virtuella slutpunkter för dina verksamhetskritiska arbetsbelastningar, eftersom det ger en stabil anslutningspunkt för program, vilket säkerställer minimala störningar. Om du har en virtuell slutpunkt mappad till den primära servern tar du bort den virtuella slutpunkten från den primära servern och lägger till samma virtuella slutpunkt på den nyligen skapade servern när den har tagits bort. Detta säkerställer att programanslutningen förblir konsekvent och minimerar stilleståndstiden. Mer information finns i använda virtuella slutpunkter för konsekvent värdnamn under PITR
Återställ och nätverksinställningar
Återställning till specifik tidpunkt
Om källservern har konfigurerats med ett offentligt åtkomstnätverk kan du bara återställa till offentlig åtkomst.
Om källservern har konfigurerats med ett virtuellt nätverk för privat åtkomst kan du antingen återställa till samma virtuella nätverk eller till ett annat virtuellt nätverk. Du kan inte utföra PITR över både offentlig och privat åtkomst.
Geo-återställning
Om källservern har konfigurerats med ett offentligt åtkomstnätverk kan du bara återställa till offentlig åtkomst. Du måste också tillämpa brandväggsregler när återställningen har slutförts.
Om källservern har konfigurerats med ett virtuellt nätverk för privat åtkomst kan du bara återställa till ett annat virtuellt nätverk eftersom virtuella nätverk inte kan sträcka sig över regioner. Du kan inte utföra geografisk återställning genom både offentlig och privat åtkomst.
Uppgifter efter återställning
När du har återställt servern kan du utföra följande uppgifter för att få igång dina användare och program igen:
- Om den nya servern är avsedd att ersätta den ursprungliga servern omdirigerar du klienter och klientprogram till den nya servern. Ändra servernamnet för anslutningssträng så att det pekar på den nya servern. 
- Värdena för alla serverparametrar på den ursprungliga servern tillämpas inte automatiskt på den nya servern. Kontrollera att alla serverparametrar på den nya servern har konfigurerats om enligt kraven för den nya servern. 
- Se till att lämpliga brandväggsregler på servernivå, privata slutpunkter och regler för virtuella nätverk finns för användaranslutningar. Dessa regler kopieras inte från den ursprungliga servern. 
- Skala upp eller skala ned den återställde serverns beräkning efter behov. 
- Se till att lämpliga inloggningar och behörigheter på databasnivå finns på plats. 
- Konfigurera aviseringar efter behov. 
- Om källservern som du återställde har konfigurerats med hög tillgänglighet och du vill konfigurera den återställde servern med hög tillgänglighet kan du följa dessa steg. 
- Om källservern som du återställde har konfigurerats med läsrepliker och du vill konfigurera läsrepliker på den återställde servern, kan du följa anvisningarna i Skapa en läsreplik. 
Säkerhetskopiering på begäran
Din flexibla Azure Database for PostgreSQL-serverinstans genererar automatiskt ögonblicksbilder av lagringsvolymer av hela databasinstansen, som täcker alla databaser, som en del av de schemalagda säkerhetskopiorna. Dessutom kan du skapa en säkerhetskopiering på begäran när det behövs, vilket är idealiskt för scenarier som att förbereda för en potentiellt riskfylld åtgärd eller utföra periodiska uppdateringar utanför det vanliga säkerhetskopieringsschemat.
Säkerhetskopieringar på begäran kan göras utöver schemalagda automatiska säkerhetskopieringar. Dessa säkerhetskopior behålls enligt kvarhållningsfönstret för säkerhetskopior. Du kan ta bort dessa säkerhetskopieringar på begäran när som helst om de inte längre behövs. Om du vill initiera en säkerhetskopiering på begäran väljer du den databasinstans som du vill säkerhetskopiera och anger ett säkerhetskopieringsnamn. Dessa säkerhetskopior lagras tillsammans med automatiserade säkerhetskopior, men endast säkerhetskopieringar på begäran kan tas bort av användarna, eftersom automatiserade säkerhetskopieringar hanteras och behålls av tjänsten för att uppfylla kraven på kvarhållning av säkerhetskopior.
Mer information finns i Utföra säkerhetskopieringar på begäran.
Begränsningar
- Funktionen för säkerhetskopiering på begäran stöds för närvarande inte med beräkningsnivå för "Burstable server".
- Säkerhetskopieringsfunktionen på begäran stöds för närvarande inte med lagringsnivån SSDv2.
- Du kan ta högst 7 säkerhetskopieringar på begäran per flexibel serverinstans, som behålls baserat på fönstret för kvarhållning av säkerhetskopior.
Långsiktig kvarhållning
Azure Backup och Azure Database for PostgreSQL-tjänster har skapat en långsiktig säkerhetskopieringslösning i företagsklass för Azure Database for PostgreSQL- flexibla serverinstanser som behåller säkerhetskopior i upp till 10 år. Du kan använda långsiktig kvarhållning (LTR) oberoende eller utöver den automatiserade säkerhetskopieringslösning som erbjuds av Azure Database for PostgreSQL, som erbjuder kvarhållning på upp till 35 dagar. Automatiserade säkerhetskopieringar är fysiska säkerhetskopior som lämpar sig för driftåterställning, särskilt när du vill återställa från de senaste säkerhetskopiorna. Långsiktiga säkerhetskopior hjälper dig med dina efterlevnadsbehov, är mer detaljerade och används som logiska säkerhetskopior med hjälp av inbyggda pg_dump. Utöver långsiktig kvarhållning erbjuder lösningen följande funktioner:
- Kundstyrda schemalagda och on-demand säkerhetskopior på enskild databasnivå.
- Central övervakning av alla åtgärder och jobb.
- Säkerhetskopior lagras i separata säkerhets- och feltoleransdomäner. Om källservern eller prenumerationen äventyras förblir säkerhetskopiorna säkra i säkerhetskopieringsvalvet (i Azure Backup-hanterade lagringskonton).
- Med hjälp av pg_dump ger du större flexibilitet när det gäller att återställa data i olika databasversioner.
- Azures säkerhetskopieringsvalv stöder funktioner för oföränderlighet och mjuk radering (förhandsgranskning), vilket skyddar dina data.ata.
- Stöd för LTR-säkerhetskopiering för CMK-aktiverade servrar.
Begränsningar och överväganden
- Vi rekommenderar starkt att du testar din LTR-säkerhetskopiering och återställning omedelbart efter konfigurationen för att säkerställa att de uppfyller dina affärskrav.
- LTR-återställningar är för närvarande endast tillgängliga som "Återställ som filer" för lagringskonton, med funktionen "Återställ som server" planerad för framtiden.
- LTR säkerhetskopierar alla databaser i flexibla serverinstanser och enskilda databaser kan inte väljas för LTR-konfiguration.
- LTR-säkerhetskopiering stöds inte på repliker, det kan utföras på primära servrar.
- Den maximala databasstorleken som stöds för LTR-säkerhetskopior (Long-Term Retention) är 1 TiB.
- LTR-säkerhetskopior kan schemaläggas varje vecka, varje månad eller varje år. Schemat för daglig säkerhetskopiering stöds för närvarande inte.
- LTR-säkerhetskopior stöder inte tabeller som innehåller en rad med en BYTEA-längd som överstiger 500 MB.
- När du återställer roller för Microsoft Entra-användare kontrollerar du att Microsoft Entra-autentisering är aktiverat och att du är inloggad som Microsoft Entra-administratör för att skapa ytterligare användare. Försök att skapa Entra-roller som en vanlig användare resulterar i fel.
Mer information om hur du utför en långsiktig säkerhetskopiering finns i instruktioner.
Vanliga frågor och svar
Säkerhetskopieringsrelaterade frågor
- Hur hanterar Azure säkerhetskopiering av min server? - Som standard möjliggör Azure Database for PostgreSQL automatiserade säkerhetskopieringar av hela servern (som omfattar alla databaser som skapats) med en standardkvarhållningsperiod på 7 dagar. De automatiserade säkerhetskopiorna innehåller en daglig inkrementell ögonblicksbild av databasen. Loggfilerna (WAL) arkiveras kontinuerligt till Azure Blob Storage. 
- Kan jag konfigurera automatiserade säkerhetskopieringar för att behålla data på lång sikt? - Nej. För närvarande stöder Azure Database for PostgreSQL maximalt 35 dagars kvarhållning. Du kan använda manuella säkerhetskopior för ett långsiktigt kvarhållningskrav med hjälp av Azure Backup. 
- Hur gör jag för att manuellt säkerhetskopiera mina flexibla Azure Database for PostgreSQL-serverinstanser? - Du kan ta en fysisk ögonblicksbild manuellt med hjälp av säkerhetskopieringsfunktionen på begäran. Du kan också göra logiska säkerhetskopior med hjälp av PostgreSQL-verktyget pg_dump. Exempel finns i Migrera din Azure Database for PostgreSQL-databas med hjälp av dump och återställning. 
- Vilka är säkerhetskopieringsfönstren för min server? Kan jag anpassa dem? - Azure hanterar säkerhetskopieringsfönster och du kan inte anpassa dem. Den första fullständiga säkerhetskopieringen schemaläggs omedelbart efter att en server har skapats. Efterföljande säkerhetskopieringar av ögonblicksbilder är inkrementella och sker en gång om dagen. 
- Är mina säkerhetskopior krypterade? - Ja. Alla data, säkerhetskopieringar och temporära filer i Azure Database for PostgreSQL för flexibel serverinstans som skapas under frågekörning krypteras via 256-bitars kryptering med AES (Advanced Encryption Standard). Lagringskrypteringen är alltid igång och kan inte inaktiveras. 
- Kan jag återställa en enskild databas eller några databaser på en server? - Det går inte att återställa en enskild databas eller några databaser eller tabeller direkt. Du kan dock återställa hela servern till en ny server och sedan ta bort tabeller eller databaser som du inte behöver på den nya servern. 
- Är min server tillgänglig när en säkerhetskopia pågår? - Ja. Säkerhetskopieringar är onlineåtgärder som använder ögonblicksbilder. Ögonblicksbildsåtgärden tar bara några sekunder och stör inte produktionsarbetsbelastningar för att säkerställa hög tillgänglighet för servern. 
- Behöver jag ta hänsyn till säkerhetskopieringsfönstret när jag konfigurerar underhållsperioden för servern? - Nej. Säkerhetskopior utlöses internt som en del av den hanterade tjänsten och har ingen betydelse för underhållsfönstret. 
- Var lagras mina automatiserade säkerhetskopior och hur hanterar jag deras kvarhållning? - Din flexibla Azure Database for PostgreSQL-serverinstans skapar automatiskt serversäkerhetskopior och lagrar dem i: - Zonredundant lagring i regioner där flera zoner stöds.
- Lokalt redundant lagring i regioner som inte har stöd för flera zoner än.
- Den kopplade regionen, om du konfigurerar den geo-redundanta säkerhetskopieringen.
 - Dessa säkerhetskopieringsfiler kan inte exporteras eftersom de lagras i Microsoft-hanterade lagringskonton. Kunder har skrivskyddad åtkomst för att återställa dessa filer men kan inte ändra eller ta bort dem. Säkerhetskopieringsfilerna tas bort automatiskt efter kvarhållningsperioden - Du kan använda säkerhetskopior för att återställa servern till en viss tidpunkt. Kvarhållningsperioden är som standard inställd på 7 dagar för säkerhetskopior. Du kan också konfigurera kvarhållning av säkerhetskopior upp till 35 dagar. 
- Hur ofta kopieras säkerhetskopian till den kopplade regionen med geo-redundant säkerhetskopiering? - När servern har konfigurerats med geo-redundant säkerhetskopiering lagras säkerhetskopieringsdata i ett geo-redundant lagringskonto. Lagringskontot kopierar datafiler till den kopplade regionen när den dagliga säkerhetskopieringen sker på den primära servern. WAL-filer säkerhetskopieras när de är redo att arkiveras. - Säkerhetskopieringsdata kopieras asynkront på ett kontinuerligt sätt till den kopplade regionen. Du kan förvänta dig upp till en timmes fördröjning när du tar emot säkerhetskopierade data. 
- Kan jag göra PITR i fjärrregionen? - Nej. Data återställs till de senast tillgängliga säkerhetskopieringsdata i fjärrregionen. 
- Hur utförs säkerhetskopior på en HA-aktiverad server? - Datavolymer i en flexibel Azure Database for PostgreSQL-serverinstans säkerhetskopieras via inkrementella ögonblicksbilder av hanterade diskar från den primära servern. WAL-säkerhetskopieringen utförs från antingen den primära servern eller väntelägesservern. 
- Hur kan jag verifiera att säkerhetskopior utförs på min server? - Det bästa sättet att kontrollera säkerhetskopior är att utföra periodisk PITR och se till att säkerhetskopior är giltiga och återställningsbara. Säkerhetskopieringen och filerna exponeras inte för slutanvändaren. 
- Var kan jag se användningen av säkerhetskopiering? - I Azure Portal går du till Övervakning och väljer Mått. I Säkerhetskopieringslagring som används kan du övervaka den totala användningen av säkerhetskopiering. 
- Vad händer med mina säkerhetskopior om jag tar bort min server? - Om du tar bort en server tas även alla säkerhetskopior som tillhör servern bort och kan inte återställas. Administratörer kan använda hanteringslås för att skydda serverresurser från oavsiktlig borttagning eller oväntade ändringar efter distributionen. 
- Hur behålls säkerhetskopior för stoppade servrar? - Inga nya säkerhetskopior utförs för stoppade servrar. Alla äldre säkerhetskopior (inom kvarhållningsfönstret) vid tidpunkten för att stoppa servern behålls tills servern startas om. Därefter styrs kvarhållning av säkerhetskopior för den aktiva servern av dess kvarhållningsfönster. 
- Hur faktureras jag för mina säkerhetskopior? - Azure Database for PostgreSQL tillhandahåller upp till 100 procent av din etablerade serverlagring som lagring av säkerhetskopior utan extra kostnad. Allt mer lagringsutrymme för säkerhetskopiering som du använder debiteras i gigabyte per månad, enligt definitionen i prismodellen. - Alternativet för kvarhållningsperiod för säkerhetskopiering och redundans för säkerhetskopiering som du väljer, tillsammans med transaktionsaktiviteten på servern, påverkar direkt den totala lagringen och faktureringen av säkerhetskopior. 
- Hur debiteras jag för en stoppad server? - När serverinstansen har stoppats utförs inga nya säkerhetskopior. Du debiteras för etablerad lagring och lagring av säkerhetskopior (säkerhetskopior som lagras i det angivna kvarhållningsfönstret). - Lagringsutrymme för kostnadsfri säkerhetskopiering är begränsat till storleken på din etablerade databas. Eventuella överskott av säkerhetskopieringsdata debiteras enligt säkerhetskopieringspriset. 
- Jag har konfigurerat min server med zonredundant hög tillgänglighet. Tar du två säkerhetskopior och debiteras jag två gånger? - Nej. Oavsett HA- eller icke-HA-servrar bevaras endast en uppsättning säkerhetskopior. Du debiteras bara en gång. 
Återställningsrelaterade frågor
- Hur gör jag för att återställa servern? - Azure stöder PITR för alla servrar. Användare kan återställa till den senaste återställningspunkten eller en anpassad återställningspunkt med hjälp av Azure Portal, Azure CLI och API:et. - Om du vill återställa servern från manuella säkerhetskopior med hjälp av verktyg som pg_dump kan du först skapa en flexibel Azure Database for PostgreSQL-serverinstans och sedan återställa databaserna till servern med hjälp av pg_restore. 
- Kan jag återställa till en annan tillgänglighetszon inom samma region? - Ja. Om regionen stöder flera tillgänglighetszoner lagras säkerhetskopian på ett zonredundant lagringskonto så att du kan återställa till en annan zon. 
- Hur lång tid tar en PITR? Varför tar återställningen så lång tid? - Dataåterställningsåtgärden från en ögonblicksbild beror inte på storleken på data. Tidpunkten för återställningsprocessen som tillämpar loggarna (transaktionsaktiviteter att spela upp) kan dock variera beroende på den tidigare säkerhetskopieringen av det begärda datumet/tiden och antalet loggar som ska bearbetas. Detta gäller både återställning inom samma zon eller återställning av data till en annan zon. 
- Konfigureras återställningsservern automatiskt med hög tillgänglighet om jag återställer min HA-aktiverade server? - Nej. Servern återställs som en Azure Database for PostgreSQL-instans med en enda instans. När återställningen är klar kan du konfigurera servern med hög tillgänglighet. 
- Jag har konfigurerat min server i ett virtuellt nätverk. Kan jag återställa till ett annat virtuellt nätverk? - Ja. Vid tidpunkten för återställningen väljer du ett annat virtuellt nätverk att återställa till. 
- Kan jag återställa min offentliga åtkomstserver till ett virtuellt nätverk eller tvärtom? - Nej. Azure Database for PostgreSQL stöder för närvarande inte återställning av servrar över offentlig och privat åtkomst. 
- Hur gör jag för att spåra min återställningsåtgärd? - För närvarande finns det inget sätt att spåra återställningsåtgärden. Du kan övervaka aktivitetsloggen för att se om åtgärden pågår eller är klar.