Zálohování a obnovení po havárii pro aplikace AzureBackup and disaster recover 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 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 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.

Výpadek závislé službyDependent service outage

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.

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.

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 k automatizovanému 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 Application Gateway by měly být nastavené v sekundární oblasti tak, 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.

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:Review 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:

Databáze Azure CosmosAzure 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.

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.

Strategie zálohováníBackup strategy

K dispozici je řada alternativních strategií pro implementaci distribuovaných výpočtů napříč oblastmi.Many alternative strategies are available for implementing distributed compute across regions. Ty musí být upraveny na konkrétní obchodní požadavky a podmínky aplikace.These must be tailored to the specific business requirements and circumstances of the application. V nejvyšší úrovni je možné tyto přístupy rozdělit do následujících kategorií:At a high level, the approaches can be divided into the following categories:

  • Opětovné nasazení při havárii: v tomto postupu se aplikace znovu nasadí od začátku v době havárie.Redeploy on disaster: In this approach, the application is redeployed from scratch at the time of disaster. To je vhodné pro nekritické aplikace, které nevyžadují garantovanou dobu obnovení.This is appropriate for non-critical applications that don’t require a guaranteed recovery time.

  • Volná (aktivní/pasivní) : sekundární hostovaná služba se vytvoří v alternativní oblasti a role se nasadí, aby se zaručila Minimální kapacita. role ale neobdrží provozní provoz.Warm Spare (Active/Passive): A secondary hosted service is created in an alternate region, and roles are deployed to guarantee minimal capacity; however, the roles don’t receive production traffic. Tento přístup je užitečný pro aplikace, které nejsou navržené pro distribuci provozu napříč oblastmi.This approach is useful for applications that have not been designed to distribute traffic across regions.

  • Vyměnitelné za chodu (aktivní/aktivní) : aplikace je navržená tak, aby přijímala provozní zatížení ve více oblastech.Hot Spare (Active/Active): The application is designed to receive production load in multiple regions. Cloudové služby v jednotlivých oblastech můžou být nakonfigurované pro větší kapacitu, než je potřeba pro účely zotavení po havárii.The cloud services in each region might be configured for higher capacity than required for disaster recovery purposes. Cloudové služby se případně můžou v době havárie a převzetí služeb při selhání škálovat podle potřeby.Alternatively, the cloud services might scale out as necessary at the time of a disaster and failover. Tento přístup vyžaduje značné investice do návrhu aplikací, ale má významné výhody.This approach requires substantial investment in application design, but it has significant benefits. Mezi ně patří nízká a zaručená doba obnovení, nepřetržité testování všech umístění obnovení a efektivní využití kapacity.These include low and guaranteed recovery time, continuous testing of all recovery locations, and efficient usage of capacity.

Kompletní diskuze nad distribuovaným návrhem je mimo rozsah tohoto dokumentu.A complete discussion of distributed design is outside the scope of this document. Další informace najdete v tématu zotavení po havárii a vysoká dostupnost pro aplikace Azure.For more information, see Disaster Recovery and High Availability for Azure Applications.

Správa prostředkůResource management

Výpočetní instance můžete distribuovat do různých oblastí vytvořením samostatné cloudové služby v každé cílové oblasti a následným publikováním balíčku pro nasazení do každé cloudové služby.You can distribute compute instances across regions by creating a separate cloud service in each target region, and then publishing the deployment package to each cloud service. Distribuci provozu mezi cloudové služby v různých oblastech ale musí implementovat vývojář aplikace nebo služba pro správu provozu.However, distributing traffic across cloud services in different regions must be implemented by the application developer or with a traffic management service.

Důležitým aspektem plánování kapacity je určení počtu náhradních instancí rolí, které se mají nasadit předem pro zotavení po havárii.Determining the number of spare role instances to deploy in advance for disaster recovery is an important aspect of capacity planning. Úplné sekundární nasazení zajišťuje, že kapacita je již v případě potřeby dostupná; Tím se ale tyto náklady účinně zdvojnásobí.Having a full-scale secondary deployment ensures that capacity is already available when needed; however, this effectively doubles the cost. Běžným vzorem je použití malého, sekundárního nasazení, stačí dostatečně velký, aby bylo možné spouštět důležité služby.A common pattern is to have a small, secondary deployment, just large enough to run critical services. Toto malé sekundární nasazení je dobrý nápad, jak rezervovat kapacitu a testovat konfiguraci sekundárního prostředí.This small secondary deployment is a good idea, both to reserve capacity, and for testing the configuration of the secondary environment.

Poznámka

Kvóta předplatného není záruka na kapacitu.The subscription quota is not a capacity guarantee. Kvóta je jenom úvěrový limit.The quota is simply a credit limit. Aby bylo možné zaručit kapacitu, musí být v modelu služby definován požadovaný počet rolí a role musí být nasazeny.To guarantee capacity, the required number of roles must be defined in the service model, and the roles must be deployed.

Převzetí služeb při selhání a testování po obnoveníFailover and failback testing

