Delen via

Back-up en herstel in Azure Database for PostgreSQL - flexibele server

  • Artikel

VAN TOEPASSING OP: Azure Database for PostgreSQL - Flexibele server

Back-ups vormen een essentieel onderdeel van elke strategie voor bedrijfscontinuïteit. Ze helpen gegevens te beschermen tegen onbedoelde beschadiging of verwijdering.

Azure Database for PostgreSQL Flexibele server voert automatisch regelmatige back-ups van uw server uit. U kunt vervolgens een herstel naar een bepaald tijdstip (PITR) uitvoeren binnen een retentieperiode die u opgeeft. De totale tijd die nodig is om te herstellen en te herstellen, is doorgaans afhankelijk van de grootte van de gegevens en de hoeveelheid herstel die moet worden uitgevoerd.

Overzicht van Backup

Flexibele Azure Database for PostgreSQL-server maakt momentopnameback-ups van gegevensbestanden en slaat deze veilig op in zone-redundante opslag of lokaal redundante opslag, afhankelijk van de regio. De server maakt ook een back-up van transactielogboeken wanneer het WAL-bestand (Write-Ahead Log) gereed is om te worden gearchiveerd. U kunt deze back-ups gebruiken om een server te herstellen naar een bepaald tijdstip binnen de geconfigureerde bewaarperiode voor back-ups.

De standaardretentieperiode voor back-ups is 7 dagen, maar u kunt de periode verlengen tot maximaal 35 dagen. Alle back-ups worden versleuteld via AES 256-bits versleuteling voor gegevens die in rust zijn opgeslagen.

Deze back-upbestanden kunnen niet worden geëxporteerd of gebruikt voor het maken van servers buiten Azure Database for PostgreSQL flexibele server. Hiervoor kunt u de PostgreSQL-hulpprogramma's pg_dump en pg_restore/psql gebruiken.

Back-upfrequentie

Back-ups op flexibele azure Database for PostgreSQL-serverexemplaren zijn gebaseerd op momentopnamen. De eerste momentopnameback-up wordt gepland direct nadat een server is gemaakt. Back-ups van momentopnamen worden momenteel eenmaal per dag gemaakt. Als geen van de databases op de server verdere wijzigingen ontvangt nadat de laatste momentopnameback-up is gemaakt, worden momentopnameback-ups onderbroken totdat er nieuwe wijzigingen worden aangebracht in een van de databases, zodat er onmiddellijk een nieuwe momentopname wordt gemaakt. De eerste momentopname is een volledige back-up en opeenvolgende momentopnamen zijn differentiële back-ups.

Back-ups van transactielogboeken vinden plaats met verschillende frequenties, afhankelijk van de workload en wanneer het WAL-bestand wordt gevuld en gereed is om te worden gearchiveerd. Over het algemeen kan de vertraging (herstelpuntdoelstelling of RPO) maximaal 5 minuten duren.

Redundantieopties voor back-up

Azure Database for PostgreSQL Flexibele server slaat meerdere kopieën van uw back-ups op om uw gegevens te beschermen tegen geplande en ongeplande gebeurtenissen. Deze gebeurtenissen kunnen tijdelijke hardwarefouten, netwerk- of stroomstoringen en natuurrampen omvatten. Back-upredundantie zorgt ervoor dat uw database voldoet aan de beschikbaarheids- en duurzaamheidsdoelen, zelfs als er fouten optreden.

