Dlouhodobé uchovávání záloh – Azure SQL Database a Azure SQL Managed Instance

Platí pro:Azure SQL DatabaseAzure SQL Managed Instance

Tento článek obsahuje koncepční přehled záloh pro dlouhodobé uchovávání (LTR) pro Azure SQL Database a Azure SQL Managed Instance. Dlouhodobé uchovávání je možné nakonfigurovat až na 10 let zálohování pro Azure SQL Database (včetně úrovně služby Hyperscale) a Azure SQL Managed Instance.

Pokud chcete začít používat funkci dlouhodobého uchovávání záloh, přečtěte si:

Důležité

Některá starší rozhraní API používaná pro operace zálohování dlouhodobého uchovávání (LTR) jsou zastaralá a už se nepodporují. Nepoužívejte starší rutiny PowerShellu, například Copy-AzSqlDatabaseLongTermRetentionBackup. Místo toho použijte podporované metody obnovení popsané v tomto článku.

Jak dlouhodobé uchovávání funguje

Mnoho aplikací má regulační, dodržování předpisů nebo jiné obchodní důvody, které vyžadují, abyste uchovávali zálohy databáze nad rámec 1–35 dnů, které poskytuje období krátkodobého uchovávání automatických záloh. Dlouhodobé uchovávání záloh (LTR) spoléhá na úplné zálohy databáze, které jsou automaticky vytvořeny službou Azure SQL. Další informace naleznete v části Automatizované zálohování v Azure SQL Database nebo Automatizované zálohování v Azure SQL Managed Instance.

Pomocí funkce LTR můžete ukládat zadané úplné zálohy služby SQL Database a SQL Managed Instance v redundantním úložišti Azure Blob Storage s konfigurovatelnými zásadami uchovávání informací o velikosti až 10 let. Zálohy LTR je pak možné obnovit jako novou databázi. Pokud je nakonfigurovaná zásada LTR, automatizované zálohy se zkopírují do různých objektů blob pro dlouhodobé úložiště, které pak můžete použít k obnovení databáze k určitému bodu v čase. Proces kopírování je úloha na pozadí, která nemá žádný vliv na výkon databázové úlohy. Zásady LTR pro každou databázi také můžou určovat, jak často se vytvářejí zálohy LTR.

Poznámka:

  • V Azure SQL Database můžete nakonfigurovat zálohy pro dlouhodobé uchovávání jako neměnné.
  • V Azure SQL Managed Instance není v současné době možné nakonfigurovat zálohování jako immutable. Zálohy LTR se nedají upravit, ale můžete je odstranit prostřednictvím portálu Azure, Azure CLI, PowerShellu nebo rozhraní REST API. Jako alternativní řešení v Azure SQL Managed Instance můžete pořídit zálohy databáze typu copy-only a uchovat je ve svém vlastním účtu Azure Storage jako neměnný soubor.

Pokud chcete povolit LTR, můžete definovat zásadu pomocí kombinace čtyř parametrů: týdenní uchovávání záloh (W), měsíční uchovávání záloh (M), roční uchovávání záloh (Y) a týdne v roce (WeekOfYear). Pokud zadáte W, každý týden se jedna záloha zkopíruje do dlouhodobého úložiště. Pokud zadáte M, první záloha každého měsíce se zkopíruje do dlouhodobého úložiště. Pokud zadáte hodnotu Y, zkopíruje se do dlouhodobého úložiště jedna záloha za týden určená parametrem WeekOfYear. Pokud je zadaný WeekOfYear v minulosti, když je zásada nakonfigurovaná, vytvoří se první záloha LTR v následujícím roce. Každá záloha se uchovává v dlouhodobém úložišti podle parametrů zásad nakonfigurovaných při vytvoření zálohy LTR.

Změny zásad LTR se vztahují pouze na budoucí zálohy. Pokud například upravíte týdenní uchovávání záloh (W), měsíční uchovávání záloh (M) nebo roční uchovávání záloh (Y), nové nastavení uchovávání se vztahuje pouze na nové zálohy. Uchovávání existujících záloh se nezmění. Zásady LTR je možné nakonfigurovat pro každou databázi v Azure SQL Database a Azure SQL Managed Instance. Pokud máte v úmyslu odstranit staré zálohy LTR před vypršením jejich doby uchovávání, můžete zálohy odstranit ručně.

