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

Zotavení po havárii je proces obnovení funkčnosti aplikace při probuzení závažné ztráty.Disaster recovery is the process of restoring application functionality in the wake of a catastrophic loss.

Vaše tolerance pro omezenou funkčnost během havárie je obchodní rozhodnutí, které se liší od jedné aplikace po další.Your tolerance for reduced functionality during a disaster is a business decision that varies from one application to the next. Může být přijatelné, aby některé aplikace byly zcela nedostupné nebo byly částečně dostupné s omezenou funkčností nebo opožděným zpracováním po 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í se neakceptuje žádné omezené funkce.For other applications, any reduced functionality is unacceptable.

Plán zotavení po haváriiDisaster recovery plan

Začněte vytvořením plánu obnovení.Start by creating a recovery plan. Plán se považuje za dokončený poté, co byl plně testován.The plan is considered complete after it has been fully tested. Zahrňte lidi, procesy a aplikace potřebné k obnovení funkčnosti v rámci smlouvy SLA (Service-level agreement), kterou jste definovali pro vaše zákazníky.Include the people, processes, and applications needed to restore functionality within the service-level agreement (SLA) you've defined for your customers.

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

  • Do svého plánu zahrňte proces pro kontaktování podpory a pro problémy s eskalací.In your plan, include the process for contacting support and for escalating issues. Tyto informace vám pomůžou zabránit dlouhotrvajícímu výpadku při prvním použití procesu obnovení.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.
  • Vyberte architekturu obnovení mezi jednotlivými oblastmi pro klíčové aplikace.Choose a cross-region recovery architecture for mission-critical applications.
  • Identifikujte konkrétního vlastníka plánu zotavení po havárii, včetně automatizace a testování.Identify a specific owner of the disaster recovery plan, including automation and testing.
  • Zdokumentujte proces, zejména ruční kroky.Document the process, especially any manual steps.
  • Automatizujte proces co nejvíce.Automate the process as much as possible.
  • Vytvořte strategii zálohování pro všechny referenční a transakční data a pravidelně provádějte obnovu záložního zálohování.Establish a backup strategy for all reference and transactional data, and test backup restoration regularly.
  • Nastavte výstrahy pro zásobník služeb Azure spotřebovaných vaší aplikací.Set up alerts for the stack of the Azure services consumed by your application.
  • Školením provozních pracovníků proveďte plán.Train operations staff to execute the plan.
  • K ověření a vylepšení plánu Provádějte pravidelné simulace havárie.Perform regular disaster simulations to validate and improve the plan.

Pokud používáte Azure Site Recovery k replikaci virtuálních počítačů, vytvořte plně automatizovaný plán obnovení pro převzetí služeb při selhání celou aplikaci.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ž je automatizace ideální, některé strategie pro zotavení po havárii vyžadují ruční odezvy.Although automation is ideal, some strategies for disaster recovery require manual responses.

UpozorněníAlerts

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. Pokud například Azure SQL Database nebo Azure Cosmos DB konzistentně omezuje vaši aplikaci, může být nutné zvýšit kapacitu databáze nebo optimalizovat vaše 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 když aplikace může chyby omezování transparentně zvládnout, vaše telemetrie by dál mělo vyvolat výstrahu, abyste mohli pokračovat.Even though the application might handle the throttling errors transparently, your telemetry should still raise an alert so that you can follow up.

V případě omezení služby a prahových hodnot kvót Doporučujeme konfigurovat výstrahy pro metriky prostředků Azure a diagnostické protokoly.For service limits and quota thresholds, we recommend configuring alerts on Azure resources metrics and diagnostics logs. Pokud je to možné, nastavte výstrahy pro metriky, které jsou nižší latencí než protokoly diagnostiky.When possible, set up alerts on metrics, which are lower latency than diagnostics logs.

Azure poskytuje prostřednictvím Resource Healthněkolik integrovaných kontrol stavu, které vám pomůžou diagnostikovat problémy s omezením služeb 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 její služby Azure.Configure a disaster recovery strategy for each Azure application and its Azure services. Přijatelné strategie nasazení, které podporují zotavení po havárii, se můžou lišit v závislosti na SLA vyžadovaném pro všechny součásti každé aplikace.Acceptable deployment strategies to support disaster recovery may vary based on the SLAs required for all components of each application.  

