Sdílet prostřednictvím

Zálohování a obnovení ve službě Azure Database for PostgreSQL

Zálohy tvoří základní součást jakékoli strategie provozní kontinuity. Pomáhají chránit data před náhodným poškozením nebo odstraněním.

Azure Database for PostgreSQL automaticky provádí pravidelné zálohy vašeho serveru. Poté můžete provést obnovení k určitému bodu v čase (PITR) během vámi specifikované doby uchování. Celková doba obnovy a zotavení obvykle závisí na velikosti dat a množství provedené obnovy.

Přehled služby Backup

Azure Database for PostgreSQL vytváří zálohy snímků datových souborů a bezpečně je ukládá v zónově redundantním úložišti nebo místně redundantním úložišti v závislosti na oblasti. Server také zálohuje transakční protokoly, když je soubor WAL (Write-ahead Log) připravený k archivaci. Tyto zálohy můžete použít k obnovení serveru k jakémukoli bodu v čase v rámci nakonfigurovaného období uchovávání záloh.

Výchozí doba uchovávání záloh je 7 dnů, ale dobu můžete prodloužit na maximálně 35 dnů. Všechny zálohy jsou šifrované prostřednictvím 256bitového šifrování AES pro neaktivní uložená data.

Tyto záložní soubory nejde exportovat ani použít k vytvoření serverů mimo instanci flexibilního serveru Azure Database for PostgreSQL. Pro tento účel můžete použít nástroje PostgreSQL pg_dump a pg_restore/psql.

Frekvence zálohování

Zálohy na instancích flexibilního serveru Azure Database for PostgreSQL jsou založené na snímcích. První záloha snímků je naplánována okamžitě po vytvoření serveru. Zálohy snímků se pořizují jednou denně. Pokud se po posledním zálohování snímků neprovedou žádné další úpravy žádné databáze na serveru, zálohy snímků se dočasně pozastaví. Jakmile dojde k úpravě jakékoli databáze na serveru, okamžitě se pořídí nový snímek, který zachytí nejnovější změny. První snímek je kompletní záloha a následující snímky jsou přírůstkové zálohy.

Zálohování transakčních protokolů probíhá v různých frekvencích v závislosti na zatížení a na tom, kdy je soubor WAL naplněný a připravený k archivaci. Obecně platí, že zpoždění RPO (bod obnovy) může být až 5 minut.

Nastavení redundance zálohy

Azure Database for PostgreSQL ukládá několik kopií záloh, které pomáhají chránit vaše data před plánovanými a neplánovanými událostmi. Tyto události můžou zahrnovat přechodné selhání hardwaru, výpadky sítě nebo napájení a přírodní katastrofy. Redundance zálohování pomáhá zajistit, aby vaše databáze splňovala cíle dostupnosti a stálosti, i když dojde k selháním.

Azure Database for PostgreSQL nabízí tři možnosti:

  • Zónově redundantní úložiště zálohování: Tato možnost se automaticky vybere pro oblasti, které podporují zóny dostupnosti. Pokud jsou zálohy uložené v zónově redundantním úložišti zálohování, uchovávají se tři kopie dat v zóně dostupnosti, kde je váš server hostovaný. Kromě toho se data replikují do jiné zóny dostupnosti pro přidanou ochranu.

    Tato možnost poskytuje dostupnost zálohovaných dat napříč zónami dostupnosti a omezuje replikaci dat do určité země nebo oblasti tak, aby splňovala požadavky na rezidenci dat. Tato možnost poskytuje alespoň 99,9999999999 % (12 devítek) odolnost zálohovaných objektů za rok.

  • Místně redundantní úložiště zálohování: Tato možnost se automaticky vybere pro oblasti, které ještě nepodporují zóny dostupnosti. Pokud jsou zálohy uložené v místně redundantním úložišti zálohování, uloží se ve stejném datacentru několik kopií záloh.

    Tato možnost pomáhá chránit vaše data před selháním serverové skříně a disku. Poskytuje alespoň 99,999999999 % (11 devítek) odolnost zálohovaných objektů za rok.

    Ve výchozím nastavení je úložiště záloh pro servery se stejnou zónou vysoké dostupnosti (HA) nebo bez konfigurace vysoké dostupnosti nastaveno na místně redundantní.

  • Geograficky redundantní úložiště zálohování: Tuto možnost můžete zvolit při vytváření serveru. Pokud jsou zálohy uložené v geograficky redundantním úložišti zálohování, kromě tří kopií dat uložených v oblasti, kde je váš server hostovaný, se data replikují do geograficky spárované oblasti.

    Tato možnost umožňuje obnovit server v jiné oblasti v případě havárie. Poskytuje také alespoň 99,99999999999999 % (16 devítek) trvanlivost zálohovaných objektů během ročního období.

    Geografická redundance se podporuje pro servery hostované v některé z spárovaných oblastí Azure.