Flexibele Azure Database for PostgreSQL-server biedt drie opties:

  • Zone-redundante back-upopslag: deze optie wordt automatisch gekozen voor regio's die beschikbaarheidszones ondersteunen. Wanneer de back-ups worden opgeslagen in zone-redundante back-upopslag, worden meerdere kopieën niet alleen opgeslagen in dezelfde beschikbaarheidszone, maar ook gerepliceerd naar andere beschikbaarheidszones binnen dezelfde regio.

    Deze optie biedt beschikbaarheid van back-upgegevens in beschikbaarheidszones en beperkt de replicatie van gegevens naar binnen een land/regio om te voldoen aan de vereisten voor gegevenslocatie. Deze optie biedt ten minste 99,999999999999 procent (12 negens) duurzaamheid van back-upobjecten gedurende een jaar.

  • Lokaal redundante back-upopslag: deze optie wordt automatisch gekozen voor regio's die nog geen beschikbaarheidszones ondersteunen. Wanneer de back-ups worden opgeslagen in lokaal redundante back-upopslag, worden meerdere kopieën van back-ups opgeslagen in hetzelfde datacenter.

    Met deze optie kunt u uw gegevens beschermen tegen serverrack- en stationsfouten. Het biedt ten minste 99,999999999999 procent (negens) duurzaamheid van back-upobjecten gedurende een jaar.

    Standaard is back-upopslag voor servers met hoge beschikbaarheid in dezelfde zone of geen configuratie met hoge beschikbaarheid ingesteld op lokaal redundant.

  • Geografisch redundante back-upopslag: u kunt deze optie kiezen op het moment dat de server is gemaakt. Wanneer de back-ups worden opgeslagen in geografisch redundante back-upopslag, worden naast drie kopieën van gegevens die zijn opgeslagen in de regio waar uw server wordt gehost, de gegevens gerepliceerd naar een geografisch gekoppelde regio.

    Met deze optie kunt u uw server in een andere regio herstellen in het geval van een noodgeval. Het biedt ook ten minste 99,9999999999999999 procent (16 negens) duurzaamheid van back-upobjecten gedurende een jaar.

    Georedundantie wordt ondersteund voor servers die worden gehost in een van de gekoppelde Azure-regio's.

Overstappen van andere opties voor back-upopslag naar geografisch redundante back-upopslag

U kunt geografisch redundante opslag alleen configureren voor back-ups tijdens het maken van de server. Nadat een server is ingericht, kunt u de optie voor redundantie van back-upopslag niet wijzigen.

Back-upretentie

Back-ups worden bewaard op basis van de bewaarperiode die u voor de server hebt ingesteld. U kunt een bewaarperiode tussen 7 (standaard) en 35 dagen selecteren. U kunt de bewaarperiode instellen tijdens het maken van de server of deze op een later tijdstip wijzigen. Back-ups worden bewaard, zelfs voor gestopte servers.

De bewaarperiode voor back-ups bepaalt het tijdsbestek waaruit een PITR kan worden opgehaald met behulp van de beschikbare back-ups. U kunt de bewaarperiode voor back-ups ook behandelen als een herstelvenster vanuit het perspectief van herstel.

Alle back-ups die nodig zijn om een PITR uit te voeren binnen de bewaarperiode voor back-ups, worden bewaard in de back-upopslag. Als de bewaarperiode voor back-ups bijvoorbeeld is ingesteld op 7 dagen, is het herstelvenster de afgelopen 7 dagen. In dit scenario worden alle gegevens en logboeken die nodig zijn om de server in de afgelopen 7 dagen te herstellen, bewaard.

Kosten van back-upopslag

Flexibele Azure Database for PostgreSQL-server biedt maximaal 100 procent van uw ingerichte serveropslag als back-upopslag zonder extra kosten. Eventuele extra back-upopslag die u gebruikt, worden in gigabytes per maand in rekening gebracht.

Als u bijvoorbeeld een server hebt ingericht met 250 gibibytes (GiB) aan opslagruimte, hebt u 250 GiB aan back-upopslagcapaciteit zonder extra kosten. Als het dagelijkse back-upgebruik 25 GiB is, kunt u maximaal 10 dagen gratis back-upopslag hebben. Back-upopslagverbruik dat groter is dan 250 GiB, wordt in rekening gebracht zoals gedefinieerd in het prijsmodel.

Als u uw server hebt geconfigureerd met geografisch redundante back-up, worden de back-upgegevens ook gekopieerd naar de gekoppelde Azure-regio. Uw back-upgrootte is dus twee keer zo groot als de lokale back-upkopie. Facturering wordt berekend als ( (2 x lokale back-upgrootte) - ingerichte opslaggrootte ) x prijs @ gigabytes per maand.

