Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://learn.microsoft.com/en-us/azure/backup/backup-architecture below:

Architecture Overview - Azure Backup

You can use the Azure Backup service to back up data to the Microsoft Azure cloud platform. This article summarizes Azure Backup architecture, components, and processes.

Azure Backup backs up the data, machine state, and workloads running on on-premises machines and Azure virtual machine (VM) instances. There are a number of Azure Backup scenarios.

You can back up machines and data by using a number of methods:

• Back up on-premises machines:

  • You can back up on-premises Windows machines directly to Azure by using the Azure Backup Microsoft Azure Recovery Services (MARS) agent. Linux machines aren't supported.
  • You can back up on-premises machines to a backup server - either System Center Data Protection Manager (DPM) or Microsoft Azure Backup Server (MABS). You can then back up the backup server to a Recovery Services vault in Azure.

• Back up Azure VMs:

  • You can back up Azure VMs directly. Azure Backup installs a backup extension to the Azure VM agent that's running on the VM. This extension backs up the entire VM.
  • You can back up specific files and folders on the Azure VM by running the MARS agent.
  • You can back up Azure VMs to the MABS that's running in Azure, and you can then back up the MABS to a Recovery Services vault.

Learn more about what you can back up and about supported backup scenarios.

Azure Backup stores backed-up data in vaults - Recovery Services vaults and Backup vaults. A vault is an online-storage entity in Azure that's used to hold data, such as backup copies, recovery points, and backup policies.

Vaults have the following features:

• Vaults make it easy to organize your backup data, while minimizing management overhead.
• You can monitor backed-up items in a vault, including Azure VMs and on-premises machines.
• You can manage vault access with Azure role-based access control (Azure RBAC).
• You specify how data in the vault is replicated for redundancy:
  • Locally redundant storage (LRS): To protect your data against server rack and drive failures, you can use LRS. LRS replicates your data three times within a single data center in the primary region. LRS provides at least 99.999999999% (11 nines) durability of objects over a given year. Learn more
  • Geo-redundant storage (GRS): To protect against region-wide outages, you can use GRS. GRS replicates your data to a secondary region. Learn more.
  • Zone-redundant storage (ZRS): replicates your data in availability zones, guaranteeing data residency and resiliency in the same region. Learn more
  • By default, Recovery Services vaults use GRS.

Recovery Services vaults have the following additional features:

• In each Azure subscription, you can create up to 500 vaults.

Azure Backup provides different backup agents, depending on what type of machine is being backed up:

• Runs on individual on-premises Windows Server machines to back up files, folders, and the system state.
• Runs on Azure VMs to back up files, folders, and the system state.
• Runs on DPM/MABS servers to back up the DPM/MABS local storage disk to Azure.

The following table explains the different types of backups and when they're used:

Inefficient because data blocks that are unchanged between later backups are transferred and stored.

With incremental backup, there's no need to supplement with full backups.

The following table explains the different types of backups used for SQL Server databases and how often they're used:

You can choose to make a full backup on a daily or weekly interval.

It captures only the data that's changed since the full backup.

You can't configure a full backup and a differential backup on the same day.

The following table explains the different types of backups used for SAP HANA databases and how often they're used:

You can choose to schedule a full backup on a daily or weekly interval.

It captures only the data that's changed since the previous full backup.

You can't configure a full backup and a differential backup on the same day.

It captures only the data that's changed since this previous data backup.

You can't schedule both differential and incremental backups on a database, only one delta backup type can be scheduled.

You can't configure a full backup and a differential backup on the same day.

Storage consumption, recovery time objective (RTO), and network consumption varies for each type of backup. The following image shows a comparison of the backup types:

• Data source A is composed of 10 storage blocks, A1-A10, which are backed up monthly.
• Blocks A2, A3, A4, and A9 change in the first month, and block A5 changes in the next month.
• For differential backups, in the second month changed blocks A2, A3, A4, and A9 are backed up. In the third month, these same blocks are backed up again, along with changed block A5. The changed blocks continue to be backed up until the next full backup happens.
• For incremental backups, in the second month blocks A2, A3, A4, and A9 are marked as changed and transferred. In the third month, only changed block A5 is marked and transferred.

The following table summarizes the supported features for the different types of backup:

• A backup policy is created per vault.
• A backup policy can be created for the backup of following workloads: Azure VMs, SQL in Azure VMs, SAP HANA in Azure VMs and Azure file shares. The policy for files and folder backup using the MARS agent is specified in the MARS console.
  • Azure File Share
• A policy can be assigned to many resources. An Azure VM backup policy can be used to protect many Azure VMs.
• A policy consists of two components
  • Schedule: When to take the backup
  • Retention: For how long each backup should be retained.