Poznámka:

Když v Azure SQL Database i Azure SQL Managed Instance povolíte zásadu LTR poprvé pro databázi, zkopíruje se nejnovější úplná záloha z obnovení k určitému bodu v čase (PITR) do dlouhodobého úložiště.

Příklady zásad LTR:

  • W=0, M=0, Y=5, WeekOfYear=3

    Třetí úplná záloha každého roku se uchovává po dobu pěti let.

  • W=0, M=3, Y=0

    První úplná záloha každého měsíce se uchovává po dobu tří měsíců.

  • W=12, M=0, Y=0

    Každé týdenní úplné zálohování se uchovává po dobu 12 týdnů.

  • W=6, M=12, Y=10, WeekOfYear=20

    Každé týdenní úplné zálohování se uchovává po dobu šesti týdnů. S výjimkou prvního úplného zálohování každého měsíce, který se uchovává po dobu 12 měsíců. S výjimkou úplného zálohování pořízeného v 20. týdnu roku, který se uchovává po dobu 10 let.

Následující tabulka ukazuje četnost a vypršení platnosti dlouhodobých záloh pro následující zásady:

W=12 weeks (84 dní), M=12 months (365 dní), Y=10 years (3 650 dní), WeekOfYear=20 (týden po 13. květnu)

Následující data jsou v ISO 8601 (YYYY-MM-DD).

Zálohování PITR do LTR Vypršení platnosti W Vypršení platnosti M Vypršení platnosti Y
2018-03-07 2019-03-02
2018-03-14 2018-06-06
2018-03-21 2018-06-13
2018-03-28 2018-06-20
04. 04. 2018 2019-03-30
2018-04-11 2018-07-04
2018-04-18 2018-07-11
2018-04-25 2018-07-18
2018-05-02 2019-04-27
2018-05-09 1. 8. 2018
2018-05-16 13.05.2028
2018-05-23 2018-08-15
2018-05-30 2018-08-22
2018-06-06 1. 6. 2019
2018-06-13 2018-09-05
2018-06-20 2018-09-12
2018-06-27 2018-09-19
2018-07-04 2019-06-29
2018-07-11 2018-10-03
2018-07-18 2018-10-10
2018-07-25 2018-10-17
1. 8. 2018 2019-07-27
2018-08-08 2018-10-31
2018-08-15 2018-11-07
2018-08-22 2018-11-14
2018-08-29 2018-11-21

Pokud upravíte tuto zásadu a nastavíte (žádné týdenní zálohy), týdenní zálohy se zachovají W=0 , dokud nevyprší jejich platnost, a služba si zachová jenom měsíční a roční zálohy. Na základě zásad LTR nejsou ukládány žádné budoucí týdenní zálohy. Velikost úložiště potřebná k zachování těchto záloh se odpovídajícím způsobem snižuje.

Důležité

Načasování jednotlivých záloh LTR je určováno společností Microsoft. Ručně nemůžete vytvořit zálohování LTR, ani řídit časování vytvoření zálohy. Po konfiguraci zásad LTR může trvat až sedm dní, než se první záloha LTR zobrazí v seznamu dostupných záloh.

Pokud odstraníte logický server nebo spravovanou instanci SQL, odstraní se také všechny databáze na tomto serveru nebo spravované instanci. Odstraněný logický server ani spravovanou instanci SQL nemůžete obnovit. Pokud jste však nakonfigurovali LTR pro databázi, zálohy LTR se neodstraní a je možné je použít k obnovení databází na jiný server nebo spravovanou instanci ve stejném předplatném k určitému bodu v čase při vytvoření zálohy LTR.

Podobně pokud odstraníte databázi, zálohy LTR se neodstraní a zachovají se po nakonfigurovanou dobu uchovávání informací. Tyto zálohy je možné obnovit na stejný server nebo jiný server ve stejném předplatném.

