URGENT DATA RECOVERY REQUEST – Azure VM dc_vm

Question

URGENT DATA RECOVERY REQUEST – Azure VM dc_vm

Design Club 0

Our MySQL/MariaDB database erp on Azure VM dc_vm has lost its original data. The database/tables are not visible . We did not have a MySQL backup configured.
We have investigated the VM and cannot find the original .ibd files or ibdata1. The VM uses an EXT4 filesystem.
We urgently need Microsoft Azure assistance to determine whether an older VM disk, managed-disk snapshot, restore point, Azure Backup recovery point, or any other platform-level recovery option is available.
IMPORTANT: Please advise us before making any changes to the VM/disk because we want to preserve the current disk state and investigate possible EXT4 deleted-file recovery.

Taz 9,526 Reputation points MVP Volunteer Moderator

2026-08-13T07:10:29.77+00:00
Hi,

At this point, avoid making further changes to dc_vm or running filesystem repair tools such as fsck. If deleted-file recovery is being considered, additional writes to EXT4 can overwrite recoverable blocks.

The safest first step is to take a managed-disk snapshot of the affected disk and perform all recovery work on a disk created from that snapshot. Azure snapshots are read-only, crash-consistent copies of managed disks.

Also check these Azure resources for an older copy:

Snapshots in the Azure portal

Recovery Services vault > Backup items > Azure Virtual Machine

Restore Point Collections

Backup vault > Azure Disks, if disk backup was configured

Azure VM backups and restore points can be restored as separate disks, so there is no need to overwrite the current VM.

If none of those existed before the data loss, Azure does not automatically keep historical copies of the contents of a managed disk. In that situation, recovery would need to be attempted at the EXT4 filesystem level from the preserved disk copy.

I would also open an Azure Support request immediately and ask them to verify whether any backup recovery points, disk snapshots, or VM restore points exist for dc_vm before proceeding.
SIVASANKAR YEDDULA 165 Reputation points Microsoft External Staff Moderator

2026-08-17T12:36:52.1033333+00:00

Hi Design Club,

Please share the following details so we can review the recovery options:
VM name Subscription ID / Resource Group Approximate date and time when the data loss occurred Available Azure Backup recovery points or disk snapshots

Once we have these details, we can review the available recovery options and suggest the appropriate recovery approach.

Please share any sensitive or PII details through a private message.
SIVASANKAR YEDDULA 165 Reputation points Microsoft External Staff Moderator

2026-08-20T10:11:04.8366667+00:00

Hi Design Club, We haven’t received a response. Please let us know if you need any additional information or assistance from my side.
Vinodh247-1375 44,556 Reputation points Volunteer Moderator

2026-08-24T16:12:39.9233333+00:00
Here are the key areas I would suggest you to check first:

Azure Managed Disk Snapshots

Review the resource group and subscription for any snapshots associated with the VM's OS disk or data disks.

If a snapshot exists from before the data loss event, you can create a new managed disk from the snapshot and attach it to a recovery VM for investigation.

Azure Backup Recovery Points

Check whether the VM was protected by an Azure Recovery Services Vault.

If Azure Backup was enabled, restore the VM or disks from a recovery point created before the data loss occurred.

VM Restore Points
- Review whether Azure VM Restore Points or Restore Point Collections were created prior to the incident. - These can be used to restore disks to an earlier state. **Recently Detached or Replaced Disks** - Verify the VM activity history and disk configuration to determine whether any managed disks were detached, replaced, or recreated. - In some cases, the original data disk may still exist as a separate managed disk resource. **Preserve the Current Disk State** - Before performing any recovery attempts, create a snapshot of the current affected disk(s). - Avoid running filesystem repair tools, database initialization commands, or actions that may overwrite blocks containing recoverable data. - If EXT4 file-level recovery is being considered, preserving the disk in its current state is essential. **Check Azure Activity Logs** - Review Azure Activity Logs around the time the data disappeared. - This may help identify disk replacement, VM restore operations, snapshot restores, or other administrative actions that could explain the loss of the database files.