• Schedule can be defined as "daily" or "weekly" with a specific point of time.
• Retention can be defined for "daily", "weekly", "monthly", "yearly" backup points.
  • "weekly" refers to a backup on a certain day of the week
  • "monthly" refers a backup on a certain day of the month
  • "yearly" refers to a backup on a certain day of the year
• Retention for "monthly", "yearly" backup points is referred to as Long Term Retention (LTR)
• When a vault is created, a "DefaultPolicy" is also created and can be used to back up resources.
• Any changes made to the retention period of a backup policy will be applied retroactively to all the older recovery points aside from the new ones.

• Retention duration is increased / decreased: When the retention duration is changed, the new retention duration is applied to the existing recovery points as well. As a result, some of the recovery points will be cleaned up. If the retention period is increased, the existing recovery points will have an increased retention as well.
• Changed from daily to weekly: When the scheduled backups are changed from daily to weekly, the existing daily recovery points are cleaned up.
• Changed from weekly to daily: The existing weekly backups will be retained based on the number of days remaining according to the current retention policy.

• Azure VM machine: How to create and modify policy.
• SQL Server database in Azure VM machine: How to create and modify policy.
• Azure File share: How to create and modify policy.
• SAP HANA: How to create and modify policy.
• MARS: How to create and modify policy.
• Are there any limitations on scheduling backup based on the type of workload?
• What happens to the existing recovery points if I change the retention policy?

1. For Azure VMs that are selected for backup, Azure Backup starts a backup job according to the backup schedule you specify.

2. If you have opted for application or file-system consistent backups, the VM needs to have a backup extension installed to coordinate for the snapshot process.

   If you have opted for crash-consistent backups, no agents are required in the VMs.

3. During the first backup, a backup extension is installed on the VM if the VM is running.

   • For Windows VMs, the VMSnapshot extension is installed.
   • For Linux VMs, the VMSnapshotLinux extension is installed.

4. For Windows VMs that are running, Azure Backup coordinates with Windows Volume Shadow Copy Service (VSS) to take an app-consistent snapshot of the VM.

   • By default, Backup takes full VSS backups.
   • If Backup can't take an app-consistent snapshot, then it takes a file-consistent snapshot of the underlying storage (because no application writes occur while the VM is stopped).

5. For Linux VMs, Backup takes a file-consistent backup. For app-consistent snapshots, you need to manually customize pre/post scripts.

6. For Windows VMs, Microsoft Visual C++ 2015 Redistributable (x64) version 14.40.33810.0 is installed, the startup of Volume Shadow Copy Service (VSS) is changed to automatic, and a Windows Service IaaSVmProvider is added.

7. After Backup takes the snapshot, it transfers the data to the vault.

   • The backup is optimized by backing up each VM disk in parallel.
   • For each disk that's being backed up, Azure Backup reads the blocks on the disk and identifies and transfers only the data blocks that changed (the delta) since the previous backup.
   • Snapshot data might not be immediately copied to the vault. It might take some hours at peak times. Total backup time for a VM will be less than 24 hours for daily backup policies.

1. To set up the scenario, you download and install the MARS agent on the machine. You then select what to back up, when backups will run, and how long they'll be kept in Azure.
2. The initial backup runs according to your backup settings.
3. The MARS agent uses VSS to take a point-in-time snapshot of the volumes selected for backup.
   • The MARS agent uses only the Windows system write operation to capture the snapshot.
   • Because the agent doesn't use any application VSS writers, it doesn't capture app-consistent snapshots.
4. After taking the snapshot with VSS, the MARS agent creates a virtual hard disk (VHD) in the cache folder you specified when you configured the backup. The agent also stores checksums for each data block. These are later used to detect changed blocks for subsequent incremental backups.
5. Incremental backups run according to the schedule you specify, unless you run an on-demand backup.
6. In incremental backups, changed files are identified and a new VHD is created. The VHD is compressed and encrypted, and then it's sent to the vault.
7. After the incremental backup finishes, the new VHD is merged with the VHD created after the initial replication. This merged VHD provides the latest state to be used for comparison for ongoing backup.

1. You install the DPM or MABS protection agent on machines you want to protect. You then add the machines to a DPM protection group.
   • To protect on-premises machines, the DPM or MABS server must be located on-premises.
   • To protect Azure VMs, the MABS server must be located in Azure, running as an Azure VM.
   • With DPM/MABS, you can protect backup volumes, shares, files, and folders. You can also protect a machine's system state (bare metal), and you can protect specific apps with app-aware backup settings.