U kunt de metrische gegevens Voor back-upopslag gebruikt in Azure Portal gebruiken om de back-upopslag te bewaken die een server verbruikt. De metrische waarde Back-upopslag gebruikt vertegenwoordigt de som van de opslag die wordt gebruikt door alle bewaarde databaseback-ups en logboekback-ups, op basis van de bewaarperiode voor back-ups die voor de server zijn ingesteld.

Notitie

Ongeacht de databasegrootte genereert een zware transactionele activiteit op de server meer WAL-bestanden. De toename van bestanden verhoogt op zijn beurt de back-upopslag.

Herstel naar een bepaald tijdstip

In Azure Database for PostgreSQL flexibele server maakt het uitvoeren van een PITR een nieuwe server in dezelfde regio als uw bronserver, maar u kunt de beschikbaarheidszone kiezen. Deze wordt gemaakt met de configuratie van de bronserver voor de prijscategorie, het genereren van berekeningen, het aantal virtuele kernen, de opslaggrootte, de bewaarperiode voor back-ups en de optie voor back-upredundantie. Bovendien worden tags en instellingen, zoals virtuele netwerken en firewallinstellingen, overgenomen van de bronserver.

De fysieke databasebestanden worden eerst hersteld van de momentopnameback-ups naar de gegevenslocatie van de server. De juiste back-up die eerder is gemaakt dan het gewenste tijdstip, wordt automatisch gekozen en hersteld. Een herstelproces begint vervolgens met behulp van WAL-bestanden om de database in een consistente status te brengen.

Stel dat de back-ups elke nacht om 11:00 uur worden uitgevoerd. Als het herstelpunt voor 15 augustus om 10:00 uur is, wordt de dagelijkse back-up van 14 augustus hersteld. De database wordt hersteld tot 10:00 uur van 15 augustus met behulp van de back-up van het transactielogboek van 14 augustus 11:00 tot 15 augustus 10:00 uur.

Als u de databaseserver wilt herstellen, raadpleegt u deze stappen.

Belangrijk

Met een herstelbewerking in een flexibele Azure Database for PostgreSQL-server wordt altijd een nieuwe databaseserver gemaakt met de naam die u opgeeft. De bestaande databaseserver wordt niet overschreven.

PITR is handig in scenario's zoals deze:

  • Een gebruiker verwijdert per ongeluk gegevens, een tabel of een database.
  • Een toepassing overschrijft per ongeluk goede gegevens met slechte gegevens vanwege een toepassingsfout.
  • U wilt uw server klonen voor testen, ontwikkelen of voor gegevensverificatie.

Met continue back-up van transactielogboeken kunt u herstellen naar de laatste transactie. U kunt kiezen tussen de volgende herstelopties:

  • Laatste herstelpunt (nu): dit is de standaardoptie, waarmee u de server naar het laatste tijdstip kunt herstellen.

  • Aangepast herstelpunt: met deze optie kunt u elk tijdstip kiezen binnen de retentieperiode die is gedefinieerd voor dit flexibele Azure Database for PostgreSQL-serverexemplaren. Standaard wordt de laatste tijd in UTC automatisch geselecteerd. Automatische selectie is handig als u wilt herstellen naar de laatste doorgevoerde transactie voor testdoeleinden. U kunt desgewenst andere dagen en tijden kiezen.

  • Snel herstelpunt: met deze optie kunnen gebruikers de server zo snel mogelijk herstellen binnen de retentieperiode die is gedefinieerd voor hun flexibele Azure Database for PostgreSQL-serverexemplaren. De snelste herstelbewerking is mogelijk door rechtstreeks de tijdstempel te kiezen in de lijst met back-ups. Deze herstelbewerking richt een server in en herstelt eenvoudig de volledige back-up van momentopnamen en vereist geen herstel van logboeken, waardoor het snel gaat. U wordt aangeraden een tijdstempel voor back-ups te selecteren. Dit is groter dan het vroegste herstelpunt voor een geslaagde herstelbewerking.