Azure poskytuje různé funkce v rámci řady služeb Azure, které umožňují ruční převzetí služeb při selhání, jako jsou geografické repliky Redis Cache, nebo pro automatizované převzetí služeb při selhání, jako jsou třeba skupiny automatického převzetí služeb při selhání.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 aplikaci, která převážně používá virtuální počítače, můžete použít Azure Site Recovery pro webové a logické úrovně.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 Architektura zotavení po havárii z Azure do Azure.For more information, see Azure to Azure disaster recovery architecture. Pro SQL Server na virtuálních počítačích použijte skupiny dostupnosti Always on SQL Server.For SQL Server on VMs, use SQL Server Always On availability groups.
  • Pro aplikaci, která používá App Service a Azure SQL Database můžete použít menší plán App Service vrstev nakonfigurovaný v sekundární oblasti, který při převzetí služeb při selhání provádí automatické škálová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. Pro databázovou vrstvu použijte skupiny převzetí služeb při selhání.Use failover groups for the database tier.

V obou případech nabízí profil Azure Traffic Manager automatické převzetí služeb při selhání napříč 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 aplikacíby měly být nastavené v sekundární oblasti, aby podporovaly rychlejší dostupnost při 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 pro 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ýpadky vypnutím nebo odebráním služeb Azure.Alternatively, you can simulate an outage by shutting down or removing Azure services.

Selhání aplikaceApplication failure

Chyby aplikací jsou buď obnovitelné, nebo neobnovitelné.Application failures are either recoverable or nonrecoverable. Můžete zmírnit chybu, ale v neobnovitelných chybách se aplikace projeví.You can mitigate a recoverable error, but nonrecoverable errors will bring down the application.

  • Některé chyby je možné řešit transparentně tím, že se automaticky zpracovávají chyby a přijímají se alternativní akce.Some failures can be addressed transparently by handling faults automatically and taking alternate actions. Traffic Manager například automaticky zpracovává chyby, které jsou výsledkem základního hardwaru nebo softwaru operačního systému v hostitelském virtuálním počítači.For example, Traffic Manager automatically handles failures that result from the underlying hardware or operating system software in the host virtual machine.
  • V případě některých chyb může aplikace nadále zpracovávat požadavky uživatelů s omezenou funkčností.With some errors, the application can continue handling user requests with reduced functionality.
  • Přísnější výpadky služeb mohou způsobit, že aplikace nebude k dispozici.More severe service disruptions might render the application unavailable.

Dobře navržený systém odděluje zodpovědnost 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í brání výpadku závislé služby v uvedení celé aplikace.This separation prevents a dependent service disruption from bringing down the entire application. Představte si třeba aplikaci pro web Commerce s následujícími moduly:For example, consider a web commerce application with the following modules:

PŘIDAT ODKAZ NA OBRÁZEK

Pokud databáze pro objednávky hostování vychází z provozu, služba zpracování objednávek 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 nemusí být možné odesílat objednávky a zpracovávat služby zpracování objednávek, aby bylo možné pokračovat.Depending on the architecture, it might be impossible for the Order Submission and Order Processing services to continue. Pokud jsou však data produktu uložena v jiném umístění, katalog produktů je stále k dispozici, i když jiné části aplikace nemusí být 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.

Můžete určit, jak bude aplikace informovat uživatele o všech dočasných problémech a vytvořit příslušná oznámení v systému.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 aplikace dovolit Zobrazit produkty a přidat je 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. Pokud se však zákazník pokusí koupit, aplikace by se měla informovat, že funkce ř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 zabraňuje výpadkům služby na úrovni aplikace.Although not ideal for the customer, this approach prevents an application-wide service disruption.

Poškození a obnovení datData corruption and restoration

Pokud úložiště dat dojde k chybě, může dojít k nekonzistenci dat, když budou opět k dispozici, zejména pokud byla data replikována.If a data store fails, there might be data inconsistencies when it becomes available again, especially if the data was replicated. Porozumění plánované době obnovení (RTO) a cíl bodu obnovení (RPO) replikovaných úložišť dat vám může pomáhat odhadnout množství ztráty dat.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, jestli je meziregionální převzetí služeb při selhání spouštěné ručně nebo Microsoftem, najdete v SLA služby Azure.To understand whether the cross-regional failover is started manually or by Microsoft, review the Azure service SLAs. Pro služby, které nemají SLA pro převzetí služeb při selhání mezi oblastmi, Microsoft většinou rozhoduje, kdy převezme služby při selhání, a obvykle určí prioritu obnovení dat v primární oblasti.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 se data v primární oblasti považují za neodstranitelná, 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.

