How to protect and backup your Branch and Remote offices data (Files and Folders) ?

Hi everyone,

Since the first days of the adoption of an Information System by companies, backing up the workloads was crucial and a production blocker : No production without backup, no backup,  no business.

Today, companies are better mastering and understanding their backup needs, solutions and they are continually seeking for better, simple and cost effective backup software.

One of the ‘headache’ subjects that bother the majority of the backup admins and decision makers is the Remote Offices / Branch Offices (ROBO) ‘Files and Folders’ data backup.

During this post, I will show why Azure Backup via the MARS agent is your best choice to get rid of the ROBO workloads backup problematic. I will present :

  • Use cases for using Azure Backup via MARS agent
  • What do you need to know in order to be comfortable with this solution
  • What are the steps to plan and start using Azure Backup via MARS agent for your ROBO

1- Use cases for using Azure Backup via MARS agent

Azure Backup is the name of a complete enterprise backup solution allowing several backup scenarios and using the last technologies, specially the ability to back up to the cloud and to benefit from a GFS model (a model allowing  efficient Long term retention policies).

What is interesting about Azure Backup via MARS agent is that it allows you to backup your files and folders without the need to deploy a Backup Infrastructure or a Storage infrastructure. This opens up a lot of use cases :

Backup without backup infrastructure

The following picture shows the end to end data journey from your Windows Server or Workstation to the cloud storage (More details about the components later on this post). As you can note, the backup will needs only the installation of the Azure Backup Agent (MARS agent : Microsoft Azure Recovery Services agent) and to configure it to
backup data to a cloud location (Recovery Services Vault)

This is fantastic since it removes the classic requirements to enable workloads backup :

  • Backup software infrastructure (Backup server, Backup Proxy…)
  • Local storage : No need for a SAN or a NAS. Azure backup will directly send data to the cloud using an internet connection

Short and Long term retention without backup infrastructure

In addition to the great value from the first discussed statement, Azure Backup provides in the same time, Short and Long term retention within the same policies. No need for tapes, no need for external provider to handle it. Azure Backup use a GFS model to allow  Long Term retentions without any additional configuration. You can reach up to 99 years of retention period for up to 9999 recovery points (These values can change on the future).

Low bandwidth/Latency ROBO locations

The Azure Backup agent supports throttling (2) the data transfer to the cloud location (Not for all OSs). This is very important for ROBO location with limited bandwidth that prevent you from using your central backup infrastructure (Backup to a central backup repository)


2- What do you need to know

In this section, I will resume the important information that you need to know about the Azure Backup (Specially with the MARS agent). These information will give you the ability to decide, design and implement Azure backup into your information system.

2.1- Pricing

Fortunately, the Azure Backup pricing is very simple. It’s well explicated on the official documentation (1) but to resume:

When you backup a workload, you pay for :

  • An Azure Backup fixed cost for each backed up instance (The cost depends on the size of the data being backed up)


  • The storage used by the recovery points:
    • You can choose between LRS or GRS storage (3). To resume, LRS (Locally redundant storage) is a storage only available with the region where you create the Recovery Vault. GRS is a storage replicated asynchronously to another paired region providing hence, a protection against region failure, but more expensive (4) (~ * 2)
    • The redundancy cannot be changed after the first workload backup, so be sure of your decision before going forward


For example, if you backup 4 windows servers, you will pay:

  • 4* Azure Backup fixed cost
  • The cost of the Azure storage (cloud storage) used by the recovery points

2.2- Requirements

In this section, I will resume what do you need to technically be ready to use Azure Backup (via the MARS agent)


2.2.1-  Azure Level

As discussed earlier in this post, you need the location where you will send and store backups. This is called Recovery Services Vault (RSV). An RSV is a Microsoft Azure resource, which means that you need to subscribe to Azure in order to deploy it. Subscribing to Microsoft Azure is very simple, there are many ways to achieve it, depending on your needs and the billing/relation model that you want. In order to use Azure, you need to create an Azure subscription (5). After creating it, you can directly without any requirement create an Azure Recovery Vault, ready to host your backups (within minutes).

You will then need access* to the Recovery Vault in order to begin. You can benefit from the Azure RBAC roles (6) in order to have or give required permissions.

In order to backup Files and Folders via the MARS agent, you will just need:

  • The MARS agent installation file : Allowing you to install the agent on the required servers
  • The Vault credentials : Allowing the MARS agent to find and authenticate to the Azure Recovery Vault.

