Selhání a zotavení po havárii pro aplikace AzureFailure and disaster recovery for Azure applications

Zotavení po havárii je proces obnovení aplikace funkcí v důsledku katastrofické ztrátě.Disaster recovery is the process of restoring application functionality in the wake of a catastrophic loss.

Tolerance pro omezenou funkčnost při havárii je obchodní rozhodnutí, která se mění z jedné aplikace na další.Your tolerance for reduced functionality during a disaster is a business decision that varies from one application to the next. To může být přijatelný pro některé aplikace nedostupnost zcela nebo částečně dalo se sníženou funkčností nebo zpoždění zpracování pro určitou dobu.It might be acceptable for some applications to be completely unavailable or to be partially available with reduced functionality or delayed processing for a period of time. U ostatních aplikací nepřijatelné jakékoli omezenou funkčnost.For other applications, any reduced functionality is unacceptable.

Plán zotavení po haváriiDisaster recovery plan

Začněte tím, že vytvoření plánu obnovení.Start by creating a recovery plan. Plán se považuje za dokončené, jakmile byl plně testovaný.The plan is considered complete after it has been fully tested. Zahrnují lidi, procesy a aplikace, které jsou potřebné k obnovení funkce v rámci smlouvu o úrovni služeb (SLA) pro vaše zákazníky, které jste definovali.Include the people, processes, and applications needed to restore functionality within the service-level agreement (SLA) you've defined for your customers.

Vezměte v úvahu následující návrhy při vytváření a testování vašeho plánu zotavení po havárii:Consider the following suggestions when creating and testing your disaster recovery plan:

  • V plánu zahrnuje proces pro kontaktování podpory a pro eskalaci problémů.In your plan, include the process for contacting support and for escalating issues. Tyto informace pomohou výpadky dlouhotrvající práci, proces obnovení poprvé.This information will help to avoid prolonged downtime as you work out the recovery process for the first time.
  • Vyhodnoťte obchodní dopad selhání aplikace.Evaluate the business impact of application failures.
  • Zvolte možnost obnovení mezi různými oblastmi architektura pro klíčové aplikace.Choose a cross-region recovery architecture for mission-critical applications.
  • Identifikujte konkrétní Vlastník plánu zotavení po havárii, včetně služby automation a testování.Identify a specific owner of the disaster recovery plan, including automation and testing.
  • Zdokumentujte procesu, zejména jakékoli ruční kroky.Document the process, especially any manual steps.
  • Automatizujte proces co největší míře.Automate the process as much as possible.
  • Pravidelně strategie zálohování pro referenční a transakčních dat a obnovení záloh testu.Establish a backup strategy for all reference and transactional data, and test backup restoration regularly.
  • Nastavení upozornění pro zásobník služby Azure využité vaší aplikací.Set up alerts for the stack of the Azure services consumed by your application.
  • Trénování provozní personál ke spuštění plánu.Train operations staff to execute the plan.
  • Provádění simulací po havárii regulárních ověřilo a zlepšilo plánu.Perform regular disaster simulations to validate and improve the plan.

Pokud používáte Azure Site Recovery replikovat virtuální počítače (VM), vytvoření plánu obnovení plně automatizované převzít služby při selhání celé aplikace.If you're using Azure Site Recovery to replicate virtual machines (VMs), create a fully automated recovery plan to fail over the entire application.

Ruční odpovědiManual responses

I když služba automation je ideální, některé strategie zotavení po havárii vyžadují ruční odpovědi.Although automation is ideal, some strategies for disaster recovery require manual responses.

VýstrahyAlerts

Monitorujte vaší aplikace a sledujte varovné signály, které by mohly vyžadovat proaktivní zásah.Monitor your application for warning signs that may require proactive intervention. Například pokud Azure SQL Database nebo Azure Cosmos DB často omezuje propustnost vaší aplikace, může být potřeba zvýšit kapacitu vaší databáze nebo optimalizovat dotazy.For example, if Azure SQL Database or Azure Cosmos DB consistently throttles your application, you might need to increase your database capacity or optimize your queries. I v případě, že aplikace může omezení chyby zpracovat transparentně, vaše telemetrie měla vygenerovat výstrahu tak, aby vám poradí.Even though the application might handle the throttling errors transparently, your telemetry should still raise an alert so that you can follow up.