Přechod z jiných možností úložiště zálohování na geograficky redundantní úložiště zálohování

Geograficky redundantní úložiště můžete nakonfigurovat pouze při vytváření serveru. Po zřízení serveru nemůžete změnit volbu redundance zálohovacího úložiště.

Uchování záloh

Zálohy se uchovávají na základě doby uchovávání, kterou jste nastavili pro server. Můžete vybrat dobu uchovávání mezi 7 (výchozí) a 35 dny. Dobu uchovávání můžete nastavit během vytváření serveru nebo ji později změnit. Zálohy se uchovávají i pro zastavené servery.

Doba uchovávání záloh určuje časový rámec, ve kterém je možné pomocí dostupných záloh provést obnovení k určitému bodu v minulosti (PITR). Dobu uchovávání záloh můžete také považovat za okno obnovení z pohledu obnovy.

Všechny zálohy potřebné k provedení obnovení do konkrétního bodu v čase během období uchovávání záloh se uchovávají v úložišti záloh. Pokud je například doba uchovávání záloh nastavená na 7 dnů, okno obnovení je posledních 7 dnů. V tomto scénáři se zachovávají všechna data a protokoly potřebné k obnovení serveru za posledních 7 dnů.

Náklady na zálohovací úložiště

Azure Database for PostgreSQL poskytuje až 100 % zřízeného úložiště serveru jako úložiště záloh bez dalších poplatků. Za každé další zálohovací úložiště, které používáte, je účtováno podle gigabajtů za měsíc.

Pokud jste například zřídili server s 250 gibibajtemi (GiB) úložiště, máte 250 GiB kapacity úložiště zálohování bez dalších poplatků. Pokud je denní využití zálohování 25 GiB, můžete mít až 10 dnů bezplatného úložiště zálohování. Spotřeba úložiště zálohování, která překračuje 250 GiB, se účtuje podle definice v cenovém modelu.

Pokud jste server nakonfigurovali s geograficky redundantním zálohováním, data záloh se zkopírují také do spárované oblasti Azure. Velikost zálohy bude tedy dvojnásobná než velikost místní záložní kopie. Fakturace se vypočítá jako (2 x velikost místního zálohování) – zřízená velikost úložiště ) x cena za gigabajty za měsíc.

Pomocí metriky Využité úložiště zálohování na webu Azure Portal můžete monitorovat úložiště zálohování, které server využívá. Metrika Využité úložiště zálohování představuje součet úložiště spotřebovaného všemi uchovávanými zálohami databáze a zálohami protokolů na základě doby uchovávání záloh nastavené pro server.

Poznámka:

Bez ohledu na velikost databáze generuje velká transakční aktivita na serveru více souborů WAL. Zvýšením souborů se zase zvýší úložiště zálohování.

Obnovení dat k určitému okamžiku v čase

V instanci flexibilního serveru Azure Database for PostgreSQL vytvoří provedení obnovy k určitému bodu v čase (PITR) nový server ve stejné oblasti jako zdrojový server, ale můžete zvolit zónu dostupnosti. Vytvoří se s konfigurací zdrojového serveru pro cenovou úroveň, generaci výpočetních prostředků, počet virtuálních jader, velikost úložiště, dobu uchovávání záloh a možnost redundance zálohování.