De tijd die nodig is om te herstellen met behulp van de meest recente en aangepaste herstelpuntopties varieert op basis van factoren zoals het volume van transactielogboeken dat moet worden verwerkt sinds de laatste back-up en het totale aantal databases dat tegelijkertijd in dezelfde regio wordt hersteld. De totale hersteltijd duurt meestal enkele minuten tot een paar uur.

Als u uw server in een virtueel netwerk configureert, kunt u herstellen naar hetzelfde virtuele netwerk of naar een ander virtueel netwerk. U kunt echter niet herstellen naar openbare toegang. Als u uw server hebt geconfigureerd met openbare toegang, kunt u ook geen toegang tot een virtueel particulier netwerk herstellen.

Belangrijk

Verwijderde servers kunnen worden hersteld. Als u de server verwijdert, kunt u onze richtlijnen volgen om een verwijderde Azure Database for Azure Database for PostgreSQL - Flexible Server te herstellen. Gebruik Azure-resourcevergrendeling om te voorkomen dat uw server per ongeluk wordt verwijderd.

Geografisch redundante back-up en herstel

Als u geografisch redundante back-ups wilt inschakelen vanuit het deelvenster Compute en opslag in Azure Portal, raadpleegt u de snelstartgids.

Belangrijk

Geografisch redundante back-up kan alleen worden geconfigureerd op het moment dat de server wordt gemaakt.

Nadat u uw server hebt geconfigureerd met geografisch redundante back-up, kunt u deze herstellen naar een geografisch gekoppelde regio. Zie de ondersteunde regio's voor geografisch redundante back-up voor meer informatie.

Wanneer de server is geconfigureerd met geografisch redundante back-up, worden de back-upgegevens en transactielogboeken asynchroon naar de gekoppelde regio gekopieerd via opslagreplicatie. Nadat u een server hebt gemaakt, wacht u ten minste één uur voordat u een geo-herstelbewerking start. Hierdoor kan de eerste set back-upgegevens worden gerepliceerd naar de gekoppelde regio.

Later worden de transactielogboeken en de dagelijkse back-ups asynchroon gekopieerd naar de gekoppelde regio. Er kan maximaal één uur vertraging optreden bij het verzenden van gegevens. U kunt dus maximaal één uur RPO verwachten wanneer u herstelt. U kunt alleen herstellen naar de laatst beschikbare back-upgegevens die beschikbaar zijn in de gekoppelde regio. Op dit moment is de PITR van geografisch redundante back-ups niet beschikbaar.

De geschatte tijd voor het herstellen van de server (beoogde hersteltijd of RTO) is afhankelijk van factoren zoals de grootte van de database, de laatste back-uptijd van de database en de hoeveelheid WAL die moet worden verwerkt tot de laatste ontvangen back-upgegevens. De totale hersteltijd duurt meestal van een paar minuten tot een paar uur.

Tijdens het geo-herstel zijn de serverconfiguraties die kunnen worden gewijzigd onder andere instellingen voor het virtuele netwerk en de mogelijkheid om geografisch redundante back-ups van de herstelde server te verwijderen. Het wijzigen van andere serverconfiguraties, zoals berekening, opslag of prijscategorie (Burstable, Algemeen gebruik of Geoptimaliseerd voor geheugen), wordt niet ondersteund tijdens geo-herstel.

Zie de handleiding voor instructies voor meer informatie over het uitvoeren van geo-herstel.

Belangrijk

Wanneer de primaire regio niet beschikbaar is, kunt u geen geografisch redundante servers maken in de respectieve geografisch gekoppelde regio, omdat opslag niet kan worden ingericht in de primaire regio. Voordat u geografisch redundante servers in de geografisch gekoppelde regio kunt inrichten, moet u wachten tot de primaire regio is ingeschakeld.

Als de primaire regio offline is, kunt u de bronserver nog steeds herstellen naar de geografisch gekoppelde regio. Zie de handleiding voor instructies voor meer informatie over het uitvoeren van geo-herstel. U moet Geo-replica's gebruiken als herstel na noodgevallen (DR) als u herstel na noodgeval wilt configureren voor een regio of als de primaire regio geen ondersteuning biedt voor geografisch redundante back-ups