Both of them can be downloaded via the Azure portal via the Azure Recovery Services resource blades.

* Technically, you don’t need access to the Recovery Vault to enable backups. An Admin can send you the required information instead.

2.2.2- Local level

I mean by local level, what do you need at the server level (The server where the folders and files to be backed up) in order to start backing up :

  • A supported Operating system : Only Windows is supported, Linux is not yet supported.
  • A internet connectivity : The agent needs outbound internet connection to the Azure services in order to send data. Using a Proxy is supported. You can in addition limit the outbound flows to only Azure services public IPs (7) (And even more, only the IPs belonging to the RSV region)


There are limitations regarding the supported operating systems, what can you backup, how often you can backup and more. Please refer to the Azure Backup FAQ for complete information


2.3- Security and data confidentiality

Azure backup via the MARS agent provides many precious security aspects, let me enumerate some of them:

  • You will need a Vault credentials file in order to register an agent to a vault. Only backup admins can download such file from the Azure portal
  • Before enabling the backup, you will be prompted to provide a ‘passphrase’. A passphrase is a ‘complex password’ used to encrypt data before sending it to the RSV. Data is encrypted and send via HTTPS to the RSV where it remains encrypted. Note that without this passphrase, you will not be able to restore data in case you lose the original server (Or its configuration), the passphrase must be kept securely somewhere (You can use Azure Key Vault to store your secrets)
  • In case your server is compromised, the compromiser (Hacker, malicious admin) cannot delete you recovery points. Azure backup provides a security setting (enabled by default) that requires the ‘remover’ to login to the Azure Portal and generate a PIN code. The probability that the ‘compromiser’ owns the credentials to login to the Azure portal is small. In addition, you can benefit from the ‘MFA’ feature of Azure portal in order to more secure the portal access.
  • In case of ransomware/crypto-locker attack or infection, your backup data is protected, since the backup media is totally independent of the server.
  • Other security prevention feature are also available (8) :
    • Retention of deleted backup data: Backup data retained for 14 days after delete operation
    • Minimum retention range checks: Ensures more than one recovery point in case of attacks
    • Alerts and notifications: For critical operations like Stop backup with delete data
    • Multiple layers of security: Security PIN required for critical operations (Already mentioned)

2.4- Monitoring and reporting

Like you noticed, there is no server nor a console to install, monitor or see what is happening. All is done via the Azure Portal. You can use the Azure portal to :

  • Backup Items : View the backed up items (Server name, volume…)
  • Backup Status : You can view and show the status of the backups, with ‘filtering’ options
  • Backup jobs: You can see the backup jobs and their status. You can see the duration and the size of the backups and restore operations
  • Notifications : You can configure and see the notifications related to the jobs. Currently, you can only configure notifications based on the jobs status (Critical, Warning, Information)

Currently, there is no ‘Reporting’ feature with Azure backup via the portal. But this feature is coming very soon.

3- How to start : The plan

In this third and final section, I will present the planning steps in order to successfully plan and implement your ‘Folders and Files’ backup. The main steps are :

  1. Create a Recovery Services Vault
  2. Configure the vault
  3. Download the Recovery Vault credentials
  4. Install the MARS Agent on the server
  5. Create a backup policy and a schedule

This link shows the detailed steps to achieve the above steps :

The Azure Backup FAQ contains the most answers to your questions :

To finish, the following are my recommendations when planning to implement Azure Backup via the MARS agent:

Question / Constraint


Are my source servers located on the same region ? It’s recommended to backup data to the nearest location in order to benefit from a better performance / Latency during backup and restore operations.
Do I need to back up to the same RSV ? No, but to have a simple design, it’s better to minimize the number of RSV for the a similar servers group.
When do I need to backup to different RSV What can differentiate two Recovery Services Vault  :

–         The redundancy of the Storage (LRS or GRS)

–         The user rights on the RSV

–         The vault credentials

So :

–               If you have different ‘data’ importance, and you want to optimize the costs, you can create ‘LRS’ RSVs for less important data, and ‘GRS’ RSVs for more important and critical data

–               You can give permissions to access or manage the Recovery Service Vault. If you want different security levels for your Vault, you can create multiple RSV

–               The Vault Credentials are unique for an RSV. A user with a valid Vault credentials file (expires after 2 days) can backup data to the vault

