When I wrote my book Installing and Configuring Windows Server 2012 R2 Training Guide three years ago, Windows Server Backup was still the best in-box way of safeguarding your Windows Server systems from possible disaster. While Microsoft Azure Backup had just been released that same year as a backup solution utilizing the Microsoft Azure public cloud for orchestrating backup workflows and storing backups, Microsoft still seemed to be lagging behind the online backup solutions of other cloud providers. In the last three years things have radically changed in this regard and Azure Backup now has numerous features that make it appealing for performing cloud-based disaster recovery. Even so, there is always room for improvement, and now with the v.1709 refresh of the Windows Server platform Microsoft has added a more robust cloud-based off-site backup story to the in-box Windows Server Backup tool with Azure Backup.
Windows Server Backup
Windows Server Backup (WSB) has been the time-tested tool that server admins trust for backing up critical Windows Server assets such as files, application workloads as well server system state either to locally attached media or to network shares to store the backups at remote locations. The choice between local and remote backup is driven by a combination of RTO (recovery time objective) and DR (disaster recovery) requirements. Backups that have low RTO requirements, i.e. faster restores, need to be stored locally while backups with higher RTO requirements can be stored remotely. This allows server admins to lower the consumption of local storage for backups and reserve most of it for production workloads. DR compliance requirements mandate backups to be stored at remote locations, often several miles away or in a different city. While WSB does allow the ability to back up remotely to network shares, Azure offers a more robust, secure, and economical model to store these backups remotely. Backup of file servers and system state are excellent candidates for remote backups to Azure and a deeper look explains why.
The fundamental reason backups are stored locally is to meet RTO requirements for faster restores. Restores for virtual machines or workloads such as SQL require the entire server to be restored, so it makes sense to store them locally. However, the primary restore use case for file servers is to recover individual files and folders because the users did an accidental delete. With advances in network bandwidth and storage access technologies, restoring individual files from cloud backups is getting faster every day, which satisfies RTO requirements of this scenario for most enterprises
System State backup feature in WSB is used to restore the server in case of a DR event such as a server crash, configuration corruption, or a site outage. Since this is a DR use case, these backups must to be stored at a remote location and customers currently use the backup-to-network-share feature in WSB for this use case. This solution has a few limitations such as lack of versioning and potential backup corruption if the network shares become unavailable during the backup that make it a less-than-ideal solution. Storing system state on the public cloud not only satisfies the DR requirement, it also handily meets RTO requirements since the average size of the system state image is about 25GB, which can be restored relatively quickly from the public cloud.
As evident from the commentary above, backing up file folders and system state to the public cloud delivers compelling value to customers, and WSB customers can hit refresh with Azure Backup.
Introducing Azure Backup
A simple, secure, and reliable solution from the very folks that created Windows Server Backup to take the advantage of the cloud for remote backup for file servers and system state.
Resilient, secure, and reliable offsite backup
Azure Backup leverages the infinite scale of Azure to provide a bottomless, highly available, and robust offsite backup target. Azure Backup stores three copies of your data at a minimum, thereby precluding possibilities of backup data loss due to corruption or storage failures. Azure Backup's native AES256 encryption encrypts backups at the source with a user-provided key and then sends it securely via HTTPS to Azure. Backups stored in Azure Backups are encrypted at REST and have built-in security features that safeguards against ransomware attacks.
Flexible backup and retention policy
Azure Backup enables up to three daily backups, which provides higher granularity during recovery as well as separate backup policies for Files and System State that provides flexibility for the server’s data and configuration. Azure Backup features a rich experience to specify retention period for daily, monthly, weekly, and yearly backups to meet long-term retention (LTR) for your compliance-sensitive files while optimizing storage consumption in Azure as shown here:
Central Management at Scale
Once a Windows server is registered with the Azure Backup service, it provides a bird’s eye view of the status of all the backups, provides automated alerts for failed backups, and generates custom reports using Microsoft Power BI. Furthermore, there is no need to deploy any agents or provision additional infrastructure to get these management capabilities, which can be used to backup operations at scale. For example, see the following screenshots:
For more info about the new capabilities of Azure Backup, see this post on the Windows Server Blog.
To get started with Azure Backup you can:
- Create your 30-day free trial Azure account, which has $200 of Azure credits to get you started.
- Follow three simple steps in this tutorial to start backing up your files and System State.
- Follow us on Azure Backup Blogs, Twitter, or Azure Backup user voice to share your feedback.
Happy backing up with Azure Backup!
Photo credit: StockVault.net