Infrastructure Backup Service best practices - Modular Data Center (MDC)

Applies to: Modular Data Center, Azure Stack Hub ruggedized

Review these best practices regularly to verify that your installation is still in compliance when changes are made to the operation flow. If you encounter any issues while implementing these best practices, contact Microsoft Support for help.

Configuration best practices

Infrastructure backup is enabled by default during deployment of a new system and stored internally. Using the Azure Stack portal or PowerShell, you can provide an external storage location to export the backups to a secondary location.

Networking

The Universal Naming Convention (UNC) string for the path must use a fully qualified domain name (FQDN). An IP address can be used if name resolution isn't possible. A UNC string specifies the location of resources such as shared files or devices.

Encryption

The encryption certificate is used to encrypt backup data that gets exported to external storage. The certificate can be a self-signed certificate since the certificate is only used to transport keys. For more information about how to create a certificate, see the documentation for New-SelfSignedCertificate.

The certificate must be stored in a secure location. The CER format of the certificate is used to encrypt data only and not used to establish communication.

Operational best practices

Backups

• Backup jobs execute while the system is running so there is no downtime to the management experiences or user apps. Expect the backup jobs to take 20-40 minutes for a solution that's under reasonable load.

• Additional instructions provided to manually back up network switches and the hardware lifecycle host (HLH).

Folder names

• The infrastructure creates a MASBACKUP folder automatically. This is a Microsoft-managed share. You can create shares at the same level as MASBACKUP. It's not recommended to create folders or storage data inside of MASBACKUP that Azure Stack does not create.

• The user FQDN and region in your folder name differentiates backup data from different clouds. The FQDN of your Azure Stack deployment and endpoints is the combination of the Region parameter and the External Domain Name parameter. For more information, see Azure Stack datacenter integration - DNS.

For example, the backup share is AzSBackups hosted on fileserver01.contoso.com. In that file share, there may be a folder per Azure Stack deployment using the external domain name and a subfolder that uses the region name.

• FQDN: contoso.com
• Region: nyc

\\fileserver01.contoso.com\AzSBackups
\\fileserver01.contoso.com\AzSBackups\contoso.com
\\fileserver01.contoso.com\AzSBackups\contoso.com\nyc
\\fileserver01.contoso.com\AzSBackups\contoso.com\nyc\MASBackup

The MASBackup folder is where Azure Stack stores its backup data. Don't use this folder to store your own data. OEMs should also not use this folder to store any backup data.

OEMs are encouraged to store backup data for their components under the region folder. You can store each network switch, hardware lifecycle host (HLH), and so on, in its own subfolder. For example:

\\fileserver01.contoso.com\AzSBackups\contoso.com\nyc\HLH
\\fileserver01.contoso.com\AzSBackups\contoso.com\nyc\Switches
\\fileserver01.contoso.com\AzSBackups\contoso.com\nyc\DeploymentData
\\fileserver01.contoso.com\AzSBackups\contoso.com\nyc\Registration

Monitoring

The following alerts are supported by the system:

Infrastructure Backup Service components

The Infrastructure Backup Service includes the following components:

• Infrastructure Backup Controller: The Infrastructure Backup Controller is instantiated with and resides in every Azure Stack cloud.

• Backup Resource Provider: The Backup Resource Provider (Backup RP) is composed of the user interface and APIs exposing basic backup functionality for the Azure Stack infrastructure.

Infrastructure Backup Controller

The Infrastructure Backup Controller is a Service Fabric service that gets instantiated for an Azure Stack Cloud. Backup resources are created at a regional level and capture region-specific service data from AD, CA, Azure Resource Manager, CRP, SRP, NRP, Key Vault, and RBAC.

Backup Resource Provider

The Backup Resource Provider presents a user interface in the Azure Stack portal for basic configuration and listing of backup resources. Operators can perform the following actions in the user interface:

• Enable backup for the first time by providing external storage location, credentials, and encryption key.
• View completed created backup resources and status resources under creation.
• Modify the storage location where Backup Controller places backup data.
• Modify the credentials that Backup Controller uses to access external storage location.
• Modify the encryption certificate that Backup Controller uses to encrypt backups.

Backup Controller requirements

This section describes important requirements for the Infrastructure Backup Service. We recommend that you review the info carefully before you enable backup for your Azure Stack instance, and then refer back to it as necessary during deployment and subsequent operation.

The requirements include:

• Software requirements: Describes supported storage locations and sizing guidance.
• Network requirements: Describes network requirements for different storage locations.

Software requirements

Supported storage locations

Supported SMB versions

SMB encryption

The Infrastructure Backup Service supports transferring backup data to an external storage location with SMB encryption enabled on the server side. If the server doesn't support SMB Encryption or doesn't have the feature enabled, the Infrastructure Backup Service falls back to unencrypted data transfer. Backup data placed on the external storage location is always encrypted at rest and is not dependent on SMB encryption.

Storage location sizing

We recommend that you back up at least twice a day, and keep at most seven days of backups. This is the default behavior when you enable infrastructure backups on Azure Stack.

Network requirements

Encryption requirements

The Infrastructure Backup Service uses a certificate with a public key (.CER) to encrypt backup data. The certificate is used for transport of keys and is not used to establish secure authenticated communication. For this reason, the certificate can be a self-signed certificate. Azure Stack does not need to verify root or trust for this certificate, so external internet access is not required.

The self-signed certificate comes in two parts, one with the public key and one with the private key:

• Encrypt backup data: Certificate with the public key (exported to .CER file) is used to encrypt backup data.
• Decrypt backup data: Certificate with the private key (exported to .PFX file) is used to decrypt backup data.

The certificate with the public key (.CER) is not managed by internal secret rotation. To rotate the certificate, you must create a new self-signed certificate and update backup settings with the new file (.CER).

All existing backups remain encrypted using the previous public key. New backups use the new public key.

For security reasons, the certificate used during cloud recovery with the private key (.PFX) is not persisted by Azure Stack.

Infrastructure Backup limits

Consider these limits as you plan, deploy, and operate your Microsoft Azure Stack instances. The following table describes these limits.

Next steps

• Learn more about the Infrastructure Backup Service.