Urgent – Temporary/Resource Disk Data Loss After Unexpected VM Restart – Recovery Assistance Needed

Question

Urgent – Temporary/Resource Disk Data Loss After Unexpected VM Restart – Recovery Assistance Needed

Vincent ARTZ 0

Subject: Urgent – Temporary/Resource Disk Data Loss After Unexpected VM Restart – Recovery Assistance Needed

Description:
We are reaching out urgently regarding a potential data loss incident on one of our Azure Virtual Machines.
What happened:
Our VM became inaccessible via SSH without any apparent reason — the machine showed no signs of being overloaded or saturated at the time. With no other option to restore access, we performed a restart of the VM.
After the restart, the temporary/resource disk (which was previously holding approximately 250 GB of data) now appears to contain only a few kilobytes. The disk is still visible in df -h, but its content appears to have been reset or replaced with an empty disk. This disk does not appear as a managed disk in our Azure resource group, which we understand is expected behavior for a temporary/local disk.
Important – Please do not modify the VM state:
To maximize the chances of data recovery, we ask that no action be taken on this VM until further notice. Specifically, please do not:

Stop or deallocate the VM
Restart, redeploy, resize, or migrate it
Reformat, remount, or reinitialize the temporary disk

What we need from Azure:

Root cause of SSH inaccessibility – Was there an Azure platform event (incident, maintenance, live migration, reprovisioning) that caused our VM to become unreachable? We had no indication of any issue on our end.
Physical host continuity – Is the VM currently running on the same physical host as before the restart? Or did a host change occur?
Status of the old temporary disk – Does the original temporary/resource disk still exist on the previous physical host, either attached or detached? Is there any possibility to preserve, reattach, or copy its contents? It was on docker in a temporary folder
Nature of the restart event – Did the platform event trigger a deallocation, redeployment, or host migration rather than a simple in-place reboot? This is critical to understanding whether data recovery is feasible.

Even without a backup policy in place, Azure infrastructure may be the only party able to verify whether the original disk still exists at the physical level. Any assistance in preserving or recovering that data would be greatly appreciated.

Thank you for treating this as urgent.

0 commentaires

1 réponse

Votre réponse

Answer 1

Hello Vincent ARTZ,

Thank you for reaching out and providing the detailed description of the issue.

Based on the information shared, it is important to note that the Azure temporary/resource disk is intended for non-persistent storage. Data stored on this disk is not guaranteed to persist through certain VM and infrastructure events and may be lost if the VM is moved to different underlying hardware or if the temporary disk is reprovisioned.

The temporary/resource disk is not a managed disk and is not backed by Azure Managed Disk storage. As a result, there is no supported method to recover previous contents of a temporary disk after it has been reinitialized or replaced.

Regarding your questions about the cause of the SSH inaccessibility, potential platform events, host continuity, or whether a host migration/redeployment occurred, these details cannot be investigated through the Microsoft Q&A forum because they require access to subscription-specific telemetry and backend diagnostics.

To facilitate further investigation, I have shared a private message containing instructions for creating a support request and securely providing the required information. Once the requested details are provided through the support channel, we can review the available platform telemetry and determine whether any infrastructure events occurred around the time of the incident.

Please note that while a backend investigation may help determine whether an Azure platform event occurred, recovery of data previously stored on the temporary/resource disk cannot be guaranteed.

For future workloads, we recommend storing application and business-critical data on Azure Managed Disks or other persistent storage services. Temporary/resource disks should only be used for transient data such as cache, scratch space, swap files, or other data that can be recreated if lost.

I hope this information is helpful. Please review the private message and let us know if you have any further questions.