Azure Backup & Restore

Overview

Lucidity AutoScaler is a multi-cloud storage management platform that autonomously resizes block storage across AWS, Azure, and Google Cloud. It dynamically expands and shrinks storage volumes based on actual data usage patterns, helping enterprises optimize storage utilization and reduce storage costs by up to 70%. These optimizations are achieved without requiring any application code changes or causing downtime.

Lucidity AutoScaler is fully compatible with Azure Backup—a native cloud-based backup solution from Microsoft that helps protect and restore data for Azure Virtual Machines (VMs). The integration works seamlessly across backup and restore operations.

Azure Backup: How It Works for VMs

1. Enable Azure Backup
   Configure Azure Backup using a Recovery Services Vault.

2. Define a Backup Policy
   Specify frequency (daily/weekly), retention period, and consistency options.

3. Snapshot Creation
   Azure Backup takes point-in-time snapshots of the managed disks attached to the VM.

4. Transfer to Recovery Services Vault
   Snapshots are securely transferred and stored in the Recovery Services Vault. There is no impact on production workloads.

5. Snapshot Consistency Options

   • Crash-consistent backup: Captures disk state at the time of backup; no app-level consistency.

   • File-consistent or Application-consistent backup: Achieved using an agent; ensures all app data is flushed to disk for a consistent state.
     See more: Snapshot Consistency

Restore Options with Azure Backup

Regardless of the backup consistency model chosen, Azure Backup offers the following restore options:

• File Recovery
  Recover individual files and folders from a restore point.

• Restore VM

  • Create new VM: Creates a new VM from the restore point.

  • Restore Disks: Creates new managed disks that can be used to build a new VM.

Lucidity supports all of the above restore options. See full documentation here:
Azure Restore Options

File-Level Restore

Lucidity AutoScaler is fully compatible with Azure Backup's file-level recovery. You can restore files and folders from backed-up VMs that were onboarded to Lucidity without requiring any changes or additional configuration.

High-Level Steps

1. Go to the Virtual Machine
   In the Azure portal, navigate to the Backup section of the VM.

2. Check Restore Points
   View available restore points created by Azure Backup.

3. Choose “File Recovery”
   Select a restore point and choose the "File Recovery" option.
    

4. Download Recovery Script
   Azure generates a script (Windows executable or Linux shell script) to mount the snapshot.

5. Run the Script on a Target VM
   Copy the script to any VM (not the original backed-up VM) and run it. This machine can be standalone or managed by Lucidity.
    

6. Mounts as New Drive
   Within minutes, the backup is mounted as a new volume over iSCSI. 

7. Browse and Recover Files
   Navigate the snapshot and copy required files to the local VM.
    

8. Unmount
   Manually unmount or allow the session to expire automatically.
    

Notes

• The recovery script cannot be run on the same VM that was backed up. Use a different machine. Please refer to Azure Limitation.

• The recovery target can be a Lucidity-managed or unmanaged VM.

VM Restore

Lucidity AutoScaler supports full VM restores using Azure Backup. When restoring a VM that was onboarded to Lucidity, the new VM is automatically detected and onboarded to Lucidity with all attached disks.

High-Level Steps

1. Go to the Virtual Machine
   Open the Azure portal and locate the backed-up VM.

2. Check Restore Points
   Review available backup snapshots.

3. Select “Restore VM”
   Choose the "Restore VM" option and select a restore point.
    

4. Restore Type: “Create New VM”
   Choose to restore as a new virtual machine and provide a new name.
    

5. Start Restore
   Click "Restore" to begin the process. Once complete, the new VM will appear under “Managed VMs” in the Lucidity console.
    

Alternative: Restore Disks

If you choose the “Restore Disks” option on step 4 above:

• Azure creates new managed disks based on the selected restore point.

• These disks can be used to manually build a new VM.
   

• The newly created VM, once launched, will also be automatically onboarded to Lucidity.
   

Important Consideration

Once a VM is onboarded to Lucidity, its disks are pooled and shared rather than dedicated to specific drive letters (e.g., E:). As a result:

• You cannot back up or restore individual drives (e.g., just the E:\ drive) once the VM is managed by Lucidity.

• Backup and restore operations must be applied at the VM level.

Work Around: Drive Level Restore

While Lucidity AutoScaler pools all attached disks and eliminates the concept of fixed drive letters (e.g., E:\), this abstraction can make it challenging to perform drive-level backup and restore operations. However, there is a practical workaround that enables restoring an individual disk.

Objective
To recover a specific disk (drive) from a VM managed by Lucidity, and optionally reuse or attach it to another Lucidity-managed VM.

Steps for Drive-Level Restore

1. Perform a VM-Level Restore from Azure Backup

   • In the Azure portal, select the desired restore point and restore the entire VM.

   • Use the "Create New Virtual Machine" option to avoid overwriting existing workloads. The new VM would automatically appear in the Lucidity dashboard. The steps are highlighted in this guide above. However, please make sure to restore to an isolated network to avoid OS level hostname conflicts.

2. Deboard the Drive from Lucidity

   • Remove the restored VM from Lucidity management using the Lucidity Console - Deboard Option.

   • This returns the disks to a standard Azure-managed state, allowing per-disk operations.
      

Once Deboarding Completes proceed to next steps.

1. Take a Snapshot of the Required Disk

   • Identify the specific disk (e.g., previously known as E:\) you wish to recover.
      

   • Create a snapshot using the Azure portal, CLI, or API.
      
      

Here is code used to identify Drive LUN:

$driveLetter = "E:"

# Get volume info

$volume = Get-WmiObject Win32_Volume | Where-Object { $_.DriveLetter -eq $driveLetter }

# Get the associated partition

$diskPartitions = Get-WmiObject Win32_DiskPartition

$logicalDisks = Get-WmiObject Win32_LogicalDiskToPartition

foreach ($ldtp in $logicalDisks) {

	$partition = ($diskPartitions | Where-Object { $_.DeviceID -eq $ldtp.Antecedent.Split('"')[1] })

	$logicalDisk = $ldtp.Dependent.Split('"')[1]

	if ($logicalDisk -eq $driveLetter) {

    	$driveIndex = $partition.DiskIndex

    	break

	}

}

# Get the LUN from the disk drive

Get-WmiObject Win32_DiskDrive | Where-Object { $_.Index -eq $driveIndex } |

Select-Object DeviceID, PNPDeviceID, SCSILogicalUnit

1. Share or Use the Snapshot

   • Share the snapshot with other teams, or

   • Create a managed disk from the snapshot.

2. Attach the Disk to Another VM

   • The newly created disk can be attached to any VM:

     • A standalone VM

     • A VM already onboarded to Lucidity

3. (Optional) Re-onboard the Disk

   • If the target VM is not yet managed by Lucidity, it can be re-onboarded post-attachment.

   • Lucidity will detect the new disk and include it in the shared storage pool.

Notes

• This method introduces an additional step (deboarding), but ensures access to individual disk-level data.

• Lucidity’s disk pooling is transparent to the VM OS, so once the disk is attached, it behaves like a regular volume.