Back up Windows Server files and folders to Azure
This article describes how to back up Windows machines by using the Azure Backup service and the Microsoft Azure Recovery Services (MARS) agent. MARS is also known as the Azure Backup agent.
Before you start
- Learn how Azure Backup uses the MARS agent to back up Windows machines.
- Learn about the backup architecture that runs the MARS agent on a secondary MABS or Data Protection Manager server.
- Review what's supported and what you can back up by the MARS agent.
- Verify internet access on the machines that you want to back up.
- If the MARS agent isn't installed, learn how to install it here.
Create a backup policy
The backup policy specifies when to take snapshots of the data to create recovery points. It also specifies how long to keep recovery points. You use the MARS agent to configure a backup policy.
Azure Backup doesn't automatically take daylight saving time (DST) into account. This default could cause some discrepancy between the actual time and the scheduled backup time.
To create a backup policy, follow these steps:
After you download and register the MARS agent, open the agent console. You can find it by searching your machine for Microsoft Azure Backup.
Under Actions, select Schedule Backup.
In the Schedule Backup Wizard, select Getting started > Next.
Under Select Items to Back up, select Add Items.
In the Select Items box, select items to back up, and then select OK.
On the Select Items to Back Up page, select Next.
On the Specify Backup Schedule page, specify when to take daily or weekly backups. Then select Next.
A recovery point is created when a backup is taken.
The number of recovery points created in your environment depends on your backup schedule.
You can schedule up to three daily backups per day. In the following example, two daily backups occur, one at midnight and one at 6:00 PM.
You can run weekly backups too. In the following example, backups are taken every alternate Sunday and Wednesday at 9:30 AM and 1:00 AM.
On the Select Retention Policy page, specify how to store historical copies of your data. Then select Next.
Retention settings specify which recovery points to store and how long to store them.
For a daily retention setting, you indicate that at the time specified for the daily retention, the latest recovery point will be retained for the specified number of days. Or you could specify a monthly retention policy to indicate that the recovery point created on the 30th of every month should be stored for 12 months.
Retention for daily and weekly recovery points usually coincides with the backup schedule. So when the schedule triggers a backup, the recovery point (that the backup operation creates) is stored for the duration that the daily or weekly retention policy specifies.
In the following example:
- Daily backups at midnight and 6:00 PM are kept for seven days.
- Backups taken on a Saturday at midnight and 6:00 PM are kept for four weeks.
- Backups taken on the last Saturday of the month at midnight and 6:00 PM are kept for 12 months.
- Backups taken on the last Saturday in March are kept for 10 years.
On the Choose Initial Backup Type page, decide if you want to take the initial backup over the network or use offline backup. To take the initial backup over the network, select Automatically over the network > Next.
For more information about offline backup, see Use Azure Data Box for offline backup.
On the Confirmation page, review the information, and then select Finish.
After the wizard finishes creating the backup schedule, select Close.
Create a policy on each machine where the agent is installed.
Run the initial backup offline
You can run an initial backup automatically over the network, or you can back up offline. Offline seeding for an initial backup is useful if you've large amounts of data that will require a lot of network bandwidths to transfer.
To do an offline transfer, follow these steps:
Write the backup data to a staging location.
Use the AzureOfflineBackupDiskPrep tool to copy the data from the staging location to one or more SATA disks.
The tool creates an Azure Import job. For more information, see What is the Azure Import/Export service.
Send the SATA disks to an Azure datacenter.
At the datacenter, the disk data is copied to an Azure storage account. Azure Backup copies the data from the storage account to the vault, and incremental backups are scheduled.
For more information about offline seeding, see Use Azure Data Box for offline backup.
Enable network throttling
You can control how the MARS agent uses network bandwidth by enabling network throttling. Throttling is helpful if you need to back up data during work hours but you want to control how much bandwidth the backup and restore activity uses.
Network throttling in Azure Backup uses Quality of Service (QoS) on the local operating system.
Network throttling for backups is available on Windows Server 2012 and later, and on Windows 8 and later. Operating systems should be running the latest service packs.
To enable network throttling:
In the MARS agent, select Change Properties.
On the Throttling tab, select Enable internet bandwidth usage throttling for backup operations.
Specify the allowed bandwidth during work hours and nonwork hours. Bandwidth values begin at 512 Kbps and go up to 1,023 Mbps. Then select OK.
Run an on-demand backup
To run an on-demand backup, follow these steps:
In the MARS agent, select Back Up Now.
If the MARS agent version is 2.0.9254.0 or newer, select a subset of the volumes backed up periodically for on-demand backup. Only the files/folders configured for periodic backup can be backed up on demand.
If the MARS agent version is 2.0.9169.0 or newer, set a custom retention date. In the Retain Backup Till section, choose a date from the calendar.
On the Confirmation page, review the settings, and select Back Up.
Select Close to close the wizard. If you close the wizard before the backup finishes, the wizard continues to run in the background.
After the initial backup finishes, the Job completed status appears in the Backup console.
Set up on-demand backup policy retention behavior
The following table shows the data retention duration for various backup schedules:
Backup-schedule option | Duration of data retention |
---|---|
Day | Default retention: Equivalent to the "retention in days for daily backups." Exception: If a daily scheduled backup that's set for long-term retention (weeks, months, or years) fails, an on-demand backup that's triggered right after the failure is considered for long-term retention. Otherwise, the next scheduled backup is considered for long-term retention. Example scenario: The scheduled backup on Thursday at 8:00 AM failed. This backup was to be considered for weekly, monthly, or yearly retention. So the first on-demand backup triggered before the next scheduled backup on Friday at 8:00 AM is automatically tagged for weekly, monthly, or yearly retention. This backup substitute for the Thursday 8:00 AM backup. |
Week | Default retention: One day. On-demand backups that are taken for a data source that has a weekly backup policy are deleted the next day. They're deleted even if they're the most recent backups for the data source. Exception: If a weekly scheduled backup that's set for long-term retention (weeks, months, or years) fails, an on-demand backup that's triggered right after the failure is considered for long-term retention. Otherwise, the next scheduled backup is considered for long-term retention. Example scenario: The scheduled backup on Thursday at 8:00 AM failed. This backup was to be considered for monthly or yearly retention. So the first on-demand backup that's triggered before the next scheduled backup on Thursday at 8:00 AM is automatically tagged for monthly or yearly retention. This backup substitute for the Thursday 8:00 AM backup. |
For more information, see Create a backup policy.
Note
This information applies only to MARS agent versions that are older than 2.0.9169.0.
Next steps
- Learn how to Restore files in Azure.
- Find Common questions about backing up files and folders
Feedback
https://aka.ms/ContentUserFeedback.
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see:Submit and view feedback for