Fyzické soubory databáze jsou nejprve obnoveny ze snímkových záloh do umístění dat serveru. Příslušná záloha, která byla provedena dříve než požadovaný časový bod, se automaticky vybere a obnoví. Proces obnovení pak začne použitím souborů WAL, aby byla databáze v konzistentním stavu.

Předpokládejme například, že zálohy se provádějí každou noc v 11:00. Pokud je bod obnovení nastaven na 15. srpna v 10:00, obnoví se denní záloha z 14. srpna. Databáze bude obnovena do 10:00 dne 15. srpna pomocí zálohy transakčního protokolu z 14. srpna 23:00 hod. do 15. srpna 10:00 hod.

Pokud chcete obnovit databázový server, podívejte se na některou z těchto věcí:

Důležité

Operace obnovení v instanci flexibilního serveru Azure Database for PostgreSQL vždy vytvoří nový databázový server s názvem, který zadáte. Nepřepíše stávající databázový server.

PitR je užitečný ve scénářích, jako jsou tyto:

  • Uživatel omylem odstraní data, tabulku nebo databázi.
  • Aplikace omylem přepíše dobrá data chybnými daty kvůli vadě aplikace.
  • Chcete naklonovat server pro testování, vývoj nebo ověření dat.

S průběžným zálohováním transakčních protokolů můžete provést obnovení na poslední transakci. Můžete si vybrat mezi následujícími možnostmi obnovení:

  • Nejnovější bod obnovení (nyní):Toto je výchozí možnost, která umožňuje obnovit server k nejnovějšímu bodu v čase.

  • Vlastní bod obnovení: Tato možnost umožňuje zvolit libovolný bod v čase v rámci doby uchovávání definované pro tuto instanci flexibilního serveru Azure Database for PostgreSQL. Ve výchozím nastavení se automaticky vybere poslední čas v UTC. Automatický výběr je užitečný, pokud chcete obnovit poslední potvrzenou transakci pro účely testování. Volitelně můžete zvolit jiné dny a časy.

  • Rychlý bod obnovení: Tato možnost umožňuje uživatelům obnovit server v nejrychlejším možném čase během doby uchovávání definované pro instanci flexibilního serveru Azure Database for PostgreSQL. Nejrychlejší obnovení je možné přímo výběrem časového razítka ze seznamu záloh. Tato operace obnovení zřídí server a jednoduše obnoví úplnou zálohu snímků a nevyžaduje žádné obnovení protokolů, což ji činí rychlou. Doporučujeme vybrat časové razítko zálohování, které je pozdější než nejstarší bod obnovení, pro úspěšnou operaci obnovení.

Doba potřebná k obnovení pomocí nejnovějších a vlastních možností bodu obnovení se liší podle faktorů, jako je objem transakčních protokolů, které se mají zpracovat od poslední zálohy a celkový počet databází, které se obnovují současně ve stejné oblasti. Celková doba obnovení obvykle trvá několik minut až několik hodin.

Pokud nakonfigurujete server ve virtuální síti, můžete provést obnovení do stejné virtuální sítě nebo do jiné virtuální sítě. Nemůžete ale obnovit veřejný přístup. Podobně pokud jste server nakonfigurovali s veřejným přístupem, nemůžete provést obnovení k privátnímu přístupu k virtuální síti.

Důležité

Odstraněné servery je možné obnovit. Pokud server odstraníte, můžete postupovat podle našich pokynů k obnovení vyřazeného flexibilního serveru Azure Database for Azure Database for PostgreSQL . Chcete-li zabránit náhodnému odstranění serveru, použijte zámek zdrojů Azure.

Geograficky redundantní zálohování a obnovení

Pokud chcete povolit geograficky redundantní zálohování z podokna Výpočty a úložiště na webu Azure Portal, přečtěte si téma Vytvoření služby Azure Database for PostgreSQL.