Herstellen en netwerken

Herstel naar een bepaald tijdstip

Als uw bronserver is geconfigureerd met een openbaar toegangsnetwerk , kunt u alleen herstellen naar openbare toegang.

Als uw bronserver is geconfigureerd met een virtueel particulier netwerk , kunt u herstellen naar hetzelfde virtuele netwerk of naar een ander virtueel netwerk. U kunt GEEN PITR uitvoeren voor openbare en persoonlijke toegang.

Geo-herstel

Als uw bronserver is geconfigureerd met een openbaar toegangsnetwerk , kunt u alleen herstellen naar openbare toegang. Bestaande firewallregels op de bronserver worden gekopieerd naar de herstelde server. Privé-eindpunten worden niet overgenomen. Nadat de herstelbewerking is voltooid, controleert u of u een van de door u overgedragen firewallregels moet aanpassen en eventuele privé-eindpunten moet maken die u mogelijk nodig hebt.

Als uw bronserver is geconfigureerd met een virtueel netwerk voor privétoegang , kunt u alleen herstellen naar een ander virtueel netwerk, omdat virtuele netwerken geen regio's kunnen omvatten. U kunt geen geo-herstel uitvoeren voor openbare en persoonlijke toegang.

Post-restore tasks

Nadat u de server hebt hersteld, kunt u de volgende taken uitvoeren om uw gebruikers en toepassingen weer actief te maken:

  • Als de nieuwe server bedoeld is om de oorspronkelijke server te vervangen, moet u clients en clienttoepassingen omleiden naar de nieuwe server. Wijzig de servernaam van uw verbindingsreeks zodat deze verwijst naar de nieuwe server.

  • Zorg ervoor dat de juiste firewall op serverniveau, privé-eindpunten en regels voor virtuele netwerken aanwezig zijn voor gebruikersverbindingen. In het openbare toegangsnetwerk worden regels gekopieerd van de oorspronkelijke server, maar deze zijn mogelijk niet de regels die vereist zijn in de herstelde omgeving. Pas ze dus aan op basis van uw vereisten. Privé-eindpunten worden niet overgedragen. Maak privé-eindpunten die u mogelijk nodig hebt op de herstelde server. In het virtuele netwerk voor privétoegang kopieert het herstel niet via artefacten van de netwerkinfrastructuur van de bron naar herstelde servernetwerken. Alles met betrekking tot de configuratie van VNET-, subnetten of netwerkbeveiligingsgroepen moet worden uitgevoerd als een taak na het herstellen.

  • Schaal de rekenkracht van de herstelde server naar behoefte omhoog of omlaag.

  • Zorg ervoor dat de juiste aanmeldingen en machtigingen op databaseniveau aanwezig zijn.

  • Configureer waar nodig waarschuwingen.

  • Als de bronserver van waaruit u hebt hersteld, is geconfigureerd met hoge beschikbaarheid en u de herstelde server wilt configureren met hoge beschikbaarheid, kunt u deze stappen uitvoeren.

  • Als de bronserver van waaruit u hebt hersteld, is geconfigureerd met leesreplica's en u leesreplica's wilt configureren op de herstelde server, kunt u deze stappen uitvoeren.

Langetermijnretentie (preview)

