After deployment, you must consider the available options when choosing an enterprise backup and recovery solution.
The following list details the backup objectives for Azure Stack Hub:
- Disaster recovery protects against data loss and unplanned downtime. Implement a backup and recovery or disaster-recovery plan for user apps and their data. This plan might be unique for each app but follows a framework that your organization's comprehensive business continuity and disaster recovery strategy establishes. For more information, download Azure Stack: Considerations for business continuity and disaster recovery.
- Recovery-point objective (RPO) defines the point in time that is used to restore data. The frequency of backups determines the RPO. If a primary system fails, a lower RPO means less data loss. For mission-critical applications, RPOs must be measured in minutes, as opposed to hours or days.
- Recovery-time objective (RTO) defines how long it takes to recover an object such as a file, server, or data center. A lower RTO means less downtime. When you are moving data, the faster your disk drives and network speeds are, the faster your RTO is.
- Mean-Time-to-Recover (MTTR) is the average time that it takes to restore any app after a declared failure. If the MTTR exceeds the RTO, then that outage causes a business disruption that exceeds the pain threshold of that defined RTO.
- Service Level Agreement (SLA) is the amount of time your OEM has to replace defective or broken components during an outage.
Backing up Azure Stack Hub components
Different components of the Azure Stack Hub environment have different requirements for backup and recovery. Components to consider include:
- HLH, hosted virtual machines, network switches
- IaaS and PaaS
Backing up HLH, hosted virtual machines, and network switches
Back up the HLH, hosted virtual machines (DellEMC-MGMTVM and DellEMC-OMEnt), and network switches. Because the HLH is reimaged if there is a catastrophic or component failure, you must manually export the hosted virtual machines so that they can be copied to a Dell EMC Data Domain or Server Message Block (SMB) file share. This task can be scripted and scheduled with PowerShell. After backup, you must share these files on the same backup share where the infrastructure backup controller stores control-plane backup data. We recommend that you organize your backups with a descriptive naming convention such as: Rack1/Region1, Rack2/Region1, Rack1/Region2, and so on.
Backing up infrastructure
Azure Stack Hub has an integrated Infrastructure Backup Service that is fully automated and backs up the Azure Stack Hub configuration. It must be validated regularly.
Infrastructure backups only cover the Azure Stack Hub configuration and its meta data. You can also use infrastructure backups that this service creates for the redeployment of the Azure Stack Hub cloud to restore identity, security, and Azure Resource Manager data. The Infrastructure Backup Service does not include user data and apps.
For more information, see Recover data in Azure Stack Hub with the Infrastructure Backup Service.
Backing up IaaS and PaaS
Dell EMC Data Protection for tenant virtual machines is used to back up IaaS and PaaS virtual machines and workloads, as shown in the following figure. Data Protection can also be used to store Microsoft infrastructure backups on the same Data Domain or SMB file share.
Figure 11. IaaS and PaaS backup summary
The following sections provide more details for each component.
Backing up HLH guest virtual machines
To protect the virtual machines running on the HLH, we recommend that you take a regular backup of the VMs using the Export-VM command function of Windows Server Hyper-V.
Note: The following procedure describes how to do the backup manually. However, backing up the virtual machines is in the Dell EMC Patch and Update Automation Tool, which creates a scheduled task that runs these steps automatically.
Protect your Azure Stack Hub Infrastructure by protecting the virtual machines that are running on the HLH. You can do the backup in several ways, but we recommend that you use the tools that Microsoft provides.
To back up the virtual machines:
- Using either a Windows System or a Dell Technologies data protection product, create an SMB file share in which to back up the virtual machines. The SMB file share for this example is \\10.128.8.126\Backups.
- To export the DellEMC-MGMTVM and DellEMC-OMEnt virtual machines to the SMB file share, run the following command:
Get-VM | Export-VM -Path "\\<SMB_TARGET>\<SMB_PATH>"
The copied files on the SMB file share are now ready to be backed up.
Note: As part of this step, consider creating a password-protected ZIP file to protect against unauthorized access to the data.
Backing up switches
Use the following procedure to back up the switches. Stop if the user account does not match the modified account.
To configure a switch backup:
- In a web browser, log in to https://<MGMTVM_IP>:8443/.
- Select Configuration Management.
- To run the switch backup:
- Go to the Configuration Management Schedule, as shown in the following figure.
- Right-click Default Device Config Backup, and then click Execute. Allow several minutes for the backup to finish, and then click Close, as shown in the following figure.
- For each switch, download a backup of the configuration:
- In the Managed Resources window, select the device that you want to download for the backup.
- Under Configuration Files, right-click the backup, and then choose Export from the options.
- When prompted, click Download Config File.
- Save the file to your backup share.
Enabling a scheduled backup task
We recommend that you enable a scheduled task for the OpenManage Network Manager to back up the switches weekly. The procedure outlines how to verify if this task is already enabled and how to enable the task if it is not.
To verify and enable (if required) a scheduled backup task:
- Go to Configuration Management Schedule.
- Confirm if Default Device Config Job is set to Enabled, as shown in the following figure:
- If it is not enable, right-click the job, and then click Enable Schedule.
Note: The Next Execution Date and Next Backup Date are not filled until after the first job run in the following week.
One of the first tasks as an Azure Stack Hub Operator is to log in to the Administrator Portal and check for active alerts. Usually, you see a “Backup is not enabled for a location.” alert, as shown in the following figure. This alert is associated with the Infrastructure Backup Service and must be configured to perform the infrastructure backups.
Figure 12. Infrastructure backup alert
Enable the Infrastructure Backup Service from the Administration Portal so that Azure Stack Hub can generate infrastructure backups. If there is a catastrophic failure, the hardware partner can use cloud recovery to restore your environment from these backups. The cloud recovery ensures that operators and users can log in to the portal after recovery is complete. Users have their subscriptions restored, including:
- Role-based access permissions and roles
- Original plans and offers
- Previously defined compute, storage, and network quotas
- Key vault secrets
To enable and run an infrastructure backup:
- In the Azure Stack Administration Portal, select All Services, and then under Administration, select Infrastructure backup.
Figure 13. Infrastructure backup
- In the Infrastructure Backup configuration wizard, enter the relevant Backup controller settings, such as the Backup storage location and credentials for the SMB file share: \\10.128.0.126\Backups (the same file share used for HLH backups).
- Click OK.
Figure 14. Infrastructure Backup configuration wizard
- Define the backup frequency and retention policies.
- Provide your Encryption Settings Certificate.
Note: If you already have a certificate, details are not provided.
If you do not have a signed certificate, you must create a self-signed certificate for your infrastructure backups. This certificate uses both public and private keys, but only the public key is exported in the certificate.
- In PowerShell, to create a self-signed certificate, use the following command, and provide the DNS name and location of the certificate:
Scert = New-SelfSignedCertficate ‘
Figure 15. Creating a self-signed certificate
- In the wizard, enter your Encryption Settings Certificate details, and then click OK to save your backup controller settings.
It takes a few minutes to configure the infrastructure backup. A confirmation window appears when the task is complete.
- To start the backup process, from the Infrastructure Backup dashboard, click Backup Now.
Figure 16. Starting a backup
- When the backup finishes, the Notifications window displays either a green or red status indicator to report the success or failure of the backup job.
Figure 17. Backup job notification
- From the Infrastructure Backups dashboard, click Activity log to view the backup activities.
Figure 18. Backup activity log
- Go to the SMC file share (\\10.128.0.126\Backups) to verify what is being backed up.
Figure 19. Verifying backed-up files
Using Microsoft Azure Backup Server
Microsoft Azure Backup Server (MABS) is another backup option for the Dell EMC Cloud for Microsoft Azure Stack Hub solution. You can use MABS to manage the backup and recovery of on-premises physical servers, virtual machines, apps, and production data.
MABS is based on Data Protection Manager (DPM), which is used with System Center. One advantage of using MABS is that it does not require additional licenses, while DPM does. You can run MABS from both an on-premises physical server or from an Azure Stack Hub virtual machine.
MABS supports the following backup scenarios:
- Machine-level with system-state backup
- Machine-level with bare-metal backup
- Backup for specific network shares, folders, or files
- Crash-consistent backup (point-in-time, no application logic)
- Application-consistent backup (point-in-time, with application logic)
For more information about MABS, see What is the Azure Backup service?.
You can download MABS from Microsoft Azure Backup Server v3.
The supported best practices for hosting MABS include:
- MABS on-premises server must be a 64-bit operating system with MABS v3 on Windows Server 2019 (Standard, Essentials, or Datacenter). You can also deploy MABS on an Azure virtual machine with a minimum of A2 Standard, two cores, and 3.5 GB RAM.
- MABS cannot be installed on domain controller or Application Server Roles.
- MABS cannot be installed with System Center, SQL Server, or Exchange Server.
- MABS cannot be installed on any clustered nodes.