Důležité

Geograficky redundantní zálohování je možné nakonfigurovat pouze při vytváření serveru.

Jakmile nakonfigurujete server s geograficky redundantním zálohováním, můžete ho obnovit do geograficky spárované oblasti. Další informace najdete v podporovaných oblastech pro geograficky redundantní zálohování.

Pokud je server nakonfigurovaný s geograficky redundantním zálohováním, data záloh a transakční protokoly se kopírují do spárované oblasti asynchronně prostřednictvím replikace úložiště. Po vytvoření serveru počkejte aspoň hodinu před zahájením geografického obnovení. To umožňuje replikaci první sady zálohovaných dat do spárované oblasti.

Později se transakční protokoly a denní zálohy asynchronně zkopírují do spárované oblasti. Přenos dat může mít zpoždění až jednu hodinu. Takže při obnovení můžete očekávat RPO až jednu hodinu. Můžete obnovit pouze poslední dostupná zálohovaná data, která jsou k dispozici ve spárované oblasti. V současné době není k dispozici PITR geograficky redundantních záloh.

Odhadovaná doba obnovení serveru RTO (cíl doby obnovení) závisí na faktorech, jako je velikost databáze, čas poslední zálohy databáze a množství WAL k zpracování, dokud nejsou přijata poslední zálohovaná data. Celková doba obnovení obvykle trvá několik minut až několik hodin.

Během geografického obnovení zahrnují konfigurace serveru, které je možné změnit, nastavení virtuální sítě a možnost odebrat geograficky redundantní zálohování z obnoveného serveru. Změna jiných konfigurací serveru, jako jsou výpočetní prostředky, úložiště nebo cenová úroveň (burstable, pro obecné účely nebo optimalizováno pro paměť), se během geografického obnovení nepodporuje.

Další informace naleznete v Obnovení do spárované oblasti (geografické obnovení).

Důležité

Když je primární oblast mimo provoz, nemůžete v příslušné geografické spárované oblasti vytvářet geograficky redundantní servery, protože úložiště nejde zřídit v primární oblasti. Než budete moct zřídit geograficky redundantní servery v geograficky spárované oblasti, musíte počkat, až bude primární oblast funkční.

Když je primární oblast mimo provoz, můžete zdrojový server ještě geograficky obnovit do geograficky spárované oblasti. Další informace naleznete v Obnovení do spárované oblasti (geografické obnovení). Pokud potřebujete nakonfigurovat zotavení po havárii do jakékoli oblasti nebo pokud primární oblast nepodporuje geograficky redundantní zálohy, měli byste jako strategii zotavení po havárii použít geograficky redundantní repliky.

Pro důležité úlohy doporučujeme používat virtuální koncové body, protože poskytují stabilní spojovací bod pro aplikace, což zajišťuje minimální přerušení. Pokud máte na primární server namapovaný virtuální koncový bod, odeberte tento virtuální koncový bod z primárního serveru, a jakmile bude odebrán, přidejte stejný virtuální koncový bod na nově vytvořený server. Tím se zajistí, že připojení k aplikacím zůstane konzistentní a minimalizuje výpadky. Další informace najdete v tématu použití virtuálních koncových bodů pro konzistentní hostname během PITR.

Obnovení a sítě

Obnovení dat k určitému okamžiku v čase

Pokud je zdrojový server nakonfigurovaný s veřejnou přístupovou sítí, můžete ho obnovit jenom do veřejného přístupu.

Pokud je zdrojový server nakonfigurovaný s virtuální sítí privátního přístupu , můžete provést obnovení buď do stejné virtuální sítě, nebo do jiné virtuální sítě. PitR nemůžete provádět napříč veřejným a privátním přístupem.

Geografická obnova

Pokud je zdrojový server nakonfigurovaný s veřejnou přístupovou sítí, můžete ho obnovit jenom do veřejného přístupu. Po dokončení operace obnovení musíte také použít pravidla brány firewall.