2. When you set up protection for a machine or app in DPM/MABS, you select to back up to the MABS/DPM local disk for short-term storage and to Azure for online protection. You also specify when the backup to local DPM/MABS storage should run and when the online backup to Azure should run.
3. The disk of the protected workload is backed up to the local MABS/DPM disks, according to the schedule you specified.
4. The DPM/MABS disks are backed up to the vault by the MARS agent that's running on the DPM/MABS server.

Azure VMs use disks to store their operating system, apps, and data. Each Azure VM has at least two disks: a disk for the operating system and a temporary disk. Azure VMs can also have data disks for app data. Disks are stored as VHDs.

• VHDs are stored as page blobs in standard or premium storage accounts in Azure:
  • Standard storage: Reliable, low-cost disk support for VMs running workloads that aren't sensitive to latency. Standard storage can use standard solid-state drive (SSD) disks or standard hard disk drive (HDD) disks.
  • Premium storage: High-performance disk support. Uses premium SSD disks.
• There are different performance tiers for disks:
  • Standard HDD disk: Backed by HDDs, and used for cost-effective storage.
  • Standard SSD disk: Combines elements of premium SSD disks and standard HDD disks. Offers more consistent performance and reliability than HDD, but still cost-effective.
  • Premium SSD disk: Backed by SSDs, and provides high-performance and low-latency for VMs that are running I/O-intensive workloads.
• Disks can be managed or unmanaged:
  • Unmanaged disks: Traditional type of disks used by VMs. For these disks, you create your own storage account and specify it when you create the disk. You then need to figure out how to maximize storage resources for your VMs.
  • Managed disks: Azure creates and manages the storage accounts for you. You specify the disk size and performance tier, and Azure creates managed disks for you. As you add disks and scale VMs, Azure handles the storage accounts.

For more information about disk storage and the available disk types for VMs, see these articles:

• Azure managed disks for Linux VMs
• Available disk types for VMs

You can back up Azure VMs by using premium storage with Azure Backup:

• During the process of backing up VMs with premium storage, the Backup service creates a temporary staging location, named AzureBackup-, in the storage account. The size of the staging location equals the size of the recovery point snapshot.
• Make sure that the premium storage account has adequate free space to accommodate the temporary staging location. For more information, see Scalability targets for premium page blob storage accounts. Don't modify the staging location.
• After the backup job finishes, the staging location is deleted.
• The price of storage used for the staging location is consistent with premium storage pricing.

When you restore Azure VMs by using premium storage, you can restore them to premium or standard storage. Typically, you would restore them to premium storage. But if you need only a subset of files from the VM, it might be cost effective to restore them to standard storage.

You can back up Azure VMs with managed disks:

• You back up VMs with managed disks in the same way that you do any other Azure VM. You can back up the VM directly from the virtual machine settings, or you can enable backup for VMs in the Recovery Services vault.
• You can back up VMs on managed disks through RestorePoint collections built on top of managed disks.
• Azure Backup also supports backing up VMs with managed disks that were encrypted by using Azure Disk Encryption.

When you restore VMs with managed disks, you can restore to a complete VM with managed disks or to a storage account:

• During the restore process, Azure handles the managed disks. If you're using the storage account option, you manage the storage account that's created during the restore process.
• If you restore a managed VM that's encrypted, make sure the VM's keys and secrets exist in the key vault before you start the restore process.

With Azure Backup, the vaulted backup data is stored in Microsoft-managed Azure subscription and tenant. External users or guests have no direct access to this backup storage or its contents, ensuring the isolation of backup data from the production environment where the data source resides.

In Azure, all communications and data in transit is securely transferred with HTTPS and TLS 1.2+ protocols. This data remains on the Azure backbone network ensuring reliable and efficient data transmission. The backup data at rest is encrypted by default using Microsoft-managed keys. You can also bring your own keys for encryption if you require greater control over the data. To enhance protection, you can use immutability, which prevents data from being altered or deleted before its retention period. Azure Backup gives you diverse options such as soft delete, stop backup and delete data or retain data if you need to stop backups at any time. To protect critical operations, you can add Multi-User Authorization (MUA) that adds additional layer of protection by using an Azure resource called Azure Resource Guard.

This robust approach ensures that even in a compromised environment, existing backups cannot be tampered with or deleted by unauthorized users.

• Review the support matrix to learn about supported features and limitations for backup scenarios.
• Set up backup for one of these scenarios:
  • Back up Azure VMs.
  • Back up Windows machines directly, without a backup server.
  • Set up MABS for backup to Azure, and then back up workloads to MABS.
  • Set up DPM for backup to Azure, and then back up workloads to DPM.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4