Obnovování dat ze zálohRestoring data from backups

Zálohy chrání před ztrátou součásti aplikace kvůli náhodnému odstranění nebo poškození dat.Backups protect you from losing a component of the application because of accidental deletion or data corruption. Zachovávají funkční verzi komponenty z dřívějšího času, kterou můžete použít k jejímu 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álohy, ale pravidelné zálohování dat aplikací podporuje 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. Volby úložiště pro zálohování by měly být založené na vaší strategii zotavení po havárii.Your backup storage choices should be based on your disaster recovery strategy.

Frekvence spuštění procesu zálohování určí cíl RPO.The frequency of running the backup process determines your RPO. Například pokud provádíte hodinové zálohování a havárie nastane dvě minuty před zálohováním, ztratíte 58 minut dat.For example, if you perform hourly backups and a disaster occurs two minutes before the backup, you will lose 58 minutes of data. Váš plán zotavení po havárii by měl zahrnovat způsob, jakým budete řešit ztracená data.Your disaster recovery plan should include how you will address lost data.

Je běžné, že data v jednom úložišti dat odkazují na data v jiném úložišti.It's common for data in one data store to reference data in another store. Zvažte například SQL Database se sloupcem, který odkazuje na objekt BLOB v Azure Storage.For example, consider a SQL Database with a column that links to a blob in Azure Storage. Pokud zálohování neproběhne současně, může mít databáze ukazatel na objekt blob, který se před selháním zálohovali.If backups don't happen simultaneously, the database might have a pointer to a blob that wasn't backed up before the failure. Aplikace nebo plán zotavení po havárii musí implementovat procesy 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 jsou například 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. Další služby Azure, například Azure cache pro Redis, poskytují geograficky replikované zálohy, 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á Azure Storage a SQL Database data v různých doménách 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žijete geografickou replikaci, data se v jiné oblasti ukládají třikrát.If you use geo-replication, the data is stored three additional times in a different region. Pokud jsou ale data poškozená nebo Odstraněná v primární kopii (například kvůli chybě uživatele), změny se replikují do ostatních kopií.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 potenciálního 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 můžete ukládat v Azure nebo v místním prostředí v závislosti na vašich obchodních požadavcích a předpisech zásad správného řízení.You can store your backups in Azure or on-premises, depending on your business requirements and governance regulations.
  • K obnovení SQL Database použijte možnost obnovení k určitému bodu v čase .Use the point-in-time restore option to recover a SQL Database.

Azure Storage obnoveníAzure Storage recovery

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

Azure Storage zajišťuje odolnost dat prostřednictvím automatizovaných replik, ale nebrání kódu aplikace nebo uživatelům v poškození dat.Azure Storage provides data resiliency through automated replicas, but it doesn't prevent application code or users from corrupting data. Zachování věrnosti dat po chybě aplikace nebo uživatele vyžaduje pokročilejší techniky, jako je například 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 blokuBlock blobs. Vytvořte snímek v čase každého objektu blob bloku.Create a point-in-time snapshot of each block blob. U každého snímku se vám bude účtovat jenom úložiště potřebné k uložení rozdílů v objektu BLOB od předchozího stavu 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ím objektu blob, proto doporučujeme kopírovat na jiný objekt BLOB nebo dokonce i na jiný účet ú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 ochranu zálohovaných dat před náhodným odstraněním.This approach ensures that backup data is protected against accidental deletion. Pomocí AzCopy nebo Azure PowerShell zkopírujte objekty blob do jiného účtu úložiště.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.

  • Soubory Azure. Azure Files. K kopírování souborů do jiného účtu úložiště použijte sdílené snímky, AzCopy nebo PowerShell.Use share snapshots, AzCopy, or PowerShell to copy your files to another storage account.

  • Úložiště tabulek Azure. 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.

SQL Database obnoveníSQL Database recovery