Limity a kvóty prahové hodnoty doporučujeme Konfigurace upozornění na metriky a diagnostické protokoly prostředků Azure.For service limits and quota thresholds, we recommend configuring alerts on Azure resources metrics and diagnostics logs. Pokud je to možné, nastavte si upozornění na metriky, které jsou nižší latenci než diagnostické protokoly.When possible, set up alerts on metrics, which are lower latency than diagnostics logs.

Prostřednictvím Resource Health, Azure poskytuje několik integrovaných stavu kontroly stavu, které vám může pomoci diagnostikovat problémy omezování služby Azure.Through Resource Health, Azure provides some built-in health status checks that can help you diagnose Azure service throttling issues.

Převzetí služeb při selháníFailover

Nakonfigurujte strategii zotavení po havárii pro každou aplikaci Azure a službami Azure.Configure a disaster recovery strategy for each Azure application and its Azure services. Strategie nasazení přijatelné podpory obnovení po havárii může lišit podle smlouvy o úrovni služeb, vyžaduje se pro všechny součásti každou aplikaci.Acceptable deployment strategies to support disaster recovery may vary based on the SLAs required for all components of each application.  

Azure nabízí různé funkce v rámci řadou služeb Azure umožňuje ruční převzetí služeb při selhání, jako například redis cache geo repliky, nebo pro automatické převzetí služeb při selhání, SQL-automatické převzetí služeb při selhání skupiny.Azure provides different features within many Azure services to allow for manual failover, such as redis cache geo-replicas, or for automated failover, such as SQL auto-failover groups. Příklad:For example:

  • Pro aplikace, která primárně využívá virtuální počítače můžete použít Azure Site Recovery pro webové a logické vrstvy.For an application that mainly uses virtual machines, you can use Azure Site Recovery for the web and logic tiers. Další informace najdete v tématu architektury pro zotavení po havárii Azure do Azure.For more information, see Azure to Azure disaster recovery architecture. SQL Server na virtuálních počítačích, použít skupin dostupnosti AlwaysOn SQL serveru.For SQL Server on VMs, use SQL Server Always On availability groups.
  • Pro aplikace, která používá službu App Service a Azure SQL Database můžete použít menší plán služby App Service úrovně nakonfigurované v sekundární oblasti, která bude automaticky škálovat, když dojde k selhání.For an application that uses App Service and Azure SQL Database, you can use a smaller tier App Service plan configured in the secondary region, which autoscales when a failover occurs. Použití skupin převzetí služeb při selhání pro databázovou vrstvu.Use failover groups for the database tier.

V obou scénářích Azure Traffic Manager profil poskytuje automatické převzetí služeb při selhání mezi oblastmi.In either scenario, an Azure Traffic Manager profile provides for the automated failover across regions. Nástroje pro vyrovnávání zatížení nebo brány application Gateway by měl být nastavit v sekundární oblasti pro podporu rychlejší dostupnost na převzetí služeb při selhání.Load balancers or application gateways should be set up in the secondary region to support faster availability on failover.

Testování provozní připravenostiOperational readiness testing

Proveďte test provozní připravenosti pro převzetí služeb při selhání do sekundární oblasti a navrácení služeb po obnovení do primární oblasti.Perform an operational readiness test for failover to the secondary region and for failback to the primary region. Řada služeb Azure podporuje postupy zotavení po havárii s využitím ručního převzetí služeb při selhání nebo testovacího převzetí služeb při selhání.Many Azure services support manual failover or test failover for disaster recovery drills. Alternativně můžete simulovat výpadku vypnutí nebo odstranění služby Azure.Alternatively, you can simulate an outage by shutting down or removing Azure services.

Aplikace se nezdařiloApplication failure

