Dell Integrated System for Microsoft Azure Stack Hub Tech Book

Web application BCDR strategy

Protecting cloud-born applications requires a deeper discussion and a clearer understanding of the top-down BCDR strategy for applications. A “bottom-up” strategy, where the underlying physical hypervisor is the source, does not work, especially for PaaS-based applications.

You must understand how tenants are protecting their cloud-born applications in Azure (or AWS, GCS, and so on). In all cases, the services do not expose an infrastructure backup that targets the underlying computers running complex multitenant services.

Backup is delegated up the stack to the application/tenant. For example, most services expose create, read, update, and delete (CRUD) operations. Administration, development, and development operations can use the services to protect a specific resource, such as backup of an application service or database, replication of a BLOB, and so on.

No single operation backs up all data repositories across all applications and subscriptions. This approach has limitations if you want an application-consistent backup across multiple independent data repositories. There is no virtual switching system (VSS) for PaaS. Over the long term, the most sophisticated application provides native backup and restore capabilities that account for consistency, item level restore, failover, and so on.

As Microsoft ships new PaaS offerings, it offers a consistent set of capabilities for Azure Stack Hub. Each service cannot provide all capabilities on Day One, but Microsoft will close any gaps over time. Microsoft documents the backup and restore workflows that work for each service. For example, Microsoft does not currently support read-access geo-redundant storage (RA-GRS) for BLOB storage. This limitation affects how you design BCDR for an application. You can take a snapshot of a BLOB and copy it to another storage account, but the native replication of BLOBs between two regions is not yet available.