Pokud je váš zdrojový server nakonfigurovaný s virtuální sítí privátního přístupu , můžete provést obnovení pouze do jiné virtuální sítě, protože virtuální sítě nemůžou zahrnovat oblasti. Geografické obnovení není možné provádět napříč veřejným a privátním přístupem.

Úlohy po obnovení

Po obnovení serveru můžete provést následující úlohy, abyste znovu uvedli uživatele a aplikace do provozu:

  • Pokud má nový server nahradit původní server, přesměrujte klienty a klientské aplikace na nový server. Změňte název serveru ve vašem připojovacím řetězci tak, aby odkazoval na nový server.

  • Hodnoty všech parametrů serveru na původním serveru se na nový server automaticky nepoužijí. Ujistěte se, že jsou všechny parametry serveru na novém serveru znovu nakonfigurované podle požadavků tohoto nového serveru.

  • Ujistěte se, že jsou pro připojení uživatelů zavedená příslušná pravidla brány firewall na úrovni serveru, privátní koncové body a pravidla virtuální sítě. Tato pravidla se nezkopírují z původního serveru.

  • Podle potřeby zvyšte nebo snižte kapacitu výpočetních prostředků obnoveného serveru.

  • Ujistěte se, že jsou zavedená příslušná přihlášení a oprávnění na úrovni databáze.

  • Podle potřeby nakonfigurujte upozornění.

  • Pokud byl zdrojový server, ze kterého jste obnovili, nakonfigurovaný s vysokou dostupností a chcete nakonfigurovat obnovený server s vysokou dostupností, můžete postupovat podle těchto kroků.

  • Pokud byl zdrojový server, ze kterého jste obnovili, nakonfigurovaný s replikami pro čtení a chcete nakonfigurovat repliky pro čtení na obnoveného serveru, můžete postupovat podle pokynů v části Vytvoření repliky pro čtení.

Zálohování na vyžádání

Instance flexibilního serveru Azure Database for PostgreSQL automaticky generuje snímky svazků úložiště celé instance databáze, které pokrývají všechny databáze jako součást plánovaných záloh. Kromě toho můžete kdykoli vytvořit zálohu na vyžádání, která je ideální pro scénáře, jako je příprava na potenciálně rizikovou operaci nebo provádění pravidelných aktualizací mimo obvyklý plán zálohování.

Zálohy na vyžádání je možné provádět kromě plánovaných automatických záloh. Tyto zálohy se uchovávají podle okna uchovávání záloh. Tyto zálohy na vyžádání můžete kdykoli odstranit, pokud už je nepotřebujete. Pokud chcete zahájit zálohování na vyžádání, jednoduše vyberte instanci databáze, kterou chcete zálohovat, a zadejte název zálohy. Tyto zálohy se ukládají společně s automatizovanými zálohami, ale pouze zálohy na vyžádání můžou uživatelé odstranit, protože automatizované zálohy spravuje a uchovává služba, aby splňovala požadavky na uchovávání záloh.

Další informace najdete v tématu Provádění záloh na vyžádání.

Omezení

  • Funkce zálohování na vyžádání není v současné době podporována u výpočetní vrstvy serveru s nárazovým škálováním.
  • Funkce zálohování na vyžádání se v současné době nepodporuje s úrovní úložiště SSDv2.
  • Na instanci flexibilního serveru můžete využít maximálně 7 záloh na vyžádání, které se uchovávají v závislosti na intervalu uchovávání záloh.

Dlouhodobé uchovávání