If no snapshots, recovery points, restore points, backups, or historical copies of the managed disks exist, Azure does not typically maintain previous versions of VM disks that can be recovered on demand. In that scenario, recovery options would be limited to filesystem-level recovery attempts from the existing disk image.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

1 answer

Your answer

Taz 9,526 Reputation points MVP Volunteer Moderator

2026-08-13T07:10:29.77+00:00

Hi,

At this point, avoid making further changes to dc_vm or running filesystem repair tools such as fsck. If deleted-file recovery is being considered, additional writes to EXT4 can overwrite recoverable blocks.

The safest first step is to take a managed-disk snapshot of the affected disk and perform all recovery work on a disk created from that snapshot. Azure snapshots are read-only, crash-consistent copies of managed disks.

Also check these Azure resources for an older copy:

Snapshots in the Azure portal

Recovery Services vault > Backup items > Azure Virtual Machine

Restore Point Collections

Backup vault > Azure Disks, if disk backup was configured

Azure VM backups and restore points can be restored as separate disks, so there is no need to overwrite the current VM.

If none of those existed before the data loss, Azure does not automatically keep historical copies of the contents of a managed disk. In that situation, recovery would need to be attempted at the EXT4 filesystem level from the preserved disk copy.

I would also open an Azure Support request immediately and ask them to verify whether any backup recovery points, disk snapshots, or VM restore points exist for dc_vm before proceeding.
SIVASANKAR YEDDULA 165 Reputation points Microsoft External Staff Moderator

2026-08-17T12:36:52.1033333+00:00

Hi Design Club,

Please share the following details so we can review the recovery options:
VM name Subscription ID / Resource Group Approximate date and time when the data loss occurred Available Azure Backup recovery points or disk snapshots

Once we have these details, we can review the available recovery options and suggest the appropriate recovery approach.

Please share any sensitive or PII details through a private message.
SIVASANKAR YEDDULA 165 Reputation points Microsoft External Staff Moderator

2026-08-20T10:11:04.8366667+00:00

Hi Design Club, We haven’t received a response. Please let us know if you need any additional information or assistance from my side.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Answer 1

Hi Design Club,

Thank you for reaching out to the Microsoft Q&A forum.

Based on the information provided, the most important recommendation at this stage is to avoid making further changes to the affected VM or disk. Actions such as restarting services, running filesystem repair utilities (fsck), reinstalling MySQL/MariaDB, or creating new files may overwrite disk blocks that could still be recoverable.

As an immediate precaution, we recommend creating a managed-disk snapshot of the affected data disk and performing all recovery attempts against a disk created from that snapshot. This helps preserve the current state of the original disk for further investigation.

To determine whether a platform-level recovery option exists, please verify the following Azure resources:

Azure Snapshots associated with the VM disks.
Recovery Services Vault → Backup Items → Azure Virtual Machine.
Restore Point Collections associated with the VM.
Backup Vault → Azure Disks (if Azure Disk Backup was configured).
Any automation or third-party backup solution that may have created managed-disk snapshots before the data loss.

If Azure VM backups, restore points, or disk snapshots exist from a time prior to the data loss, they can typically be restored to separate disks for investigation without modifying the current VM.

However, if no Azure Backup recovery points, restore points, or snapshots were created before the incident, Azure does not automatically maintain historical copies of managed disk contents. In that scenario, recovery would need to rely on filesystem-level recovery techniques against a preserved copy of the EXT4 disk.

To help determine the available recovery options, please provide:

Subscription ID
Resource Group name
VM name (dc_vm)
Approximate date and time when the data loss was first observed
Confirmation whether Azure Backup, VM Restore Points, or disk snapshots were configured before the incident

If the data is business-critical, we strongly recommend opening an Azure Support request immediately so the support team can help verify whether any Azure Backup recovery points, restore points, or managed-disk snapshots exist for the VM before any recovery actions are performed.

Please share the requested details (excluding any sensitive information) and we will review the available recovery paths further.Hi Design Club,