Why Do Files Disappear After a Cloud VM Restart? Common Pitfalls and Fixes

In daily cloud‑host operations, engineers often face user‑reported file‑loss issues that can cause significant inconvenience. The following typical scenarios are summarized to help avoid these risks and prevent repeated mistakes.

Scenario 1: File loss after cloud VM restart

Phenomenon: Users report that data stored on the VM disappears after a reboot.

Analysis: The missing files are located in the

/dev

directory, which is a

tmpfs

temporary file system stored in RAM and not persisted to disk, so a reboot clears the data.

Explanation:

What is

tmpfs

? It is an in‑memory temporary file system offering high performance.

Common

tmpfs

mounts include

/dev

,

/dev/shm

,

/sys/fs/cgroup

,

/run/user/0

, etc., typically sized to half of total RAM. Use

df

to identify

tmpfs

volumes.

Suggestion:

Use

tmpfs

only for program or application caches.

Avoid storing persistent data on

tmpfs

unless data loss is acceptable.

Scenario 2: Accidental rm command execution

Phenomenon: After a reboot, the VM cannot ping, critical services fail to start, and essential system files are missing.

Analysis:

Console shows the OS stuck at boot with many "command not found" errors.

Inspecting

/root/.bash_history

reveals destructive commands such as

rm -rf /

,

rm -rf ./*

, etc., which delete large portions of the system.

Running

rpm -Va | grep miss

can verify missing files, though files not installed via RPM cannot be checked.

Suggestion:

Use

rm

cautiously; add the

-i

flag for interactive confirmation, especially with

-r

and

-f

.

If accidental deletion occurs, stop any further writes to the disk immediately to preserve recoverable data.

Restore missing system files by copying them from a healthy machine or reinstalling packages with

yum reinstall <package>

or

yum update <package>

.

Scenario 3: File‑system damage caused by fio

Phenomenon: Users report MySQL database anomalies on the cloud host.

Analysis:

High IOWAIT observed, suggesting I/O throttling issues.

Even after lifting disk limits, MySQL continues crashing; logs show corrupted data files.

Investigation reveals that the

fio

tool was used directly on the block device

/dev/vdb

, bypassing the file system and overwriting real data, leading to severe corruption.

The affected

/data

volume on both primary and standby MySQL nodes became unreliable and required reformatting and data restoration from backups.

Suggestion:

Use

fio

only in production after thorough testing.

When running

fio

, avoid specifying a raw block device; instead, create a regular file (e.g., with

touch

) and target that file with the

--filename

option.

Scenario 4: File‑system damage caused by dd

Phenomenon: Users report abnormal file access on the cloud host.

Analysis:

Files on the data volume become inaccessible, and

ls

reports "Structure needs cleaning" errors.

System logs (

dmesg

,

/var/log/messages

) show numerous XFS errors.

Root's command history reveals the use of

dd

to write zeros directly to

/dev/vdb

, damaging the underlying block device.

Suggestion:

Use

dd

cautiously in production; test beforehand.

Never specify a raw block device for the

of

parameter; instead, write to a regular file.

Scenario 5: Accidental deletion of a data disk

Phenomenon: Users report that a cloud disk was mistakenly deleted.

Analysis:

Check the deletion timestamp in the cloud portal; resources are often retained for a short period and can be recovered.

Verify the disk state in the virtualization console; if the state is "Ready", it may still be recoverable.

If not yet deleted, re‑attach the disk to the host and synchronize disk information via the portal.

Suggestion:

Handle disk deletion operations with extreme caution; once deleted, data may be unrecoverable.

Before deletion, confirm the disk is not in use (e.g., using

lsof -n

,

df -h

,

lsblk

, etc.) and unmount it, removing any entries from

/etc/fstab

.

If accidental deletion occurs, contact recovery support immediately to prevent physical cleanup.