Z důvodu ochrany vaší firmy před ztrátou dat SQL Database automaticky provádí kombinaci úplných záloh databáze každý týden, rozdílové zálohování databáze a zálohování protokolů transakcí 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. Pro SQL Database úrovně Basic, Standard a Premium použijte obnovení k určitému bodu v čase k obnovení databáze do dřívější doby.For the Basic, Standard, and Premium SQL Database tiers, use point-in-time restore to restore a database to an earlier time. Další informace najdete 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 změny v databázi do sekundárních databází ve stejné nebo jiné oblasti Azure.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.

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

  • Pomocí příkazu Database Copy vytvořte záložní kopii databáze s konzistencí transakcí.Use the DATABASE COPY command to create a backup copy of the database with transactional consistency.
  • Použijte Azure SQL Database službu import/export, která podporuje export databází do souborů BACPAC (komprimované soubory, které obsahují schéma databáze a přidružená data) uložené 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. Chcete-li chránit před přerušením služeb na úrovni celé oblasti, zkopírujte soubory BACPAC do alternativní oblasti.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álohování a přesouvání protokolu.For SQL Server running on VMs, you have two options: traditional backups and log shipping.

  • S tradičními zálohováními se můžete vrátit 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í tradičních záloh vyžaduje, abyste začali s počáteční úplnou zálohou a pak použili přírůstkové zálohování.Restoring traditional backups requires that you start with an initial full backup and then apply any incremental backups.
  • Relaci přenosu protokolů můžete nakonfigurovat tak, aby zpozdila obnovení záloh protokolu.You can configure a log shipping session to delay the restore of log backups. Tím se zobrazí okno pro zotavení z chyb provedených 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 můžete použít k obnovení serveru a jeho databází 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 se ukládají samostatně v jiné službě úložiště a replikují se globálně, aby se chránily s místními katastrofami.Backups are stored separately in another storage service and are replicated globally to protect against regional disasters. Pokud databázi nebo kolekci omylem odstraníte, můžete si vytvořit lístek podpory nebo zavolat podporu Azure a obnovit data z poslední automatické zálohy.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 zálohování online a obnovení na vyžádání v Azure Cosmos DB.For more information, see Online backup and on-demand restore in Azure Cosmos DB.

Azure Virtual MachinesAzure Virtual Machines

Pokud chcete chránit Azure Virtual Machines před chybami aplikací nebo náhodným odstraněním, použijte Azure Backup.To protect Azure Virtual Machines from application errors or accidental deletion, use Azure Backup. Vytvořené zálohy jsou konzistentní na více discích virtuálních počítačů.The created backups are consistent across multiple VM disks. Kromě toho je možné repliku Azure Backup do různých oblastí replikovat, aby podporovala obnovení z regionální ztráty.In addition, the Azure Backup vault can be replicated across regions to support recovery from a regional loss.

Výpadek sítěNetwork outage

Pokud jsou části sítě Azure nedostupné, možná nebudete mít přístup k vaší aplikaci nebo datům.When parts of the Azure network are inaccessible, you might not be able to access your application or data. V této situaci doporučujeme navrhnout strategii zotavení po havárii, aby se spouštěla většina aplikací s omezenou funkčností.In this situation, we recommend designing the disaster recovery strategy to run most applications with reduced functionality.

Pokud omezení funkcí není možnost, zbývající možnosti jsou výpadky aplikace nebo převzetí služeb při selhání do alternativní oblasti.If reducing functionality isn't an option, the remaining options are application downtime or failover to an alternate region.

Ve scénáři se sníženou funkčností:In a reduced functionality scenario:

  • Pokud vaše aplikace nemá přístup k datům z důvodu výpadku sítě Azure, může být možné spustit místně s omezenou funkčností aplikace pomocí 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.
  • Dokud nebude připojení obnoveno, může být možné ukládat data do alternativního umístění.You might be able to store data in an alternate location until connectivity is restored.

Selhání závislé službyDependent service failure

U každé závislé služby byste měli pochopit důsledky přerušení služby 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. Mnohé služby zahrnují funkce, které podporují odolnost a dostupnost, takže vyhodnocování každé služby nezávisle může zlepšit plán 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 Azure Event Hubs podporuje převzetí služeb při selhání sekundárním oborem názvů.For example, Azure Event Hubs supports failing over to the secondary namespace.

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

Mnoho chyb je spravovatelných v rámci stejné oblasti Azure.Many failures are manageable within the same Azure region. V nepravděpodobném případě přerušení služeb na úrovni oblasti ale místně redundantní kopie vašich dat nejsou k dispozici.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ů 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 společnost Microsoft deklaruje oblast jako ztracenou, Azure přemapuje 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

