Sdílet prostřednictvím

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

  • Článek

PLATÍ PRO: Flexibilní server 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.

Flexibilní server Azure Database for PostgreSQL automaticky provádí pravidelné zálohy vašeho serveru. Pak můžete provést obnovení k určitému bodu v čase (PITR) v zadaném období uchovávání. Celková doba obnovení a obnovení obvykle závisí na velikosti dat a množství provedeného obnovení.

Přehled služby Backup

Flexibilní server 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 flexibilní server 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 úplné zálohování a po sobě jdoucí snímky jsou rozdílové 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í cíle bodu obnovení může být až 5 minut.

možnosti redundance zálohy

Flexibilní server 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.

Flexibilní server 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,99999999999 % (12 devítek) stálost 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ého racku a jednotky. Poskytuje alespoň 99,99999999999 % (11 devítek) stálost zálohovaných objektů za rok.

    Ve výchozím nastavení je úložiště záloh pro servery se stejnou zónou vysoká dostupnost (HA) nebo konfigurace vysoké dostupnosti nastavená 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,9999999999999999 % (16 devítek) stálost zálohovaných objektů za rok.

    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 možnost redundance úložiště zálohování.

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, ze kterého je možné načíst obnovení k určitému bodu v čase pomocí dostupných záloh. Dobu uchovávání záloh můžete také považovat za okno obnovení z pohledu obnovení.

Všechny zálohy potřebné k provedení obnovení k určitému bodu v čase 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 zachovají všechna data a protokoly potřebné k obnovení a obnovení serveru za posledních 7 dnů.

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

Flexibilní server 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ždou další úložiště zálohování, které používáte, se účtují gigabajty 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í k určitému bodu v čase

Na flexibilním serveru Azure Database for PostgreSQL se provedením obnovení k určitému bodu v čase vytvoří 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 se nejprve obnoví ze zálohy snímků do umístění dat serveru. Příslušná záloha, která byla provedena dříve, než je požadovaný bod v čase, 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í 15. srpna v 10:00, obnoví se denní záloha 14. srpna. Databáze bude obnovena do 10:00 ze 15. srpna pomocí zálohy transakčního protokolu od 14. srpna 11:00 do 15. srpna 10:00.

Pokud chcete obnovit databázový server, prohlédněte si tento postup.

Důležité

Operace obnovení na flexibilním 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í úplné zálohování snímků a nevyžaduje žádné obnovení protokolů, což zrychuje. Doporučujeme vybrat časové razítko zálohování, které je větší než nejstarší bod obnovení v čase 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. Pokud chcete zabránit náhodnému odstranění serveru, použijte zámek prostředků 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í instance flexibilního serveru 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. Při obnovení tedy můžete očekávat až jednu hodinu cíle bodu obnovení. 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í rto serveru (cíl doby obnovení) závisí na faktorech, jako je velikost databáze, doba poslední zálohy databáze a doba zpracování do posledního přijatého zálohovaného dat. 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 najdete v tématu 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 vzhůru.

Když je primární oblast mimo provoz, můžete zdrojový server stále geograficky obnovit do geograficky spárované oblasti. Další informace najdete v tématu 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.

Obnovení a sítě

Obnovení k určitému bodu 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é obnovení

Pokud je zdrojový server nakonfigurovaný s veřejnou přístupovou sítí, můžete ho obnovit jenom do veřejného přístupu. Existující pravidla brány firewall na zdrojovém serveru se zkopírují na obnovený server. Privátní koncové body se nepřevezmou. Po dokončení operace obnovení zkontrolujte, jestli potřebujete upravit některá pravidla brány firewall přenášená a vytvořit jakékoli privátní koncové body, které možná budete potřebovat.

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, které uživatelům a aplikacím zprovozní a zprovozní:

  • Pokud má nový server nahradit původní server, přesměrujte klienty a klientské aplikace na nový server. Změňte název serveru připojovací řetězec tak, aby odkazovat 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 pro připojení uživatelů platí příslušná brána firewall na úrovni serveru, privátní koncové body a pravidla virtuální sítě. Ve veřejné přístupové síti se pravidla kopírují z původního serveru, ale nemusí to být ty, které se vyžadují v obnoveném prostředí. Proto je upravte podle svých požadavků. Privátní koncové body se nepřenesou. Vytvořte všechny privátní koncové body, které možná budete potřebovat na obnoveném serveru. Ve virtuální síti privátního přístupu se obnovení nezkopíruje přes žádné artefakty síťové infrastruktury ze zdroje do obnovených serverových sítí. Cokoli, co souvisí s konfigurací virtuální sítě (virtuální sítě), podsítí nebo skupin zabezpečení sítě, se musí starat o úlohu po obnovení.

  • Podle potřeby vertikálně navyšte nebo vertikálně navyš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 těchto kroků.