Selhání aplikace jsou obnovitelné nebo neobnovitelné.Application failures are either recoverable or nonrecoverable. Můžete zmírnit zotavitelné chyby, ale neobnovitelné chyby přinese dolů aplikaci.You can mitigate a recoverable error, but nonrecoverable errors will bring down the application.

  • Některé chyby lze řešit transparentně automaticky zpracování chyb a alternativní akcí.Some failures can be addressed transparently by handling faults automatically and taking alternate actions. Například Traffic Manageru automaticky zpracovává chyby, které jsou výsledkem základní hardware nebo operační systém software v hostiteli virtuálního počítače.For example, Traffic Manager automatically handles failures that result from the underlying hardware or operating system software in the host virtual machine.
  • S chybami může aplikace dál zpracovává požadavky uživatelů s omezenou funkčností.With some errors, the application can continue handling user requests with reduced functionality.
  • Závažnější přerušení služeb může vykreslit aplikace není k dispozici.More severe service disruptions might render the application unavailable.

Dobře navržené systému odděluje zodpovědnosti na úrovni služby — v době návrhu a za běhu.A well-designed system separates responsibilities at the service level — at design time and at runtime. Toto oddělení zabraňuje přerušení závislé služby z Probíhá ukončování celé aplikace.This separation prevents a dependent service disruption from bringing down the entire application. Představte si třeba webovou aplikaci obchodování s následující moduly:For example, consider a web commerce application with the following modules:

PŘIDAT ODKAZ NA OBRÁZEK

Pokud databáze k hostování objednávky ocitne mimo provoz, Order Processing služba nemůže zpracovat prodejní transakce.If the database for hosting orders goes down, the Order Processing service can't process sales transactions. V závislosti na architektuře může být nemožné služby pořadí odesílání a zpracování objednávek pokračujte.Depending on the architecture, it might be impossible for the Order Submission and Order Processing services to continue. Pokud data produktu uložená v jiném umístění, katalog produktů je však stále k dispozici, i když jiné části aplikace možná nebude k dispozici.However, if product data is stored in a different location, the Product Catalog is still available, even though other parts of the application might be unavailable.

To je na vás a určit, jak aplikace bude informovat uživatele o žádné dočasné problémy s odpovídající upozornění do systému sestavení.It's up to you to determine how the application will inform users of any temporary problems and to build appropriate notifications into the system. V předchozím příkladu může aplikaci umožnit pro zobrazení produktů a pro jejich přidání do nákupního košíku.In the previous example, the application might allow for viewing products and for adding them to a shopping cart. Ale když zákazník se pokusí provést nákup, aplikace byste je upozornit, že funkce pro řazení je dočasně nedostupná.However, when the customer attempts to make a purchase, the application should notify them that the ordering functionality is temporarily unavailable. I když není ideální pro zákazníka, tento přístup brání výpadku služby celou aplikaci.Although not ideal for the customer, this approach prevents an application-wide service disruption.

Poškození dat a obnoveníData corruption and restoration

Pokud se úložiště dat nezdaří, mohou existovat nekonzistenci dat. když ji opět k dispozici, zejména v případě, že se data replikují.If a data store fails, there might be data inconsistencies when it becomes available again, especially if the data was replicated. Principy plánovaná doba obnovení (RTO) a bod obnovení cíl (RPO) ukládá replikovaná data vám mohou pomoci při předpovědět rozsah datových ztrát.Understanding the recovery time objective (RTO) and recovery point objective (RPO) of replicated data stores can help you predict the amount of data loss.

Informace o tom, zda je spuštěná převzetí služeb při selhání mezi zónami, ručně nebo microsoftem, ověření podmínek SLA služby Azure.To understand whether the cross-regional failover is started manually or by Microsoft, review the Azure service SLAs. U služeb se žádné smlouvy o úrovni služeb pro převzetí služeb při selhání mezi zónami Microsoft obvykle určuje, kdy se má převzetí služeb při selhání a obnovení dat v primární oblasti obvykle upřednostňuje.For services with no SLAs for cross-regional failover, Microsoft typically decides when to fail over and usually prioritizes recovery of data in the primary region. Pokud data v primární oblasti se bude považovat za Neopravitelná, Microsoft převezme služby při selhání do sekundární oblasti.If data in the primary region is deemed unrecoverable, Microsoft fails over to the secondary region.