Služby Azure Backup a Azure Database for PostgreSQL vytvořily podnikové řešení dlouhodobého zálohování pro instance flexibilního serveru Azure Database for PostgreSQL, které uchovávají zálohy po dobu až 10 let. Dlouhodobé uchovávání (LTR) můžete používat nezávisle nebo kromě automatizovaného řešení zálohování nabízeného službou Azure Database for PostgreSQL, které nabízí uchovávání až 35 dnů. Automatizované zálohy jsou fyzické zálohy vhodné pro provozní obnovení, zejména pokud chcete provést obnovení z nejnovějších záloh. Dlouhodobé zálohování vám pomůže s vašimi potřebami dodržování předpisů, jsou podrobnější a provádějí se jako logické zálohy pomocí nativních pg_dump. Kromě dlouhodobého uchovávání nabízí řešení následující schopnosti:

  • Plánované zálohování a zálohování na vyžádání na jednotlivých úrovních databáze řízené zákazníkem.
  • Centrální monitorování všech operací a úloh.
  • Zálohy se ukládají v samostatných doménách zabezpečení a poruch. Pokud dojde k ohrožení zabezpečení zdrojového serveru nebo předplatného, zálohy zůstanou v trezoru služby Backup (ve spravovaných účtech úložiště Azure Backup) v bezpečí.
  • Použití pg_dump umožňuje větší flexibilitu při obnovování dat napříč různými verzemi databáze.
  • Trezory služby Azure Backup podporují funkce neměnnosti a obnovitelného odstranění (Preview), které chrání vaše data.
  • Podpora zálohování LTR pro servery s podporou CMK.

Omezení a důležité informace

  • Důrazně doporučujeme okamžitě po konfiguraci otestovat zálohování LTR a obnovit, abyste zajistili, že splňují vaše obchodní požadavky.
  • Obnovení LTR jsou v současnosti k dispozici pouze jako 'Obnovení jako soubory' pro účty úložiště, přičemž schopnost 'Obnovit jako server' je plánována do budoucna.
  • LTR zálohuje všechny databáze v instancích flexibilních serverů a pro konfiguraci LTR nelze vybrat jednotlivé databáze.
  • Zálohování LTR není podporováno na replikách, je možné ho provádět na primárních serverech.
  • Maximální podporovaná velikost databáze pro zálohy dlouhodobého uchovávání (LTR) je 1 TiB.
  • Zálohy LTR je možné naplánovat týdně, měsíčně nebo ročně. Plán denního zálohování se v současné době nepodporuje.
  • Zálohy LTR nepodporují tabulky obsahující řádek s délkou BYTEA větší než 500 MB.
  • Při obnovování rolí pro uživatele Microsoft Entra se ujistěte, že je povolené ověřování Microsoft Entra a že jste přihlášeni jako správce Microsoft Entra, abyste mohli vytvářet další uživatele. Při pokusu o vytvoření rolí Entra jako normálního uživatele dojde k chybám.

Další informace o provádění dlouhodobé zálohy najdete v průvodci postupy.

