Dela via

Säkerhetskopiera och återställa i Azure Database for PostgreSQL – Flexibel server

  • Artikel

GÄLLER FÖR: Azure Database for PostgreSQL – flexibel server

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 – flexibel server utför automatiskt regelbundna säkerhetskopieringar av servern. Du kan sedan göra en återställning till tidpunkt (PITR) inom en kvarhållningsperiod 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 – flexibel server 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.

Dessa säkerhetskopieringsfiler kan inte exporteras eller användas för att skapa servrar utanför Azure Database for PostgreSQL – flexibel server. 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 ingen av databaserna på servern får ytterligare ändringar efter att den senaste säkerhetskopieringen av ögonblicksbilden har tagits, pausas säkerhetskopieringar av ögonblicksbilder tills nya ändringar görs i någon av databaserna, där en ny ögonblicksbild omedelbart tas. 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. I allmänhet kan fördröjningen (mål för återställningspunkt eller RPO) vara upp till 5 minuter.

Alternativ för säkerhetskopieringsredundans

Azure Database for PostgreSQL – flexibel server 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 – flexibel server 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äkerhetskopiorna lagras i zonredundant säkerhetskopieringslagring lagras flera kopior inte bara inom samma tillgänglighetszon, utan replikeras även till andra tillgänglighetszoner inom samma region.

    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 lagring av säkerhetskopiering: Det här alternativet väljs automatiskt för regioner som inte har stöd för tillgänglighetszoner ännu. 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 lagring av säkerhetskopiering: 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 – flexibel server tillhandahåller upp till 100 procent av din etablerade serverlagring som lagring av säkerhetskopior utan extra kostnad. Ytterligare 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 av 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.

Kommentar

Oavsett databasstorlek genererar tung transaktionsaktivitet på servern fler WAL-filer. Ökningen av filer ökar i sin tur lagringen av säkerhetskopior.

Återställning till tidpunkt

I Azure Database for PostgreSQL – flexibel server 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äkningsgenerering, antal virtuella kärnor, lagringsstorlek, kvarhållningsperiod för säkerhetskopiering och redundans för säkerhetskopiering. Taggar och inställningar som virtuella nätverk och brandväggsinställningar ärvs också från källservern.

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.

Information om hur du återställer databasservern finns i de här stegen.

Viktigt!

En återställningsåtgärd i Azure Database for PostgreSQL – flexibel server 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. Automatisk markering är användbart om du vill återställa till den senaste checkade 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 Azure Database for Azure Database for PostgreSQL – flexibel server för återställning. Använd Azure-resurslås för att förhindra oavsiktlig borttagning av servern.

Geo-redundant säkerhetskopiering och återställning

Information om hur du aktiverar geo-redundant säkerhetskopiering från fönstret Compute + Storage i Azure Portal finns i snabbstartsguiden.

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 timmes 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 beräknade tiden för att återställa servern (mål för återställningstid eller RTO) 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 omfattar de serverkonfigurationer som kan ändras virtuella nätverksinställningar och möjligheten att ta bort geo-redundant säkerhetskopiering från den återställda servern. Det går inte att ändra andra serverkonfigurationer , till exempel beräknings-, lagrings- eller prisnivå (Burstable, Generell användning eller Minnesoptimerad) under geo-återställning.

Mer information om hur du utför en geo-återställning finns i guiden instruktioner.

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 etablera geo-redundanta servrar i den geo-kopplade regionen måste du vänta tills den primära regionen är igång.

Med den primära regionen nere kan du fortfarande geo-återställa källservern till den geo-kopplade regionen. Mer information om hur du utför en geo-återställning finns i guiden instruktioner. Du bör använda Geo-repliker som din haveriberedskapsstrategi (DR) om du behöver konfigurera DR till valfri region, eller om den primära regionen inte stöder geo-redundanta säkerhetskopior

Återställa och nätverk

Återställning till 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 för 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. Befintliga brandväggsregler på källservern kopieras till den återställde servern. Privata slutpunkter tas inte över. När återställningen är klar kontrollerar du om du behöver justera någon av de brandväggsregler som överförs och skapa eventuella privata slutpunkter som du kan behöva.

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 geo-återställning över offentlig och privat åtkomst.

Post-restore tasks

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.

  • Se till att lämpliga brandväggar på servernivå, privata slutpunkter och regler för virtuella nätverk finns på plats för användaranslutningar. I det offentliga åtkomstnätverket kopieras regler från den ursprungliga servern, men de kanske inte är de som krävs i den återställde miljön. Justera dem enligt dina behov. Privata slutpunkter överförs inte. Skapa alla privata slutpunkter som du kan behöva på den återställde servern. I det virtuella nätverket för privat åtkomst kopieras inte återställningen över några artefakter i nätverksinfrastrukturen från källan till återställde servernätverk. Allt som rör konfiguration av VNET, undernät eller nätverkssäkerhetsgrupper måste hanteras som en uppgift efter återställningen.

  • 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 skrivskyddade repliker på den återställde servern, kan du följa dessa steg.

Långsiktig kvarhållning (förhandsversion)

Azure Backup och Azure Database for PostgreSQL – flexibla servertjä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 oberoende av varandra eller utöver den automatiserade säkerhetskopieringslösning som erbjuds av Azure Database for PostgreSQL – flexibel server, 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 som lagras i separata säkerhets- och feldomä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

  • 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å geo-repliker, men det kan utföras från primära servrar.
  • Den maximala databasstorleken som stöds för LTR-säkerhetskopiering är 4 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.

Mer information om hur du utför en långsiktig säkerhetskopiering finns i instruktioner.

Vanliga frågor och svar

  • Hur hanterar Azure säkerhetskopiering av min server?

    Som standard möjliggör Azure Database for PostgreSQL flexibel server 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 flexibel server maximalt 35 dagars kvarhållning. Du kan använda manuella säkerhetskopior för ett långsiktigt kvarhållningskrav.

  • Hur gör jag för att manuellt säkerhetskopiera mina flexibla Azure Database for PostgreSQL-serverinstanser?

    Du kan manuellt göra en säkerhetskopia med hjälp av PostgreSQL-verktyget pg_dump. Exempel finns i Migrera din flexibla Azure Database for PostgreSQL-serverdatabas med hjälp av dump och återställning.

    Om du vill säkerhetskopiera en flexibel Azure Database for PostgreSQL-server till Blob Storage kan du läsa Säkerhetskopiera Azure Database for PostgreSQL till Blob Storage på vår tech community-blogg.

  • 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 flexibla serverdata, säkerhetskopior och temporära filer i Azure Database for PostgreSQL som skapas under frågekörningen krypteras via AES 256-bitarskryptering. 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 extrahera tabeller eller databaser och importera dem till 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?

    Azure Database for PostgreSQL – flexibel server 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 geo-redundant säkerhetskopiering.

    Dessa säkerhetskopierade filer kan inte exporteras.

    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 Azure Database for PostgreSQL – flexibel server 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 debiteras och debiteras jag för mina säkerhetskopior?

    Azure Database for PostgreSQL – flexibel server 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.

  • Hur gör jag för att återställa servern?

    Azure Support s 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 – flexibel server 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.

Nästa steg