Obnovení dat ze zálohyRestoring data from backups

Zálohy zabránit ztráty z důvodu náhodnému odstranění nebo poškození dat v součásti aplikace.Backups protect you from losing a component of the application because of accidental deletion or data corruption. Budou udržovat funkční verzi součásti z dřívější čas, který můžete použít k obnovení.They preserve a functional version of the component from an earlier time, which you can use to restore it.

Strategie zotavení po havárii nejsou náhradou za zálohování, ale pravidelné zálohování dat aplikace podporovat některé scénáře zotavení po havárii.Disaster recovery strategies are not a replacement for backups, but regular backups of application data support some disaster recovery scenarios. Vaše volby úložiště pro zálohování by měl vycházet strategii zotavení po havárii.Your backup storage choices should be based on your disaster recovery strategy.

Určuje frekvenci spouštění procesu zálohování váš cíl bodu obnovení.The frequency of running the backup process determines your RPO. Například pokud provádíte zálohování každou hodinu a dojde k havárii dvou minut před zálohováním, ztratíte 58 minut data.For example, if you perform hourly backups and a disaster occurs two minutes before the backup, you will lose 58 minutes of data. By měl obsahovat vašeho plánu zotavení po havárii, jak je vyřešit nedošlo ke ztrátě dat.Your disaster recovery plan should include how you will address lost data.

Je běžné pro data do jednoho úložiště dat do referenčních dat v jiném úložišti.It's common for data in one data store to reference data in another store. Představte si třeba databázi SQL s sloupec, který odkazuje na objekt blob ve službě Azure Storage.For example, consider a SQL Database with a column that links to a blob in Azure Storage. Pokud zálohování nedojde současně, databáze může být ukazatel na objekt blob, která neměli zazálohovaná před selháním.If backups don't happen simultaneously, the database might have a pointer to a blob that wasn't backed up before the failure. Plán zotavení po havárii nebo aplikace musí implementovat procesů pro zpracování této nekonzistence po obnovení.The application or the disaster recovery plan must implement processes to handle this inconsistency after a recovery.

Poznámka

V některých scénářích, jako je virtuální počítače zálohované pomocí Azure Backup, můžete obnovit pouze ze zálohy ve stejné oblasti.In some scenarios, such as that of VMs backed up using Azure Backup, you can restore only from a backup in the same region. Jiné službě Azure services, jako například mezipaměti Azure Redis, poskytují geograficky replikovaných záloh, které můžete použít k obnovení služeb napříč oblastmi.Other Azure services, such as Azure Cache for Redis, provide geo-replicated backups, which you can use to restore services across regions.

Azure Storage a Azure SQL DatabaseAzure Storage and Azure SQL Database

Azure automaticky ukládá data služby Azure Storage a SQL Database třikrát v rámci různých domén selhání ve stejné oblasti.Azure automatically stores Azure Storage and SQL Database data three times within different fault domains in the same region. Pokud používáte geografickou replikaci, jsou data uložená dalších třech místech v jiné oblasti.If you use geo-replication, the data is stored three additional times in a different region. Ale pokud data je poškozený nebo odstraněný v primární kopii (třeba kvůli chybě uživatele), změny se replikují do ostatních kopie.However, if the data is corrupted or deleted in the primary copy (for example, because of user error), the changes replicate to the other copies.

Máte dvě možnosti pro správu možnému poškození dat nebo odstranění:You have two options for managing potential data corruption or deletion:

  • Vytvořte vlastní strategii zálohování.Create a custom backup strategy. Zálohy, které můžete ukládat v Azure nebo místně, v závislosti na vašich obchodních požadavcích a zásad správného řízení předpisy.You can store your backups in Azure or on-premises, depending on your business requirements and governance regulations.
  • Použít možnost obnovení k určitému bodu v čase k obnovení databáze SQL.Use the point-in-time restore option to recover a SQL Database.

Obnovení služby Azure StorageAzure Storage recovery

