Skip to content

Latest commit

 

History

History
146 lines (128 loc) · 10.1 KB

3.6. Backup (Azure Backup & Azure Site Recovery).md

File metadata and controls

146 lines (128 loc) · 10.1 KB
Raw

Backup

Azure Backup

  • Backup as a service (BaaS) solution with tools in the cloud and for on-premises
  • Data is stored in a Storage Account.
    • Azure Backup Server
      • Can be installed on Azure or on-premises and can back up VMs.
      • Inherits much of the workload backup functionality from Data Protection Manager (DPM).
      • Backs up in Site Recovery vault.
      • Can back up File servers, SQL Server, Hyper-V, Exchange Server
  • In a seamless portal experience with Azure Site Recovery, gives you cost-efficiency and minimal maintenance, consistent tools for offsite backups and operational recovery, and unified application availability and data protection.
  • There are three primary options for backing up to Azure Backup:
    1. Azure Backup / Restore of On-Premises Files & Folders
      • 💡 Ideal for backing up Files & Folders only
      • Steps:
        1. Deploy the Azure Backup Agent (Azure Recovery Services Agent) on the VM guests running on-premises Hyper-V / SCVMM / Vmware / Physical infrastructure.
        2. Configure Azure Backup from within the VM guest.
        3. Configure the integration with Azure Backup Vault.
        4. Run the Backup job from within the VM guest.
          • Runs on 443 HTTPS over Public Internet or ExpressRoute with Public Peering
        5. Files & Folders backup will be stored in Azure Backup Vault, and can be restored from there.
    2. Azure Backup / Restore of On-premises running full workloads (OS, Sysvol and Applications)
      • 💡 Better for backing up full system workloads (OS, system state, applications – consistent)
      • Steps:
        1. Deploy the Azure Backup Server (or System Center DPM 2012 R2 or 2016) on the on-premises Hyper-V / SCVMM / Vmware / Physical infrastructure.
        2. Configure Azure Backup Server backup policies, backup storage (2-tier) and deploy agents to your workloads.
        3. Configure the integration with Azure Backup Vault.
        4. Run the Backup job from within the Azure Backup Server console.
          • Runs on 443 HTTPS over Public Internet or ExpressRoute with Public Peering
        5. VM workloads (system state, OS, applications,…) backup will be stored in Azure Backup Vault, and can be restored from there.
    3. Azure VM Backup / Restore to Azure Backup Vault
      • 💡 Best for when you want to backup Azure VMs to Azure Backup Vault
      • Steps:
        • Deploy the Azure Backup Extension, or select Azure Backup in the VM configuration.
        • Configure Azure Backup backup policies, in the Azure platform.
        • Configure the integration with Azure Backup Vault.
        • Run the Backup job from within the Azure Platform.
          • Runs on 443 HTTP over Azure Backbone Infrastructure.
        • Azure VMs will be backed up as full VM snapshots, and can be restored from within the Azure Portal.
  • Allows application consistent backups in Linux environments
    • ❗ You need to run a pre- and post- backup script.
    • The VM Snapshot will be your VM Backup
      • Stored in the Backup Vault using an incremental update process

Hybrid Backup Encryption

  • Allows for end-to-end encryption of the backup platform:
  • It starts with a passphrase for the Azure Recovery Services Agent installation.
  • The next layer is the Backup Data itself, which gets encrypted in transit.
  • Once the data is stored in Azure Backup Vault, it gets encrypted at rest as well.

Monitoring

  • Azure Backup monitoring is possible from Log Analytics.
  • Out of Log Analytics, one can get a detailed view on the backup statistics, the amount of data that is being consumed, successful and failed jobs and alike.
  • Azure Backup allows for reporting integration with Microsoft Power BI.

Microsoft System Center Data Protection Manager (DPM)

  • Underlying infrastructure of Azure Back-up
  • Backs up both on-prem servers/VMs & cloud VMs
  • Can store back-up data to:
    • Disk: For short-term storage DPM backs up data to disk pools.
    • Azure: DPM data stored in disk pools can be backed up to the Microsoft Azure cloud using the Azure Backup service
    • Tape
  • Features:
    • Application-aware backup: Application-aware back up of Microsoft workloads, including SQL Server, Exchange, and SharePoint.
    • File backup: Back up files, folders and volumes for computers running Windows server and Windows client operating systems.
    • System backup: Back up system state or run full, bare-metal backups of physical computers running Windows server or Windows client operating systems.
    • Hyper-V backup: Back up Hyper-V virtual machines (VM) running Windows or Linux. You can back up an entire VM, or run application-aware backups of Microsoft workloads on Hyper-V VMs running Windows.
  • Microsoft Azure Backup Server (MABS)
    • Can be installed on Azure or on-premises and can back up VMs.
    • Inherits much of the workload backup functionality from Data Protection Manager (DPM).
    • Backs up in Site Recovery vault.
    • Can back up File servers, SQL Server, Hyper-V, Exchange Server