Azure Backup- en Azure Database for PostgreSQL Flexibele serverservices hebben een oplossing voor langetermijnback-ups gemaakt voor Azure Database for PostgreSQL flexibele serverexemplaren die back-ups maximaal 10 jaar bewaren. U kunt langetermijnretentie onafhankelijk of naast de automatische back-upoplossing van Azure Database for PostgreSQL flexibele server gebruiken, die retentie van maximaal 35 dagen biedt. Geautomatiseerde back-ups zijn fysieke back-ups die geschikt zijn voor operationele herstelbewerkingen, met name wanneer u wilt herstellen vanaf de meest recente back-ups. Langetermijnback-ups helpen u bij uw nalevingsbehoeften, zijn gedetailleerder en worden als logische back-ups gemaakt met behulp van systeemeigen pg_dump. Naast langetermijnretentie biedt de oplossing de volgende mogelijkheden:

  • Door de klant beheerde geplande en on-demand back-ups op het niveau van individuele databases
  • Centrale controle van alle bewerkingen en taken.
  • Back-ups die zijn opgeslagen in een afzonderlijk beveiligings- en foutdomeinen. Als de bronserver of het abonnement is gecompromitteerd, blijven de back-ups veilig in de Backup-kluis (in door Azure Backup beheerde opslagaccounts).
  • Het gebruik van pg_dump biedt meer flexibiliteit bij het herstellen van gegevens in verschillende databaseversies.
  • Azure Backup-kluizen ondersteunen onveranderbaarheid en functies voor voorlopig verwijderen (preview) om uw gegevens te beveiligen.
  • Ondersteuning voor LTR-back-ups voor SERVERS met CMK

Beperkingen en overwegingen

  • LTR-herstelbewerkingen zijn momenteel alleen beschikbaar als 'Herstellen als bestanden' voor opslagaccounts, met de mogelijkheid 'Herstellen als server' gepland voor de toekomst.
  • LTR maakt een back-up van alle databases in exemplaren van flexibele servers en afzonderlijke databases kunnen niet worden geselecteerd voor de LTR-configuratie.
  • LTR-back-up wordt niet ondersteund op geo-replica's, maar kan worden uitgevoerd vanaf primaire servers.
  • De maximale ondersteunde databasegrootte voor LTR-back-up is 4 TiB.
  • LTR-back-ups kunnen wekelijks, maandelijks of jaarlijks worden gepland. Het dagelijkse back-upschema wordt momenteel niet ondersteund.

Ga naar de handleiding voor instructies voor meer informatie over het uitvoeren van een back-up op lange termijn.