Můžete vyvíjet vlastní proces zálohování pro službu Azure Storage nebo použijte některou z mnoha zálohovacích nástrojů třetích stran.You can develop a custom backup process for Azure Storage or use one of many third-party backup tools.

Služba Azure Storage poskytuje odolnost dat prostřednictvím automatizovaných replik, ale nebude znemožnit kód aplikace nebo uživatele došlo k poškození dat.Azure Storage provides data resiliency through automated replicas, but it doesn't prevent application code or users from corrupting data. Zachovat data věrnost po chybě aplikaci nebo uživatele vyžaduje pokročilejších technik, jako je kopírování dat do sekundárního úložiště pomocí protokolu auditu.Maintaining data fidelity after application or user error requires more advanced techniques, such as copying the data to a secondary storage location with an audit log. Máte několik možností:You have several options:

  • Objekty BLOB bloku.Block blobs. Vytvoření snímku bodu v čase jednotlivých objektů blob bloku.Create a point-in-time snapshot of each block blob. U jednotlivých snímků, se vám účtovat pouze úložiště vyžaduje k ukládání rozdílů v rámci objektu blob od předchozí stav snímku.For each snapshot, you are charged only for the storage required to store the differences within the blob since the previous snapshot state. Snímky jsou závislé na původní objekt blob, takže doporučujeme zkopírovat do jiného objektu blob nebo dokonce i do jiného účtu úložiště.The snapshots are dependent on the original blob, so we recommend copying to another blob or even to another storage account. Tento přístup zajišťuje, že záložní data jsou chráněna před náhodným odstraněním.This approach ensures that backup data is protected against accidental deletion. Použití AzCopy nebo prostředí Azure PowerShell zkopírovat do jiného účtu úložiště objektů BLOB.Use AzCopy or Azure PowerShell to copy the blobs to another storage account.

    Další informace najdete v tématu vytvoření snímku objektu Blob.For more information, see Creating a Snapshot of a Blob.

  • Služba soubory Azure.Azure Files. Použití sdílet snímky, AzCopy nebo prostředí PowerShell pro kopírování souborů do jiného účtu úložiště.Use share snapshots, AzCopy, or PowerShell to copy your files to another storage account.

  • Azure Table storage.Azure Table storage. Pomocí AzCopy můžete exportovat data tabulky do jiného účtu úložiště v jiné oblasti.Use AzCopy to export the table data into another storage account in another region.

Obnovení databáze SQLSQL Database recovery

Chcete-li chránit vaši firmu před ztrátou dat, SQL Database automaticky provádí kombinaci zálohování úplné databáze každý týden, rozdílovými zálohami prováděnými každou hodinu a transakce zálohu protokolu každých 5 až 10 minut.To protect your business from data loss, SQL Database automatically performs a combination of full database backups weekly, differential database backups hourly, and transaction log backups every 5 to 10 minutes. U úrovní Basic, Standard a Premium SQL Database pomocí bodu v čase obnovení k obnovení databáze na dřívější čas.For the Basic, Standard, and Premium SQL Database tiers, use point-in-time restore to restore a database to an earlier time. Zobrazit další informace v následujících článcích:See the following articles for more information:

Další možností je použít aktivní geografickou replikaci pro SQL Database, která automaticky replikuje do sekundární databáze ve stejné nebo jiné oblasti Azure změny databáze.Another option is to use active geo-replication for SQL Database, which automatically replicates database changes to secondary databases in the same or different Azure region. Další informace najdete v tématu vytváření a používání aktivní geografické replikace.For more information, see Creating and using active geo-replication.

Můžete také použít více Ruční postup zálohování a obnovení:You can also use a more manual approach for backup and restore:

  • Použití kopie databáze příkazu vytvořit záložní kopii databáze s transakční konzistence.Use the DATABASE COPY command to create a backup copy of the database with transactional consistency.
  • Použití Azure SQL Database importu/exportu služby, která podporuje export databáze do souborů BACPAC (komprimovaný soubory obsahující schéma databáze a přidružená data), které jsou uloženy v úložišti objektů Blob v Azure.Use the Azure SQL Database Import/Export Service, which supports exporting databases to BACPAC files (compressed files containing your database schema and associated data) that are stored in Azure Blob storage. K ochraně proti přerušení služby na úrovni celé oblasti, zkopírujte soubory souboru BACPAC do alternativní oblast.To protect against a region-wide service disruption, copy the BACPAC files to an alternate region.