Azure Site Recovery

  • Built to provide a data center disaster recovery solution for your VM workloads to Azure.
    • Recovers from
      • Hyper-V
      • VMware
      • Physical hosts
      • AWS VMs
  • Replication-based failover to Azure Virtual Machines
  • Failover & Failback
  • Application-consistent failover
  • Good as VM lift & shift migration and for dev/test scenarios
    • Full machine-state replication to an Azure VM
    • Zero-data loss during migration

Replication policies

  • 📝 Recovery Point Objective (RPO) is the maximum time of acceptance for data loss.
  • 📝 Recovery Time Objective (RTO) in ASR means the period when a failover starts to the time the process completes and a virtual machine is running in Azure.
  • 📝 App-consistent snapshots capture disk data, all data in memory, and all transactions in process.

Running a failover

  • On portal: Recovery Plans > recovery plan name > Click "Failover"
  • You can alternatively run failover from "Replicated Items"
  • 📝 Select a Recovery Point to failover to
    • Latest
      • Processes all data that's sent to Site Recovery service.
      • Creates a recovery point for each virtual machine
        • Used by VM during failover.
      • Lowest data loss (RPO, recovery point objective)
        • As VM created after failover has all the data that has been replicated to Site Recovery service when the failover was triggered.
    • Latest processed
      • Fails over all virtual machines of the recovery plan to the latest recovery point that has already been processed by Site Recovery service.
      • If you are doing failover of a recovery plan, you can go to individual virtual machine and look at Latest Recovery Points tile to get this information.
      • Low recovery time (RTO, recovery time objective)
        • As no time is spent to process the unprocessed data.
    • Latest app-consistent
      • Fails over all virtual machines of the recovery plan to the latest application consistent recovery point that has already been processed by Site Recovery service.
      • When you are doing test failover of a virtual machine, time stamp of the latest app-consistent recovery point is also shown.
      • If you are doing failover of a recovery plan, you can go to individual virtual machine and look at Latest Recovery Points tile to get this information.
    • Latest multi-VM processed
      • This option is only available for recovery plans that have at least one virtual machine with multi-VM consistency ON.
      • VMs that are part of a replication group failover to the latest common multi-VM consistent recovery point.
      • Other virtual machines failover to their latest processed recovery point.
    • Latest multi-VM app-consistent
      • Only available for recovery plans that have at least one virtual machine with multi-VM consistency ON.
      • Virtual machines that are part of a replication group failover to the latest common multi-VM application-consistent recovery point.
      • Other virtual machines failover to their latest application-consistent recovery point.
    • Custom
      • If you are doing test failover of a virtual machine, then you can use this option to failover to a particular recovery point.
      • ❗Only supported when failing over to Azure.

Azure Backup vs Azure Site Recovery

  • Azure Backup is used to protect and restore data at a more granular level.

    • E.g. if some files become corrupted, you can use Azure Backup to restore them

  • Azure Site Recovery is used to replicate the configuration and data of a system to another data center, then you would use.

    Concept Explanation Backup Disaster Recovery (DR)
    Recovery point objective (RPO) The amount of acceptable data loss if a recovery needs to be done. Wide variability in their acceptable RPO. E.g. VM backups usually 1 day, DB backups 15 minutes. Low RPOs. The DR copy can be behind by a few seconds or a few minutes.
    Recovery time objective (RTO) The amount of time that it takes to complete a recovery or restore. Larger RPO -> the amount of data needed to process is much higher -> leads to longer RTOs. E.g. days to restore data from tapes, depending on the time it takes to transport the tape from an off-site location. Smaller RTOs because they are more in sync with the source. Fewer changes need to be processed.
    Retention How long data needs to be stored For scenarios that require operational recovery (e.g. data corruption, inadvertent file deletion, OS failure), backup data is typically retained for 30 days or less. 💡 From a compliance standpoint, data might need to be stored for months or even years. Backup data is ideally suited for archiving in such cases. Needs only operational recovery data, which typically takes a few hours or up to a day. 💡 Because of the fine-grained data capture used in DR solutions, using DR data for long-term retention is not recommended.
    Product Use cases
    Azure Backup • Accidental deletion • Patch Testing • Alternative location recovery • Security • Long-term data retention
    Azure Site Recovery • Disaster Recovery with quick failover • Migration • Dev/Test Environment (e.g. test failover)