K tomuto procesu dochází pouze při přerušení služeb na úrovni jednotlivých oblastí a není v rámci vašeho 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í lepšího cílení na RPO a RTO.Consider using Azure Site Recovery to achieve better RPO and RTO. Pomocí Site Recovery rozhodujete, co je přijatelný výpadek a kdy převzít služby při selhání na 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.

Poznámka

Výběr umístění skupiny prostředků je důležitý.The selection of the Resource Group location is important. V případě regionálního výpadku nebudete moct v rámci této skupiny prostředků řídit prostředky bez ohledu na to, jakou oblast tyto prostředky skutečně používají (tj. prostředky v jiných oblastech budou fungovat i nadále, ale operace roviny správy nebude k dispozici.In the event of a regional outage, you will be unable to control resources inside that Resource Group, regardless of what region those resources are actually in (i.e., the resources in the other region(s) will continue to function, but management plane operations will be unavailable.

Vaše reakce na přerušení služeb na úrovni jednotlivých oblastí závisí na nasazení a na vašem plánu zotavení po havárii.Your response to a region-wide service disruption depends on your deployment and your disaster recovery plan.

  • V rámci strategie řízení nákladů pro nekritické aplikace, které nevyžadují zaručený čas obnovení, může být vhodné ho znovu nasadit 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ými rolemi, ale nedistribuují provoz napříč oblastmi (aktivní/pasivní nasazení), přepněte do sekundární hostované služby v alternativní oblasti.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í úplné sekundární nasazení v jiné oblasti (aktivní/aktivní nasazení), směrují provoz do této oblasti.For applications that have a full-scale secondary deployment in another region (active/active deployment), route traffic to that region.

Další informace o obnovení při přerušení služeb v rámci oblasti najdete v tématu obnovení při přerušení služeb na úrovni služby.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

V případě kritických aplikací si naplánujte obnovování virtuálních počítačů v případě výpadku služeb na úrovni oblasti.For critical apps, plan for recovering VMs in the event of a region-wide service disruption.

  • Použijte Azure Backup nebo jinou metodu zálohování k vytvoření záloh mezi oblastmi, které jsou konzistentní s aplikacemi.Use Azure Backup or another backup method to create cross-region backups that are application consistent. (Replikace trezoru záloh musí být nakonfigurovaná v době vytváření.)(Replication of the Backup vault must be configured at the time of creation.)
  • Pomocí Site Recovery můžete replikovat v různých oblastech pro 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 Manager můžete automatizovat převzetí služeb při selhání uživatele do jiné oblasti.Use Traffic Manager to automate user traffic failover to another region.

Další informace najdete v tématu obnovení z narušení služby, virtuálních počítačů v rámci oblasti.To learn more, see Recover from a region-wide service disruption, Virtual machines.

Obnovení úložištěStorage recovery

Ochrana úložiště v případě přerušení služby v rámci oblasti:To protect your storage in the event of a region-wide service disruption:

  • Použijte geograficky redundantní úložiště.Use geo-redundant storage.
  • Zjistěte, kde je vaše úložiště geograficky replikované.Know where your storage is geo-replicated. To má vliv na to, kde nasazujete další instance vašich dat, které pro vaše úložiště vyžadují regionální spřažení.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í kontrolovat konzistenci dat a v případě potřeby obnovte 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:

Informace o SQL Server spuštěných na virtuálních počítačích najdete v tématu Vysoká dostupnost a zotavení po havárii pro SQL Server v Azure Virtual Machines.For SQL Server running on VMs, see High availability and disaster recovery for SQL Server in Azure Virtual Machines.

Pokyny pro konkrétní službuService-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 provozní kontinuity pomocí Azure Database for MySQLOverview of business continuity with Azure Database for MySQL
Azure Database for PostgreSQLAzure Database for PostgreSQL Přehled provozní kontinuity pomocí 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
Databáze CosmosCosmos DB Vysoká dostupnost s 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 Zotavení po havárii a převzetí služeb při selhání účtu úložiště (Preview) v Azure StorageDisaster recovery and storage account failover (preview) in Azure Storage
SQL DatabaseSQL Database Obnovení Azure SQL Database nebo 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 dělat v případě výpadku služby Azure, má dopad na cloud AzureWhat to do in the event of an Azure service disruption impacts Azure Cloud
Azure Virtual NetworkAzure Virtual Network Virtual Network – provozní kontinuitaVirtual Network – Business Continuity

Další postupNext steps