SQL Server na virtuálních počítačíchSQL Server on VMs

Pro SQL Server běžící na virtuálních počítačích, máte dvě možnosti: tradiční zálohy a přesouvání protokolu.For SQL Server running on VMs, you have two options: traditional backups and log shipping.

  • Tradiční záloh můžete obnovení k určitému bodu v čase, ale proces obnovení je pomalé.With traditional backups, you can restore to a specific point in time, but the recovery process is slow. Obnovení záloh tradiční vyžaduje začínat první úplná záloha a pak použít všechny přírůstkové zálohy.Restoring traditional backups requires that you start with an initial full backup and then apply any incremental backups.
  • Můžete nakonfigurovat protokol přenosů relaci ke zpoždění obnovení zálohy protokolu.You can configure a log shipping session to delay the restore of log backups. To poskytuje okno zotavení z chyb, v primární replice.This provides a window to recover from errors made on the primary replica.

Azure Database for MySQL a Azure Database for PostgreSQLAzure Database for MySQL and Azure Database for PostgreSQL

V Azure Database for MySQL a Azure Database for PostgreSQL databázová služba automaticky vytvoří zálohu každých pět minut.In Azure Database for MySQL and Azure Database for PostgreSQL, the database service automatically makes a backup every five minutes. Tyto automatizované zálohy lze použít k obnovení serveru a jeho databázím z dřívějšího bodu v čase na nový server.You can use these automated backups to restore the server and its databases from an earlier point in time to a new server. Další informace naleznete v tématu:For more information, see:

Azure Cosmos DBAzure Cosmos DB

Cosmos DB automaticky vytvoří zálohu v pravidelných intervalech.Cosmos DB automatically makes a backup at regular intervals. Zálohy jsou uloženy odděleně v jiné službě úložiště a jsou globálně replikovat k ochraně před katastrofami místní.Backups are stored separately in another storage service and are replicated globally to protect against regional disasters. Pokud omylem odstraníte databázi nebo kolekci, můžete lístek podpory nebo zavolat podporu Azure o obnovení dat z posledního automatického zálohování.If you accidentally delete your database or collection, you can file a support ticket or call Azure support to restore the data from the last automatic backup. Další informace najdete v tématu Online zálohování a obnovení na vyžádání ve službě Azure Cosmos DB.For more information, see Online backup and on-demand restore in Azure Cosmos DB.

Azure Virtual MachinesAzure Virtual Machines

K ochraně virtuálních počítačů Azure z chyb aplikace nebo nechtěnému odstranění, použijte Azure Backup.To protect Azure Virtual Machines from application errors or accidental deletion, use Azure Backup. Vytvořené zálohy jsou konzistentní vzhledem k aplikacím na několik disků virtuálního počítače.The created backups are consistent across multiple VM disks. Kromě toho Azure Backup vault se dají replikovat mezi oblastmi na podporu obnovení z místního výpadku.In addition, the Azure Backup vault can be replicated across regions to support recovery from a regional loss.

Výpadek sítěNetwork outage

Když budou pro části sítě Azure, nemusí být mít přístup k vaší aplikace nebo data.When parts of the Azure network are inaccessible, you might not be able to access your application or data. V takovém případě doporučujeme navrhování strategie zotavení po havárii se sníženou funkčností spouštět většinu aplikací.In this situation, we recommend designing the disaster recovery strategy to run most applications with reduced functionality.

Pokud snižování funkce není možné, jsou zbývající možnosti výpadky aplikací nebo převzetí služeb při selhání na alternativní oblast.If reducing functionality isn't an option, the remaining options are application downtime or failover to an alternate region.