Otestujte převzetí služeb při selhání a navrácení služeb po obnovení, abyste ověřili, že se závislé služby vaší aplikace při zotavení po havárii synchronizují.Test failover and failback to verify that your application's dependent services come back up in a synchronized manner during disaster recovery. Změny systémů a operací mohou mít vliv na funkce převzetí služeb při selhání a navrácení služeb po obnovení, ale dopad nemusí být zjištěn, dokud nedojde k selhání hlavního systému nebo dojde k jeho přetížení.Changes to systems and operations may affect failover and failback functions, but the impact may not be detected until the main system fails or becomes overloaded. Otestujte možnosti převzetí služeb při selhání, než se budou muset kompenzovat při živém problému.Test failover capabilities before they are required to compensate for a live problem. Také se ujistěte, že služby a navrácení služeb po obnovení ve správném pořadí.Also be sure that dependent services fail over and fail back in the correct order.

Pokud používáte Azure Site Recovery k replikaci virtuálních počítačů, spusťte testovací převzetí služeb při selhání v pravidelných intervalech k ověření vaší strategie replikace.If you are using Azure Site Recovery to replicate VMs, run disaster recovery drills periodically by doing test failovers to validate your replication strategy. Testovací převzetí služeb při selhání nemá vliv na probíhající replikaci virtuálních počítačů nebo na vaše produkční prostředí.A test failover does not affect the ongoing VM replication or your production environment. Další informace najdete v tématu spuštění postupu zotavení po havárii do Azure.For more information, see Run a disaster recovery drill to Azure.

Ověřování zálohValidating backups

Pravidelně ověřte, že data záloh jsou očekávaná, a to spuštěním skriptu pro ověření integrity dat, schématu a dotazů.Regularly verify that your backup data is what you expect by running a script to validate data integrity, schema, and queries. Neexistuje žádný bod, který by měl zálohovat, pokud nepotřebujete obnovit zdroje dat.There's no point having a backup if it's not useful to restore your data sources. Protokolujte a ohlaste všechny nekonzistence, aby bylo možné službu zálohování opravit.Log and report any inconsistencies so the backup service can be repaired.

Úložiště zálohováníBackup Storage

Zálohy se týkají ochrany dat, aplikací a systémů, které jsou pro organizaci důležité.Backups are about protecting data, applications, and systems that are important to the organization. V provozním prostředí je snadné poskytnout zálohy: vyberte úlohy, které potřebují technologii Hyper-v a zálohujte je.In operations environments, it’s easy to provide backups: pick the workload that needs hyper-availability and back it up. Provozní prostředí jsou poměrně statická – v takovém případě se používají systémy a aplikace s relativně konzistentními daty, ale data se mění denně.Operations environments are relatively static – in that, the systems and applications used remain relatively consistent, with only the data changing daily.

Archivy aplikacíApplication archives

Je důležité si uvědomit, že plán DR je z procesu zálohování a ověření více než pouze objednané obnovení.It’s important to remember, that a DR plan is more than just an ordered restoration from backup and validation process. Aplikace mohou vyžadovat konfiguraci po obnovení z důvodu změn v lokalitě, nebo je možné, že se znovu nainstalují obnovená data, která jsou importována po.Applications may require post-restoration configuration due to site changes, or reinstallation may be necessary with restored data imported after.

Zpětné výpadkyOutage retrospectives

Žádná ochranná ani přípravná ochrana nemůže zabránit každému možnému incidentu a někdy jednoduchá lidská chyba může mít významné důsledky pro vývoj projektu.No amount of safeguards or preparation can prevent every possible incident, and sometimes simple human error can have significant consequences to a development project. Nemůžete se k tomu vyhnout, ale můžete se z něho dozvědět, jak v budoucnu minimalizovat pravděpodobnost podobného incidentu.You can't avoid it, but you can learn from it and take steps to minimize the chances of a similar incident in the future. Otázka je způsob, jakým mohou organizace softwaru nejlépe přejít na učení s využitím agilního postmortemsu.The question is how software organizations can best go about learning from mistakes with agile postmortems.

Plánování regionálních selháníPlanning for regional failures

Azure je rozdělen fyzicky a logicky do jednotek nazývaných oblasti.Azure is divided physically and logically into units called regions. Oblast se skládá z jednoho nebo více datových center v těsné blízkosti.A region consists of one or more datacenters in close proximity.

Ve výjimečných případech je možné, že zařízení v celé oblasti můžou být nepřístupná, například kvůli chybám sítě.Under rare circumstances, it is possible that facilities in an entire region can become inaccessible, for example due to network failures. Zařízení nebo se můžou úplně ztratit, například kvůli přirozené havárii.Or facilities can be lost entirely, for example due to a natural disaster. Tato část vysvětluje možnosti Azure pro vytváření aplikací, které jsou distribuované napříč oblastmi.This section explains the capabilities of Azure for creating applications that are distributed across regions. Tato distribuce pomáhá minimalizovat možnost, že selhání v jedné oblasti může ovlivnit jiné oblasti.Such distribution helps to minimize the possibility that a failure in one region could affect other regions.

Projděte si část obnovení ze ztráty oblasti Azure , kde najdete pokyny k určitým službám Azure.Review Recover from loss of an Azure region for guidance on specific Azure services.

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ší krokyNext steps