In this blog post Azure Backup Item Level Recovery Checklist for Premium SSD v2 we will explain how to recover individual files and folders without restoring an entire Azure virtual machine, and how to confirm the process will work before an outage puts the business under pressure.
This matters because a successful backup notification does not guarantee a fast recovery. Your team may discover too late that the selected backup policy, encryption configuration, permissions or recovery computer prevents a straightforward file restore.
What item-level recovery means for your business
Premium SSD v2 is Microsoft’s high-performance storage for Azure virtual machines. It is commonly used for databases, finance systems and other applications that need fast, consistent disk performance.
Item-level recovery, sometimes called ILR, lets an authorised administrator open a selected Azure VM recovery point and copy out specific files or folders. Instead of rebuilding a complete server to recover one deleted document, the team temporarily mounts the backed-up disks and retrieves only what is needed.
CPI Consulting helps organisations design, build and secure Azure AI solutions, from Azure OpenAI and Microsoft Foundry to agents, governance and production deployment.
Visit CPI ConsultingMicrosoft now supports this process for Premium SSD v2 and Ultra Disk, including disks using 512-byte and 4-KB logical sector sizes. It can also expose eligible disks from virtual machines that contain a mixture of supported disk types.
That is a useful improvement, but it does not make every recovery scenario automatic. As we discussed in our overview of Azure Backup recovery for Premium SSD v2 and Ultra Disk, the real question is not simply whether the feature exists. It is whether your configuration, people and recovery plan can use it reliably.
How the recovery technology works
Azure Backup stores recovery points for a protected virtual machine in a Recovery Services vault, which is Azure’s protected container for VM backups. An administrator selects a recovery point and downloads a temporary recovery executable for Windows or a Python-based script for Linux.
Running that file creates a secure, temporary connection to the recovery point. The backed-up volumes appear on the recovery computer so the administrator can browse them and copy the required data to a safe location.
The process does not restore data directly over the production server. This reduces the chance of accidentally replacing current information, but your team still needs to validate the recovered file before returning it to users.
The five-part recoverability checklist
1. Confirm the workload is actually protected
- Verify that the complete Azure virtual machine is protected by a Recovery Services vault.
- Confirm the VM uses an Enhanced backup policy. This is the newer Azure VM policy required to protect Premium SSD v2 and Ultra Disk workloads.
- Check that recent backup jobs completed successfully and produced usable recovery points.
- Confirm the backup frequency matches the amount of data the business can afford to lose.
- Review retention periods against operational, contractual and regulatory requirements.
Enhanced policies can support multiple backups per day, with schedules as frequent as every four hours. More frequent backups can reduce the recovery point objective, meaning the maximum period of recent data the business might lose.
Do not assume every system needs the same schedule. A payroll platform may need a four-hour recovery point, while an internal archive may only require a daily backup.
2. Check whether item-level recovery is supported
- Confirm the VM was deployed using the Azure Resource Manager model used for modern Azure environments.
- Record whether each disk is Standard HDD, Standard SSD, Premium SSD v1, Premium SSD v2 or Ultra Disk.
- For Linux workloads, verify that the operating system and file system are supported.
- Identify guest-level disk encryption or special storage configurations before an incident.
- Confirm that the chosen recovery computer can read the source file system.
Windows and common Linux distributions such as Ubuntu, Red Hat Enterprise Linux, Debian, Oracle Linux, SUSE Linux Enterprise Server and openSUSE are supported for Premium SSD v2 item-level recovery. Exact versions and configurations should still be checked during testing.
Encryption deserves particular attention. Normal Azure encryption at rest does not mean your backups are unprotected. However, some encrypted VM configurations, including Azure Disk Encryption scenarios, do not support file-and-folder recovery and may require a full disk or VM restore instead.
3. Choose the right recovery method
Item-level recovery is designed for small, targeted restores. Microsoft’s current guidance recommends it when the total recovery is 10 GB or less, with expected transfer speeds of around 1 GB per hour.
That makes it suitable for a deleted spreadsheet, application configuration folder or small collection of documents. It is usually the wrong method for recovering hundreds of gigabytes after ransomware or major storage corruption.
- Use item-level recovery for a small number of known files or folders.
- Restore a disk when a large volume of data must be inspected or recovered.
- Restore the VM when the operating system or complete application stack has failed.
- Use application-aware recovery for databases and transactional systems that require data consistency.
Copying a database file from a VM backup is not automatically the same as completing a valid database restore. SQL Server and similar platforms may require application-specific backups, logs and recovery procedures.
4. Prepare access, people and a recovery computer
The recovery file is time-limited and normally becomes invalid after 12 hours. Waiting until an incident to arrange administrator access, network rules or a suitable recovery computer can turn a simple request into a day-long outage.
- Assign recovery permissions to named roles rather than general IT accounts.
- Require multi-factor authentication for administrators.
- Maintain a hardened Windows or Linux recovery computer with enough free storage.
- Confirm it can reach the Azure services required by the recovery process.
- Document who can approve a restore and who validates the recovered information.
- Close the recovery session after copying and validating the files.
Use separate backup administration accounts where practical. This limits the ability of a compromised everyday administrator account to modify backup settings or interfere with recovery operations.
5. Test the complete business process
A technical test is not complete when a file appears in a folder. The business owner must confirm that it is the right version, opens correctly, contains the expected information and can be safely returned to production.
- Select a representative Premium SSD v2 workload.
- Choose a recovery point from a defined date and time.
- Download and run the recovery file from the approved recovery computer.
- Locate and copy a nominated test file.
- Scan the recovered file before opening or returning it to production.
- Ask the system or data owner to validate the result.
- Record the time taken, issues encountered and approvals received.
- Close the mounted recovery session and remove temporary data securely.
Track both the recovery point objective and the recovery time objective, which is how quickly the business expects service or data to be restored. These measures turn backup discussions into decisions leaders can understand.
A realistic mid-market recovery scenario
Consider a 200-person professional services company running its document management application on an Azure VM with Premium SSD v2 data disks. A user accidentally removes a project folder containing several hundred files.
A full VM restore could create unnecessary disruption, consume additional Azure resources and force the team to reconcile old and current data. With a tested item-level process, IT can select a suitable recovery point, mount the backed-up volume and copy only the missing folder.
The business outcome is not merely a technically successful restore. It is fewer billable hours lost, less interruption for employees and a lower chance of damaging current production data.
Turn each test into compliance evidence
The Essential Eight, the Australian government’s baseline cybersecurity framework, includes regular backups as one of its core strategies. The Australian Signals Directorate also expects organisations to test restoration as part of disaster recovery exercises, rather than discovering problems during a real incident.
Keep a simple evidence pack containing the workload tested, recovery point used, approvals, results, elapsed time and any corrective actions. This supports audits, cyber insurance reviews and management reporting.
A green backup dashboard only shows that a job ran. Our guide to turning Azure Backup inventory into recovery decisions explains how to connect technical protection data with business ownership and recovery priorities.
What good recovery readiness looks like
A recoverable Azure environment has more than backup policies. It has named owners, documented recovery paths, secured administrative access and evidence from recent tests.
It should also form part of a wider resilience plan covering ransomware, regional outages and application-specific recovery. The Azure platform resilience checklist for Australian CIOs provides a useful starting point for that broader review.
CloudProInc combines more than 20 years of enterprise IT experience with practical Azure and cybersecurity delivery. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations test what will actually happen during recovery rather than relying on assumptions or dashboard status.
If you are not sure whether your Premium SSD v2 workloads can recover individual files within the time the business expects, we are happy to review the setup and identify the gaps — no strings attached.