Ve scénáři omezenou funkčnost:In a reduced functionality scenario:

  • Pokud vaše aplikace nemůže přistupovat k jeho data kvůli výpadku síť Azure, je možné spouštět místně pomocí funkce nižší aplikace s použitím dat uložených v mezipaměti.If your application can't access its data because of an Azure network outage, you might be able to run locally with reduced application functionality by using cached data.
  • Je možné k ukládání dat do alternativního umístění, dokud připojení se obnoví.You might be able to store data in an alternate location until connectivity is restored.

Chyba závislé službyDependent service failure

Pro každé závislé služby je třeba porozumět důsledkům přerušení služeb a způsobu, jakým bude aplikace reagovat.For each dependent service, you should understand the implications of a service disruption and the way that the application will respond. Mnoho služeb zahrnují funkce, které podporují odolnost a dostupnost, takže nezávisle na sobě vyhodnocování každá služba je zvýší vašeho plánu zotavení po havárii.Many services include features that support resiliency and availability, so evaluating each service independently is likely to improve your disaster recovery plan. Například podporuje Azure Event Hubs převzetí služeb při selhání na sekundární obor názvů.For example, Azure Event Hubs supports failing over to the secondary namespace.

Přerušení služeb na úrovni celé oblastiRegion-wide service disruptions

Mnoho chyb jsou spravovat v rámci stejné oblasti Azure.Many failures are manageable within the same Azure region. V nepravděpodobném případě výpadku služby na úrovni celé oblasti, nejsou však k dispozici místně redundantní kopie vašich dat.However, in the unlikely event of a region-wide service disruption, the locally redundant copies of your data aren't available. Pokud jste povolili geografickou replikaci, existují tři další kopie objektům BLOB a tabulek v jiné oblasti.If you've enabled geo-replication, there are three additional copies of your blobs and tables in a different region. Pokud Microsoft deklaruje oblasti ztráty, Azure změní všechny položky DNS do sekundární oblasti.If Microsoft declares the region lost, Azure remaps all the DNS entries to the secondary region.

Poznámka

Tento proces dochází k přerušení služeb na úrovni celé oblasti a není v rámci ovládacího prvku.This process occurs only for region-wide service disruptions and is not within your control. Zvažte použití Azure Site Recovery k dosažení vyššího RPO a RTO.Consider using Azure Site Recovery to achieve better RPO and RTO. Pomocí Site Recovery, můžete rozhodnout, co je přijatelné výpadku a kdy se má převzetí služeb při selhání do replikované virtuální počítače.Using Site Recovery, you decide what is an acceptable outage and when to fail over to the replicated VMs.

Reakce na přerušení úrovni celé oblasti služby závisí na nasazení a plán zotavení po havárii.Your response to a region-wide service disruption depends on your deployment and your disaster recovery plan.

  • Jako strategii řízení nákladů pro méně náročné aplikace, které nevyžadují čas zaručené obnovení může mít smysl opětovné nasazení do jiné oblasti.As a cost-control strategy, for non-critical applications that don't require a guaranteed recovery time, it might make sense to redeploy to a different region.
  • Pro aplikace, které jsou hostované v jiné oblasti s nasazené rolí, ale není distribuce provozu mezi oblastmi (aktivní/pasivní vysoká dostupnost nasazení), přepněte na sekundární hostovanou službu v oblasti alternativní.For applications that are hosted in another region with deployed roles but don't distribute traffic across regions (active/passive deployment), switch to the secondary hosted service in the alternate region.
  • Pro aplikace, které mají plnohodnotnému sekundární nasazení v jiné oblasti (aktivní/aktivní nasazení), směrování provozu pro tuto oblast.For applications that have a full-scale secondary deployment in another region (active/active deployment), route traffic to that region.

Další informace o obnovení z přerušení služby na úrovni celé oblasti, naleznete v tématu obnovit přerušení služeb na úrovni celé oblasti na.To learn more about recovering from a region-wide service disruption, see Recover from a region-wide service disruption.

Obnovení virtuálního počítačeVM recovery