Geografická replikace a dlouhodobé uchovávání záloh

Pokud jako řešení provozní kontinuity používáte aktivní geografickou replikaci nebo skupiny pro obnovení po selhání, připravte se na případné selhání a nakonfigurujte stejnou politiku LTR na sekundární databázi nebo instanci, jakou máte na primární. Vaše náklady na úložiště LTR se nezvyšují, protože zálohy se negenerují z sekundárních úložišť. Zálohy se vytvoří až poté, co se sekundární stane primárním, pro zajištění nepřerušovaného generování záloh LTR během aktivace mechanismu převzetí služeb při selhání, kdy se primární region přesune do sekundární oblasti.

Když se původní primární databáze obnoví z výpadku, který způsobil přepnutí, stane se novou sekundární databází. Vytváření zálohy proto nebude pokračovat na novém sekundárním serveru a stávající zásady LTR nevstoupí v platnost, dokud se opět nestane primárním.

Síťový bezpečnostní perimetr a obnova LTR (náhled)

Poznámka:

Síťový bezpečnostní perimetr (náhled) platí pouze pro Azure SQL Database. Azure SQL Managed Instance není onboardovaný zdroj, takže tato část se na něj nevztahuje. Pro aktuální seznam viz Připojené prostředky privátního propojení.

LTR obnova je operace řízená platformou, která obnovuje databázi z dlouhodobé zálohy na cílový logický server. Pokud kterýkoli z obou logických serverů patří do perimetru, obnova je podřízena pravidlům přístupu na perimetru.

Služba kontroluje odchozí přístup na zdrojovém serveru, pokud daný server ještě existuje, a příchozí přístup na cílovém serveru. Pokud byl zdrojový logický server smazán, může běžet pouze příchozí kontrola na cílové straně.

Podporované konfigurace

LTR obnovení funguje jak v přechodném, tak v nuceném režimu. V přechodovém režimu obnovení proběhne úspěšně bez přístupových pravidel. Nakonfigurujte pravidla před přepnutím do vynuceného režimu.

V režimu vynucení jsou podporovány tyto konfigurace:

Zdrojový server Cílový server Jsou vyžadována pravidla přístupu
Na obvodu V rámci stejné oblasti None. Přístup mezi zdroji ve stejném perimetru je vždy povolen.
V perimetru V jiné oblasti Odchozí na zdroji, příchozí na cíli.
V perimetru Mimo perimetr Odchozí na zdroji.
Mimo perimetr V perimetru Příchozí na cíl.
Odstraněno Na obvodu Míří na cíl.
Není v perimetru Mimo perimetr None.

Obnova LTR nevyžaduje spravovanou identitu.

Konfigurace přístupových pravidel pro obnovení LTR

  1. Přiřaďte každý logický server k jeho perimetru , pokud jste to ještě neudělali. Tento krok přeskočte u serveru, který se nachází mimo perimetr, nebo u smazaného zdrojového serveru.
  2. Pokud je zdrojový server v perimetru a cílový server není ve stejném perimetru, přidejte do zdrojového profilu odchozí pravidlo s Typem cíle nastaveným na FQDN a plně kvalifikovaným názvem domény cílového serveru.
  3. Pokud je cílový server v perimetru a zdrojový server není ve stejném perimetru, přidejte příchozí pravidlo v profilu cílového serveru. Požadavek na obnovení pochází z infrastruktury správy Azure SQL, nikoli ze zdrojového serveru. V pravidle povolte jeden z těchto zdrojů:
    • ID předplatného zdrojového serveru (doporučeno).
    • Servisní kód (doporučeno).
    • Rozsahy IP adres. Pro veřejný cloud Azure IP Ranges and Service Tags - Public Cloud uvádí jednotlivé service tagy a jejich rozsahy IP adres. Název servisního štítku je SqlManagement. Microsoft tyto rozsahy nezveřejňuje podle regionů, takže je povolte všechny.
  4. Servery jsou stále v přechodovém režimu, proveďte obnovení a zkontrolujte diagnostické protokoly perimetru zabezpečení sítě kvůli nečekaným zamítnutím.
  5. Přepněte do vynuceného režimu až poté, co všechny diagnostické kontroly projdou.