Nejčastější dotazy

  • Jak Azure zpracovává zálohování serveru?

    Azure Database for PostgreSQL ve výchozím nastavení umožňuje automatizované zálohování celého serveru (včetně všech vytvořených databází) s výchozí dobou uchovávání 7 dnů. Automatizované zálohy zahrnují denní přírůstkový snímek databáze. Soubory protokolu (WAL) se průběžně archivují do služby Azure Blob Storage.

  • Můžu nakonfigurovat automatizované zálohy tak, aby uchovály data po dlouhou dobu?

    Ne. Azure Database for PostgreSQL v současné době podporuje maximálně 35 dnů uchovávání. Ruční zálohování můžete použít k dlouhodobému požadavku na uchovávání pomocí služby Azure Backup.

  • Návody ručně zálohovat instance flexibilního serveru Azure Database for PostgreSQL?

    Fyzický snímek můžete pořídit ručně pomocí funkce zálohování na vyžádání. Logické zálohy můžete provádět také pomocí nástroje PostgreSQL pg_dump. Příklady najdete v tématu Migrace databáze Azure Database for PostgreSQL pomocí výpisu a obnovení.

  • Jaká jsou okna zálohování pro můj server? Můžu je přizpůsobit?

    Azure spravuje okna zálohování a nemůžete je přizpůsobit. První úplné zálohování snímků je naplánované okamžitě po vytvoření serveru. Následné zálohování snímků je přírůstkové a probíhá jednou denně.

  • Jsou moje zálohy šifrované?

    Ano. Všechna data, zálohy a dočasné soubory instance flexibilního serveru Azure Database for PostgreSQL, které se vytvářejí během provádění dotazů, se šifrují prostřednictvím 256bitového šifrování AES (Advanced Encryption Standard). Šifrování úložiště je vždycky aktivní a není možné ho zakázat.

  • Můžu obnovit jednu databázi nebo několik databází na serveru?

    Obnovení jedné databáze nebo několika databází nebo tabulek se přímo nepodporuje. Můžete ale obnovit celý server na nový server a potom odstranit tabulky nebo databáze, které na novém serveru nepotřebujete.

  • Je můj server dostupný, když probíhá zálohování?

    Ano. Zálohy jsou online operace, které používají snímky. Operace vytvoření snímku trvá jenom několik sekund a nenarušuje produkční úlohy, aby se zajistila vysoká dostupnost serveru.

  • Když nastavím časové období údržby pro server, musím počítat i s oknem zálohování?

    Ne. Zálohy se aktivují interně jako součást řízené služby a nemají žádný vliv na údržbové okno.

  • Kde se ukládají moje automatizované zálohy a jak můžu spravovat jejich uchovávání?

    Instance flexibilního serveru Azure Database for PostgreSQL automaticky vytvoří zálohy serveru a uloží je do:

    • Zónově redundantní úložiště v oblastech, kde se podporuje více zón.
    • Místně redundantní úložiště v oblastech, které zatím nepodporují více zón.
    • Spárovaná oblast, pokud konfigurujete geograficky redundantní zálohování.

    Tyto záložní soubory se nedají exportovat, protože jsou uložené v účtech úložiště spravovaných Microsoftem. Zákazníci mají k obnovení těchto souborů přístup jen pro čtení, ale nemůžou je upravovat ani odstraňovat. Záložní soubory se po uplynutí doby uchovávání automaticky odstraní.

    Zálohy můžete použít pouze k obnovení serveru k určitému bodu v čase. Výchozí doba uchovávání záloh je 7 dnů. Volitelně můžete nakonfigurovat uchovávání záloh až 35 dnů.

  • Jak často se při geograficky redundantním zálohování kopíruje do spárované oblasti?

    Pokud je server nakonfigurovaný s geograficky redundantním zálohováním, data záloh se ukládají do geograficky redundantního účtu úložiště. Účet úložiště kopíruje datové soubory do spárované oblasti, když dojde k dennímu zálohování na primárním serveru. Soubory WAL se zálohují, když jsou připravené k archivaci.

    Zálohovaná data se asynchronně kopírují nepřetržitě do spárované oblasti. Při přijímání zálohovaných dat můžete očekávat až jednu hodinu zpoždění.

  • Můžu provést obnovení k určitému bodu v vzdálené oblasti?

    Ne. Data jsou obnovena na poslední dostupná zálohovaná data v odlehlém regionu.

  • Jak se zálohy provádějí na serverech s podporou vysoké dostupnosti?

    Datové svazky v instanci flexibilního serveru Azure Database for PostgreSQL se zálohují prostřednictvím přírůstkových snímků spravovaných disků z primárního serveru. Zálohování WAL se provádí buď z primárního serveru, nebo z pohotovostního serveru.

  • Jak můžu ověřit, že se zálohy provádí na mém serveru?

    Nejlepším způsobem, jak zkontrolovat zálohy, je pravidelně provádět PITR (obnovení k určitému bodu v čase) a zajistit, aby zálohy byly validní a obnovitelné. Koncoví uživatelé nemají přístup k operacím zálohování ani záložním souborům.

  • Kde se zobrazuje využití zálohování?

    Na webu Azure Portal v části Monitorování vyberte Metriky. Ve využité službě Backup Storage můžete monitorovat celkové využití zálohování.

  • Co se stane se zálohami, když odstraním server?

    Pokud odstraníte server, odstraní se také všechny zálohy, které patří k serveru, a není možné je obnovit. K ochraně prostředků serveru před náhodným odstraněním nebo neočekávanými změnami po nasazení můžou správci používat zámky správy.

  • Jak se zálohy uchovávají pro zastavené servery?

    Pro zastavené servery se neprovádí žádné nové zálohy. Všechny starší zálohy (v rámci okna uchovávání informací) se v době zastavení serveru zachovají, dokud se server nerestartuje. Potom se uchovávání záloh pro aktivní server řídí jeho oknem uchovávání informací.

  • Jak bude účtováno a fakturováno za moje zálohy?

    Azure Database for PostgreSQL poskytuje až 100 % zřízeného úložiště serveru jako úložiště záloh bez dalších poplatků. Za jakékoli další úložiště zálohování, které použijete, se účtují gigabajty za měsíc, jak je definováno v cenovém modelu.

    Možnost uchovávání záloh a redundance zálohování, kterou vyberete, spolu s transakční aktivitou na serveru přímo ovlivní celkové úložiště zálohování a fakturaci.

  • Jak se mi bude účtovat zastavený server?

    Během zastavení instance serveru se neprovedou žádné nové zálohy. Za poskytnuté úložiště a prostor pro ukládání záloh jsou vám účtovány náklady (zálohy uložené v rámci vámi specifikovaného období uchování).

    Bezplatné úložiště zálohování je omezené na velikost zřízené databáze. Všechna nadbytečná zálohovaná data se budou účtovat podle ceny zálohování.

  • Nakonfiguroval(a) jsem server s zónově redundantní vysokou dostupností. Provedete dvě zálohy a bude se mi účtovat dvakrát?

    Ne. Bez ohledu na HA nebo ne-HA servery se udržuje pouze jedna sada záložních kopií. Účtuje se vám jenom jednou.

  • Jak obnovím server?

    Azure podporuje PITR pro všechny servery. Uživatelé můžou provést obnovení do nejnovějšího bodu obnovení nebo vlastního bodu obnovení pomocí webu Azure Portal, Azure CLI a rozhraní API.

    Pokud chcete obnovit server z ručních záloh pomocí nástrojů, jako je pg_dump, můžete nejprve vytvořit instanci flexibilního serveru Azure Database for PostgreSQL a pak obnovit databáze na server pomocí pg_restore.

  • Můžu provést obnovení do jiné zóny dostupnosti ve stejné oblasti?

    Ano. Pokud tato oblast podporuje více zón dostupnosti, záloha se uloží do zónově redundantního účtu úložiště, abyste je mohli obnovit do jiné zóny.

  • Jak dlouho trvá PITR? Proč obnovení trvá tolik času?

    Operace obnovení dat ze snímku nezávisí na velikosti dat. Časování procesu obnovení, které používá protokoly (transakční aktivity k přehrání), se ale může lišit v závislosti na načasování předchozího zálohování ve vztahu k požadovanému datu a času a počtu protokolů ke zpracování. To platí pro obnovení v rámci stejné zóny nebo obnovení dat do jiné zóny.

  • Pokud obnovím server s podporou vysoké dostupnosti, je obnovený server automaticky nakonfigurovaný s vysokou dostupností?

    Ne. Server se obnoví jako instance flexibilního serveru Azure Database for PostgreSQL s jednou instancí. Po dokončení obnovení můžete volitelně nakonfigurovat server s vysokou dostupností.

  • Nakonfiguroval(a) jsem server ve virtuální síti. Můžu provést obnovení do jiné virtuální sítě?

    Ano. V době obnovení zvolte jinou virtuální síť, do které chcete provést obnovení.

  • Můžu obnovit svůj veřejný přístupový server do virtuální sítě nebo naopak?

    Ne. Azure Database for PostgreSQL v současné době nepodporuje obnovení serverů napříč veřejným a privátním přístupem.

  • Jak můžu sledovat operaci obnovení?

    V současné době neexistuje způsob, jak sledovat operaci obnovení. Protokol aktivit můžete monitorovat a zjistit, jestli operace probíhá nebo je dokončená.

Související obsah

  • Last updated on