Pro kritické aplikace naplánujte pro obnovení virtuálních počítačů v případě přerušení služby na úrovni celé oblasti.For critical apps, plan for recovering VMs in the event of a region-wide service disruption.

  • Použití Azure Backup nebo použijte jinou metodu zálohování k vytvoření záloh mezi různými oblastmi, které jsou konzistentní s aplikací.Use Azure Backup or another backup method to create cross-region backups that are application consistent. (V době vytvoření musí nakonfigurovat replikaci z trezoru služby Backup.)(Replication of the Backup vault must be configured at the time of creation.)
  • Pomocí Site Recovery můžete replikovat do oblastí pro aplikaci jedním kliknutím převzetí služeb při selhání a testování převzetí služeb při selhání.Use Site Recovery to replicate across regions for one-click application failover and failover testing.
  • Pomocí Traffic Manageru můžete automatizovat převzetí uživatelského provozu do jiné oblasti.Use Traffic Manager to automate user traffic failover to another region.

Další informace najdete v tématu obnovit přerušení celé oblasti služeb, virtuálních počítačů na.To learn more, see Recover from a region-wide service disruption, Virtual machines.

Obnovení úložištěStorage recovery

K ochraně vašeho úložiště v případě přerušení celé oblasti služeb:To protect your storage in the event of a region-wide service disruption:

  • Používejte geograficky redundantní úložiště.Use geo-redundant storage.
  • Vědět, pokud úložiště je geograficky replikovaný.Know where your storage is geo-replicated. Tímto je ovlivněn, kde nasadíte další instance vašich dat, které vyžadují místní spřažení na základě vašeho úložiště.This affects where you deploy other instances of your data that require regional affinity with your storage.
  • Po převzetí služeb při selhání zkontrolujte konzistenci dat a v případě potřeby obnovit ze zálohy.Check data for consistency after failover and, if necessary, restore from a backup.

Další informace najdete v tématu navrhování aplikací s vysokou dostupností pomocí RA-GRS.To learn more, see Designing highly available applications using RA-GRS.

SQL Database a SQL ServerSQL Database and SQL Server

Azure SQL Database nabízí dva typy obnovení:Azure SQL Database provides two types of recovery:

SQL Server běžící na virtuálních počítačích, najdete v části vysokou dostupnost a zotavení po havárii pro SQL Server ve službě Azure Virtual Machines.For SQL Server running on VMs, see High availability and disaster recovery for SQL Server in Azure Virtual Machines.

Pokyny týkající se službyService-specific guidance

Následující články popisují zotavení po havárii pro konkrétní služby Azure:The following articles describe disaster recovery for specific Azure services:

SlužbaService ČlánekArticle
Azure Database for MySQLAzure Database for MySQL Přehled kontinuity se službou Azure Database for MySQLOverview of business continuity with Azure Database for MySQL
Azure Database for PostgreSQLAzure Database for PostgreSQL Přehled kontinuity se službou Azure Database for PostgreSQLOverview of business continuity with Azure Database for PostgreSQL
Azure Cloud ServicesAzure Cloud Services Co dělat v případě přerušení služby Azure, které ovlivní Azure Cloud ServicesWhat to do in the event of an Azure service disruption that impacts Azure Cloud Services
Cosmos DBCosmos DB Vysoká dostupnost s využitím Azure Cosmos DBHigh availability with Azure Cosmos DB
Azure Key VaultAzure Key Vault Azure Key Vault dostupnost a redundanceAzure Key Vault availability and redundancy
Azure StorageAzure Storage Po havárii pro obnovení a úložiště účtu převzetí služeb při selhání (preview) ve službě Azure StorageDisaster recovery and storage account failover (preview) in Azure Storage
SQL DatabaseSQL Database Obnovení služby Azure SQL Database a převzetí služeb při selhání do sekundární oblastiRestore an Azure SQL Database or failover to a secondary region
Virtuální počítačeVirtual Machines Co v případě Azure přerušení služby má vliv na Azure CloudWhat to do in the event of an Azure service disruption impacts Azure Cloud
Azure Virtual NetworkAzure Virtual Network Virtuální sítě – kontinuita podnikových procesůVirtual Network – Business Continuity

Další postupNext steps