Omezení a rozdíly v chování

  • Nemůžete smazat logický server, který má zálohy LTR, když je jeho perimetrová asociace v režimu vynucování. Neměnné zálohy LTR také blokují mazání, ať už je server v zabezpečeném perimetru, nebo ne. Pro více informací viz Neměnné dlouhodobé zálohy a mazání logických serverů.
  • Pokud smažete zdrojový server, zatímco je jeho asociace v přechodovém režimu, služba už nemůže číst metadata perimetru tohoto serveru, takže může ověřit pouze cílovou stranu obnovy. Tuto mezeru zohledněte, pokud spoléháte na validaci na straně zdroje jako kontrolu.
  • V přechodovém režimu obnovení uspěje i tehdy, když chybí požadovaná pravidla. V režimu vynucení je stejné obnovení blokováno.

Konfigurace dlouhodobého uchovávání záloh

Důležité

Některá starší rozhraní API používaná pro operace zálohování dlouhodobého uchovávání (LTR) jsou zastaralá a už se nepodporují. Nepoužívejte starší rutiny PowerShellu, například Copy-AzSqlDatabaseLongTermRetentionBackup. Místo toho použijte podporované metody obnovení popsané v tomto článku.

Dlouhodobé uchovávání záloh můžete nakonfigurovat pomocí portálu Azure a PowerShellu pro Azure SQL Database a Azure SQL Managed Instance. Pokud chcete obnovit databázi z úložiště LTR, můžete vybrat konkrétní zálohu na základě časového razítka. Databázi je možné obnovit na libovolný existující server nebo spravovanou instanci ve stejném předplatném jako původní databáze. Úplný seznam možností obnovení, omezení a funkcí najdete v tématu Restore schopností a funkcí v Azure SQL Managed Instance.

Když se žádost o obnovení zahájí v posledních sedmi dnech doby uchovávání LTR, záloha LTR se odstraní až po dokončení operace obnovení, a to i v případě, že vypršela doba uchovávání.

Poznámka:

Obnovení databází mezi úrovní služby Hyperscale a dalšími úrovněmi služby Azure SQL Database se v současné době nepodporuje.

V Azure SQL Managed Instance můžete naplánovat zálohování databáze pomocí pouze kopie pomocí úloh SQL Agenta a přesunout je do vlastního účtu úložiště jako alternativu k:

  • Uchovávejte zálohy po dobu delší než 10 let.
  • Uchovávejte denní kopie databází po dobu delší než 35 dnů.
  • Ukládání záloh databáze v neměnném úložišti

Návod

Pokud ke splnění požadavků na dodržování předpisů nebo jiných důležitých požadavků používáte zálohy LTR, zvažte provedení pravidelných postupů obnovení, abyste ověřili, že zálohy LTR je možné obnovit a že obnovení vede k očekávanému stavu databáze.

Poznámka:

Dlouhodobé zálohy závisejí na úspěšných úplných zálohách. Zaplněný protokol transakcí může zabránit plánovanému úplnému zálohování, což může zabránit vytvoření zálohy LTR. Zachycení dat změn (CDC) a další funkce, které zabraňují zkrácení transakčních logů, mohou zpozdit zálohu LTR, která je úspěšná až po úspěšné úplné zálohě. Vyhodnoťte funkce, které zabraňují zkrácení transakčních logů, a zvažte jejich dočasné vypnutí, dokud se zálohovací operace neobnoví.

Další krok

Spravovat dlouhodobou retenci záloh Azure SQL Database

Řízení Azure SQL Managed Instance dlouhodobého uchování záloh

Související obsah

Vzhledem k tomu, že zálohy databází chrání data před náhodným poškozením nebo odstraněním, jsou důležitou součástí jakékoli strategie provozní kontinuity a zotavení po havárii.

  • Poslední aktualizace v