Veelgestelde vragen

  • Hoe verwerkt Azure back-ups van mijn server?

    Standaard maakt azure Database for PostgreSQL flexibele server automatische back-ups van uw hele server mogelijk (die alle databases omvat) met een standaardretentieperiode van 7 dagen. De automatische back-ups bevatten een dagelijkse incrementele momentopname van de database. De logboekbestanden (WAL) worden continu gearchiveerd in Azure Blob Storage.

  • Kan ik automatische back-ups configureren om gegevens op de lange termijn te bewaren?

    Nee Momenteel biedt Azure Database for PostgreSQL flexibele server ondersteuning voor maximaal 35 dagen retentie. U kunt handmatige back-ups gebruiken voor een langetermijnretentievereiste.

  • Hoe kan ik handmatig een back-up maken van mijn exemplaren van flexibele Azure Database for PostgreSQL-servers?

    U kunt handmatig een back-up maken met behulp van het PostgreSQL-hulpprogramma pg_dump. Zie Uw flexibele Azure Database for PostgreSQL-serverdatabase migreren met behulp van dump en herstel voor voorbeelden.

    Als u een back-up wilt maken van een flexibele Azure Database for PostgreSQL-server naar Blob Storage, raadpleegt u Een back-up maken van Azure Database for PostgreSQL naar Blob Storage in onze blog van de tech community.

  • Wat zijn de back-upvensters voor mijn server? Kan ik ze aanpassen?

    Azure beheert back-upvensters en u kunt ze niet aanpassen. De eerste volledige momentopnameback-up wordt gepland direct nadat een server is gemaakt. Volgende momentopnameback-ups zijn incrementeel en worden eenmaal per dag uitgevoerd.

  • Worden mijn back-ups versleuteld?

    Ja. Alle flexibele Azure Database for PostgreSQL-servergegevens, back-ups en tijdelijke bestanden die worden gemaakt tijdens het uitvoeren van query's, worden versleuteld via AES 256-bits versleuteling. Opslagversleuteling is altijd actief en kan niet worden uitgeschakeld.

  • Kan ik één database of een paar databases op een server herstellen?

    Het herstellen van één database of een paar databases of tabellen wordt niet rechtstreeks ondersteund. U kunt de hele server echter herstellen naar een nieuwe server en vervolgens tabellen of databases extraheren en deze importeren naar de nieuwe server.

  • Is mijn server beschikbaar terwijl er een back-up wordt uitgevoerd?

    Ja. Back-ups zijn onlinebewerkingen die gebruikmaken van momentopnamen. De momentopnamebewerking duurt slechts een paar seconden en interfereert niet met productieworkloads om hoge beschikbaarheid van de server te garanderen.

  • Wanneer ik het onderhoudsvenster voor de server instelt, moet ik dan rekening houden met het back-upvenster?

    Nee Back-ups worden intern geactiveerd als onderdeel van de beheerde service en hebben geen invloed op het onderhoudsvenster.

  • Waar worden mijn geautomatiseerde back-ups opgeslagen en hoe beheer ik hun retentie?

    Flexibele Azure Database for PostgreSQL-server maakt automatisch serverback-ups en slaat deze op in:

    • Zone-redundante opslag, in regio's waar meerdere zones worden ondersteund.
    • Lokaal redundante opslag, in regio's die nog geen ondersteuning bieden voor meerdere zones.
    • De gekoppelde regio, als u geografisch redundante back-ups configureert.

    Deze back-upbestanden kunnen niet worden geëxporteerd.

    U kunt back-ups gebruiken om uw server alleen naar een bepaald tijdstip te herstellen. De standaard retentieperiode voor back-ups is 7 dagen. U kunt eventueel de back-upretentie tot 35 dagen configureren.

  • Hoe vaak wordt de back-up met geografisch redundante back-ups gekopieerd naar de gekoppelde regio?

    Wanneer de server is geconfigureerd met geografisch redundante back-up, worden de back-upgegevens opgeslagen in een geografisch redundant opslagaccount. Het opslagaccount kopieert gegevensbestanden naar de gekoppelde regio wanneer de dagelijkse back-up plaatsvindt op de primaire server. Er wordt een back-up gemaakt van WAL-bestanden wanneer ze klaar zijn om te worden gearchiveerd.

    Back-upgegevens worden asynchroon gekopieerd naar de gekoppelde regio. U kunt maximaal één uur vertraging verwachten bij het ontvangen van back-upgegevens.

  • Kan ik PITR uitvoeren in de externe regio?

    Nee De gegevens worden hersteld naar de laatst beschikbare back-upgegevens in de externe regio.

  • Hoe worden back-ups uitgevoerd op servers met hoge beschikbaarheid?

    Er wordt een back-up gemaakt van gegevensvolumes in azure Database for PostgreSQL flexibele server via incrementele momentopnamen van beheerde schijven vanaf de primaire server. De WAL-back-up wordt uitgevoerd vanaf de primaire server of de stand-byserver.

  • Hoe kan ik valideren dat back-ups worden uitgevoerd op mijn server?

    De beste manier om back-ups te controleren, is door periodieke pitr uit te voeren en ervoor te zorgen dat back-ups geldig en herstelbaar zijn. Back-upbewerkingen of -bestanden zijn niet beschikbaar voor eindgebruikers.

  • Waar kan ik het back-upgebruik zien?

    Selecteer in De Azure-portal onder Bewaking de optie Metrische gegevens. In Gebruikte back-upopslag kunt u het totale back-upgebruik bewaken.

  • Wat gebeurt er met mijn back-ups als ik mijn server verwijder?

    Als u een server verwijdert, worden alle back-ups die deel uitmaken van de server ook verwijderd en kunnen ze niet worden hersteld. Beheerders kunnen beheervergrendelingen gebruiken om serverbronnen te beschermen tegen onbedoeld verwijderen of onverwachte wijzigingen na de implementatie.

  • Hoe worden back-ups bewaard voor gestopte servers?

    Er worden geen nieuwe back-ups uitgevoerd voor gestopte servers. Alle oudere back-ups (binnen het bewaarvenster) op het moment dat de server wordt gestopt, worden bewaard totdat de server opnieuw wordt opgestart. Daarna wordt back-upretentie voor de actieve server beheerd door het bewaarvenster.

  • Hoe worden er kosten in rekening gebracht en gefactureerd voor mijn back-ups?

    Flexibele Azure Database for PostgreSQL-server biedt maximaal 100 procent van uw ingerichte serveropslag als back-upopslag zonder extra kosten. Elke back-upopslag die u gebruikt, wordt in gigabytes per maand in rekening gebracht, zoals gedefinieerd in het prijsmodel.

    De bewaarperiode voor back-ups en de optie voor back-upredundantie die u selecteert, samen met transactionele activiteit op de server, is rechtstreeks van invloed op de totale back-upopslag en facturering.

  • Hoe wordt er gefactureerd voor een gestopte server?

    Terwijl uw serverexemplaren zijn gestopt, worden er geen nieuwe back-ups uitgevoerd. Er worden kosten in rekening gebracht voor ingerichte opslag en back-upopslag (back-ups die zijn opgeslagen in het opgegeven bewaarvenster).

    Gratis back-upopslag is beperkt tot de grootte van uw ingerichte database. Eventuele overtollige back-upgegevens worden in rekening gebracht volgens de back-upprijs.

  • Ik heb mijn server geconfigureerd met zone-redundante hoge beschikbaarheid. Maak je twee back-ups en worden er twee keer kosten in rekening gebracht?

    Nee Ongeacht hoge beschikbaarheids- of niet-hoge beschikbaarheidsservers wordt slechts één set back-upkopieën onderhouden. Er worden slechts eenmaal kosten in rekening gebracht.

  • Hoe kan ik mijn server herstellen?

    ondersteuning voor Azure pitr voor alle servers. Gebruikers kunnen herstellen naar het meest recente herstelpunt of een aangepast herstelpunt met behulp van Azure Portal, de Azure CLI en de API.

    Als u uw server wilt herstellen vanuit handmatige back-ups met behulp van hulpprogramma's zoals pg_dump, kunt u eerst een exemplaar van een flexibele Azure Database for PostgreSQL-server maken en vervolgens uw databases herstellen naar de server met behulp van pg_restore.

  • Kan ik herstellen naar een andere beschikbaarheidszone binnen dezelfde regio?

    Ja. Als de regio meerdere beschikbaarheidszones ondersteunt, wordt de back-up opgeslagen in een zone-redundant opslagaccount, zodat u kunt herstellen naar een andere zone.

  • Hoe lang duurt een PITR? Waarom duurt het zoveel tijd voor mijn herstel?

    De gegevensherstelbewerking van een momentopname is niet afhankelijk van de grootte van de gegevens. Maar de timing van het herstelproces waarmee de logboeken (transactieactiviteiten om opnieuw te worden afgespeeld) kunnen variëren, afhankelijk van de vorige back-up van de aangevraagde datum/tijd en het aantal logboeken dat moet worden verwerkt. Dit geldt zowel voor het herstellen binnen dezelfde zone als voor het herstellen van gegevens naar een andere zone.

  • Als ik mijn server met hoge beschikbaarheid herstel, wordt de herstelserver automatisch geconfigureerd met hoge beschikbaarheid?

    Nee De server wordt hersteld als een exemplaar van azure Database for PostgreSQL Flexibele server met één exemplaar. Nadat het herstellen is voltooid, kunt u de server desgewenst configureren met hoge beschikbaarheid.

  • Ik heb mijn server in een virtueel netwerk geconfigureerd. Kan ik herstellen naar een ander virtueel netwerk?

    Ja. Kies op het moment van herstellen een ander virtueel netwerk om naar te herstellen.

  • Kan ik mijn openbare toegangsserver herstellen naar een virtueel netwerk of omgekeerd?

    Nee Flexibele Azure Database for PostgreSQL-server biedt momenteel geen ondersteuning voor het herstellen van servers via openbare en persoonlijke toegang.

  • Hoe kan ik mijn herstelbewerking bijhouden?

    Op dit moment is er geen manier om de herstelbewerking bij te houden. U kunt het activiteitenlogboek controleren om te zien of de bewerking wordt uitgevoerd of voltooid.

Volgende stappen