Zálohy na vyžádání (Preview)

Flexibilní server Azure Database for PostgreSQL automaticky generuje snímky svazků úložiště celé instance databáze, které pokrývají všechny databáze v rámci 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álohování spravuje a uchovává služba flexibilního serveru, aby splňovala požadavky na uchovávání záloh.

Další informace najdete v tématu Zálohování na vyžádání.

Omezení

Funkce zálohování na vyžádání se v současné době nepodporuje u výpočetní vrstvy serveru s možností nárazového škálování.

Známé problémy

Víme o existující chybě, která umožňuje zálohování replik na vyžádání, i když obnovení k určitému bodu v čase (PITR) v tomto kontextu není podporované. Tento problém bude vyřešen, aby se zajistilo, že zálohy na vyžádání lze provádět pouze na primárním serveru.

Dlouhodobé uchovávání (Preview)

Flexibilní serverové služby Azure Backup a Azure Database for PostgreSQL vytvořily podnikové řešení dlouhodobého zálohování pro instance flexibilních serverů 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 flexibilním serverem 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é doméně zabezpečení a selhání. 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

  • Obnovení LTR jsou v současné době k dispozici pouze jako Obnovení jako soubory pro účty úložiště s možností Obnovit jako server, která je v budoucnu naplánována.
  • 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 u geografických replik, ale dá se provést z primárních serverů.
  • Maximální podporovaná velikost databáze pro zálohy dlouhodobého uchovávání (LTR) je 4 TiB. I když se zálohy dají pokusit na serverech přesahujících 4 TiB, nejsou oficiálně podporované a úspěch záloh LTR pro tyto servery nelze zaručit.
  • Zálohy LTR je možné naplánovat každý týden, měsíčně nebo ročně. Plán denního zálohování se v současné době nepodporuje.

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?

    Flexibilní server Azure Database for PostgreSQL ve výchozím nastavení umožňuje automatizované zálohování celého serveru (zahrnující všechny vytvořené databáze) 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. Flexibilní server 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 ručně pořídit pomocí funkce zálohování na vyžádání. Logické zálohy můžete také provést pomocí nástroje PostgreSQL pg_dump. Příklady najdete v tématu Migrace flexibilní serverové 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 zálohy šifrované?

    Ano. Všechna data, zálohy a dočasné soubory 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 pro záložní okno počítat?

    Ne. Zálohy se aktivují interně jako součást spravované služby a nemají žádný vliv na časové období údržby.

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

    Flexibilní server Azure Database for PostgreSQL automaticky vytváří zálohy serveru a ukládá 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 se obnoví na poslední dostupná zálohovaná data ve vzdálené oblasti.

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

    Datové svazky na flexibilním serveru Azure Database for PostgreSQL se zálohují prostřednictvím přírůstkových snímků spravovaného disku 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 provádět pravidelné obnovení k určitému bodu v čase a zajistit, aby zálohy byly platné 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 se budou účtovat a účtovat zálohy?

    Flexibilní server 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 zřízené úložiště a úložiště záloh se vám účtují poplatky (zálohy uložené v zadaném okně uchovávání informací).

    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 vysokou dostupnost nebo servery bez vysoké dostupnosti se udržuje pouze jedna sada záložních kopií. Účtuje se vám jenom jednou.

  • Návody obnovit můj server?

    podpora Azure s 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 (aktivity transakcí k přehrání), se ale může lišit v závislosti na předchozím zálohování požadovaného data a času a počtu protokolů, které se mají zpracovat. 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 server pro obnovení 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. Flexibilní server Azure Database for PostgreSQL v současné době nepodporuje obnovení serverů napříč veřejným a privátním přístupem.

  • Návody 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