Use the same passphrase for each server ? No. This is absolutely not recommended for the unique reason is that someone compromises the passphrase, he can access you all your server’s restore points (He will need a valid Vault credentials file)


Useful Links:


(1) Azure Backup pricing :

(2) Azure Backup agent network throttling :

(3) Azure Storage redundancy :

(4) Azure Storage pricing :

(5) Designing Azure Subscriptions :

(6)Azure Backup Roles : Backup Contributor, Backup Operator, Backup Reader

(7) Azure Public IP ranges :

(8) Azure-backup-security-feature :

(9) Azure subscription and service limits, quotas, and constraints :

How to protect and backup your branch-offices data and workloads ?

Hi all,

This is a rapid post where I will share one of my last experience during a customer call for advice.

The customer have several branch offices (Tens). In each site, a ‘big’ server is deployed where several Virtual Machines are running to provide ‘vital’ infrastructure like :

  • Active Directory Domain Controller (RODC) + DHCP + DNS + Printer services
  • File Server
  • SCCM Distribution point

The question was arisen when we studied some DR and Service continuity scenarios : The branch offices workloads were under the scope, but the priority was very low, and the question was : How can I minimally protect the branch offices data with 0 investment ?

This is wasn’t a very difficult question, and the answers were like the following :

  • AD + DNS + DHCP + Printer Services :
    • AD services : When the RODC is not reachable, clients automatically contacts the primary domain controllers on the main site (Through S2S VPN or MPLS). This is a built-in AD service  –> Solved
    • DNS : The secondary DNS servers configured via DHCP are the main site DNS servers —> Solved
    • DHCP  : This is a vital service, without DHCP, clients will not obtain IP addresses and will not be able to work. The solution was to configure (since Windows Server 2012) a Hot-Standby failover relation ship with the main site. The branch-offices network device must only support IP-helpers –> Solved
  • SCCM DP : The SCCM distribution point helps providing deployed packages from a near place (50 clients downloading an Office 2016 package (1 GB) or Windows updates from a local server is better than over a VPN connection. Just like domain controller, if a client is not able to reach the ‘nearest’ DP server, it will contact the next one, which can be the main site DP –> Solved
  • File sever : This was the hardest question. How can we protect the file servers data and rebuild them on case of disaster, data loss or anything similar ? Let’s discuss this case more deeply

The file Server history

The file server is not stateless

What differs the file server from the other servers is that it contains changing data. In case we loose this data (data loss, ransomware, accidental deletion…), there is no built-in way to recover it

Availability or Recovery ?

There are two wishes against a file server data :

Availability : This is the need of accessing the data even if the File server goes down

Recovery : This is the need to recover the data when needed. The data recovery can be when rebuilding the server (In case of server loss) or to recover a set of files/folders as part of an Item-Level-Recovery (Deleted files, old version, ransomeware…)

The file server solution

Faced to both needs, I proposed the easiest way to achieve each need:

Availability : The easiest way to achieve availability for file servers (In case of Branch offices, minimum infrastructure) is to enable DFS-R and DFS-N. DFS-R will replicate your files to another server on the main site. DFS-N will be used to create a virtual view of shared folders permitting using the same UNC path to land on the Office’s file server and in case of failover, to land on the main site file server (where replicated files reside). This solution is very simple to be implemented. The main site server can be a target for multiple offices. The requirements are Office-MainSite bandwith and main site storage

Recovery : When we say recovery, we say Backup. The challenge was to find a ‘simple’ backup solution that :

  • Backup the shares
  • Restore the files using an Item Level Restore mechanism (User and Admin experience)
  • Does not use local storage as the office’s infrastructure is limited (In addition that local storage does not protect against site disaster)

I was very lucky when this ‘small’ challenge was requested since I was aware of the Azure Backup MARS agent experience.

Why I was lucky ?

Backing up (and restoring data) via the Azure Backup MARS (Microsoft Azure Recovery Services) agent is very interesting in this case for several reasons:

  • Deployment Simplicity : In order to backup data, you will need just to download the MARS agent, install it, and choose what and when to backup, and where the data should be backed up
  • No infrastructure : You don’t need to deploy a backup infrastructure or provide local storage. The MARS agent supports Azure Cloud storage via the Azure Recovery Vaults. A Recovery Vault is a Backup Cloud space that you need to create first (One for each file server, one for each region or one for all) and then provide it during the backup configuration wizard.
  • Item Level Restore : The Admin can easily make an Item Level Restore of backed up items
  • Limitless capacity and retention :  Azure Recovery services provides limitless storage and retention periods (up to 99 years)
  • Encrypted backup data : The data backed up to the cloud are encrypted using a key you only know.
  • Management from the cloud : The management of the operations (Backup operations, jobs, consumed storage, registered servers, notifications, alerts…) is easily done from a single portal, the Azure Portal Azure Backup MARS  agent experience


Backup using MARS agent steps (Microsoft credit picture)

What else ?

All the requirements were met. The backup solution fits the needs and has a very small TTM (Time To Market)


If you are facing the challenge of protecting branch-offices data (connected to a main site) then do not hesitate to use ‘simple’ ways to achieve it on order to simplify your architecture and to optimize costs. Use Azure Backup to protect any workload (Even Linux is supported) and to guarantee that your data are safe on a remote location. The following table resumes my post :


How to ensure availability or recovery

Active Directory Domain controller

The failover to another DC is buit-in


Windows Server 2012 (and later)  DHCP failover


Secondary remote DNS servers

File Server

  • Availability : DFS-R + DFS-N
  • Backup/Restore : Azure Backup via MARS agent

Azure Backup with Azure Recovery Services : Features and limitations

Hi all,

It has been  days since Microsoft announced the Public Preview of Azure Backup via Azure Recovery Services. In this post I will enumerate the different features and limitations of the service, to help you decide if it fits your needs.

NB : This post is only related to IaaS part of Azure Backup

The following is the agenda of this post :

Introduction to Azure Backup via Recovery Services

Azure Backup for Azure IaaS features (Current and Coming)

Azure Backup for Azure IaaS  limitations

1- Introduction to Azure Backup via Recovery Services

Azure Backup was released first time under Azure Backup vaults, and it was only supporting classic Azure IaaS (Azure Service Management ie IaaS v1). With the GA of the Azure Resource Manager stack on summer 2015, IaaS V2 users were not able to use Azure Backup to protect their V2 virtual machines. This was the first blocker of the ARM stack adoption and one of the most wanted feature regarding the ARM platform.


After 10 months of struggle, Microsoft announced the Public Preview of Azure Backup supporting IaaS V2 virtual machines. It’s a real alleviation for Azure IaaS V2 users, but also for all Azure users planning to use Azure backup features. The main difference is that Azure Backup is now part of Azure Recovery Services vaults, and no longer Azure Backup vaults. Azure Backup vaults still exist under the ASM stack, but it’s clear that sooner or later, all will be integrated to Azure Recovery Services.

Azure Recovery Services include both Azure Backup and Azure Site Recovery supporting both ASM and ARM stacks. This is what we call great news:

  • Azure Recovery Services is integrated to the new portal (Ibiza portal)
  • Azure Backup and ASR under Recovery Services vaults support both ASM and ARM stacks

Azure Backup under Recovery Services vaults support the 4 backup scenarios:

  • Azure Backup Server or Agent based:
    • Azure Backup Agent to Azure –> Backup files and foders to Azure Storage
    • Azure Backup with System Center Data Protection Manager –> Backup Hyper-V VMs, SQL server, SharePoint, files and folders to Azure Storage
    • Azure Backup with Azure Backup Server (MABS, code name Venus) –> Backup Hyper-V VMs, SQL server, SharePoint, files and folders to Azure Storage
  • Azure Backup on the Azure Service Fabric :
    • Azure Backup for IaaS VMs –> Backup Classic and ARM Azure Virtual Machines


This post will only detail Azure Backup for IaaS virtual machines

2- Azure Backup for Azure IaaS features (Current and Coming)

Azure Recovery Services is currently under Public Preview. The following are the features of Azure Backup and the expected features that will come with GA:

  • Backup and Restore ARM and ASM Azure virtual machines (V1 and V2)
  • Based on backup policies : Two backup schedules exist : Daily and Weekly. This way you can define backups which occur daily or weekly
  • Azure Backup provides different retention periods possibility : Daily, Weekly, Monthly and yearly. Microsoft officially stated a maximum retention period of 99 years, however, thanks to Azure Backup flexibility, you can have unlimited retention period, up to 9999 years. This way, you can achieve long term retention using the same policy and mechanism (9999 days for daily backups, 9999 weeks for weekly backups,9999 months for monthly retentions ,9999 years for yearly retention)
  • Azure Backup provides 3 recovery point consistency types : Application, File and Crash consistent recovery points. You can consult the documentation to get the requirements and prerequisites for each type
  • The Backup Vault’s Storage redundancy can be GRS or LRS. GRS is more secure (Data is replicated between two regions) but more expensive (LRS *2), LRS is less secure (Locally Redundant) but cheaper. As per my experience, because the Azure Backup pricing is per protected instance (And the price is relatively high), you will notice that the Storage cost is a small fraction of the Azure Backup instances cost, so using GRS will not really impact the bill.
  • Azure Backup use incremental backups : The first recovery point is a full backup, the next ones are incremental backups : This reduce the consumed backup storage. Due to the Azure Backup design and mechanism, incremental backups will not impact the restore time.
  • Simple pricing model : The cost of Azure Backup is like the following : Total Cost = Instance Cost + Consumed Storage. If you know the daily change or growth of your data, than you can easily predict the backup cost. See this link for Azure Backup pricing :
  • A backup operation consist of two phases : Snapshot phase and Data transfer phase. The snapshot phase occur when the scheduled moment comes. The data transfer he backup vault begins just after the snapshot completion. This operation lay take up to 8 hours during rush hours but will always completes before 24 hours.
  • Azure Backup provides 99,99 availability SLA for Backup and Restore, monthly based. This is only applicable for the GA product.
  • Currently, two restore options are available
    • To a Virtual Machine : A new Virtual Machine is created
    • To a Storage Account : VHDs can be restored to a Storage Account
  • I expect some features to come with and post GA, but this my own thoughts, since this is what actually implemented with DPM and MABS :
    • Backup/Restore of Files and folders from a VM recovery point
    • Backup/Restore SQL or/and MySQL databases directly from a VM

3- Azure Backup for Azure IaaS limitations

  • Azure Backup does not currently support Premium Storage virtual machines. This feature will released probably during the GA
  • Currently, the daily backup supports 1 recovery point per day ie you cannot backup a Virtual Machine more than once time a day. To achieve this, use the ‘manual backup’ to schedule more than one backup a day. Keep in mind that two simultaneous backups are not supported, so you will need to wait for the first once to compete before triggering the next one.
  • The Azure VM agent and the Backup extension are required to achieve Application or File consistent recovery points. Otherwise, the recovery point will be crash consistent. Be careful of the Azure VM and Backup agents network requirements 
  • The ‘Backup now’ operation does not replace a ‘Snapshot’ mechanism if you want to rapidly restore a VM (The recovery point may take up to 8 hours to be available)
  • Currently, the Restore to a VM is not very customizable : You cannot choose a number of properties like Storage Container, VHDs names, NIC names … To have control of the created VM, you can restore the VHDs to a storage account and use a script or template to create a VM with the configuration of your choice.
  • There is no notification system built-in with Azure backup. So you can’t at this stage configure notifications for the backup jobs statuses. However, there possible alternate methods to do it : When Powershell will be supported, you can create automation scripts which get the Backup jobs statuses and make the notifications. You can also use the Azure Audit logs since the Backup operations are logged within them
  • No Powershell support, but will be released with GA
  • You cannot edit en exiting policy. If you want to change a policy, you will need to create a new one and change the VM’s assignment. Things will change by GA, so no worry
  • You cannot change the vault Redundancy type once you configured at least one backup. You need to change the redundancy  before any data is being transferred to the vault
  • There some limitations about the backup / restore possibilities, I will rephrase here the documentation
    • Backing up virtual machines with more than 16 data disks is not supported.Backing up virtual machines with a reserved IP address and no defined endpoint is not supported.
    • Backing up virtual machines by using the Azure Backup service is supported only for select operating system versions:
      • Linux: See the list of distributions that are endorsed by Azure. Other Bring-Your-Own-Linux distributions also should work as long as the VM agent is available on the virtual machine.
      • Windows Server: Versions older than Windows Server 2008 R2 are not supported.
    • Restoring a domain controller (DC) VM that is part of a multi-DC configuration is not supported.
    • For classic VMs, restore is supported to only new cloud services.
    • Restoring virtual machines that have the following special network configurations is supported through restoring disks to a desired storage account and using PowerShell to attach restored disks to VM configuration of choice. To learn more, see Restoring VMs with special network configurations.
      • Virtual machines under load balancer configuration (internal and external)
      • Virtual machines with multiple reserved IP addresses
      • Virtual machines with multiple network adapters