騰訊雲帳號快速開戶 騰訊雲輕量伺服器數據盤未自動掛載，重啟後目錄丟失排查

騰訊雲帳號快速開戶 一、先弄清楚，真正丟失的往往不是目錄

在騰訊雲輕量伺服器上，數據盤沒能在開機後自動掛載，最容易出現的錯覺就是「重啟後目錄不見了」。其實很多時候，目錄並沒有真的被刪掉，而是原本掛在數據盤上的那一層內容被卸下來了，系統回退到根分區上同名的空目錄，或者直接看見一個沒有資料的目錄。這種情況如果第一時間去新建文件、重新解壓、再次同步，反而可能把資料寫到系統盤，後面排查起來更麻煩。

判斷這類問題，先記住一個原則：先確認磁盤是否掛載，再談資料是否遺失。只要數據盤本身還在，原有資料通常還留在磁盤上；真正危險的是誤格式化、誤分區、錯誤掛載到別的路徑，或者在未掛載的情況下把新資料寫進了系統盤。對於做網站、資料庫、日誌收集、備份存放的伺服器來說，這一步尤其重要。

二、為什麼重啟後沒有自動掛載

1. /etc/fstab 沒寫對，或根本沒寫

Linux 的自動掛載通常依賴 /etc/fstab。若啟動時沒有找到對應條目，磁盤就不會自動掛上。很多人手工掛載成功後就結束了，沒有把 UUID、檔案系統類型、掛載點補進 fstab，結果一重啟就恢復原狀。

2. 直接寫設備名，重啟後裝置順序變了

把數據盤寫成 /dev/vdb1 這類設備名，看起來簡單，實際上並不穩定。雲主機在啟動過程中，磁碟枚舉順序可能變化，今天是 /dev/vdb1，明天可能變成 /dev/vdc1。設備名一變，fstab 就找不到對應分區，自動掛載自然失敗。比起設備名，UUID 更穩定。

3. 檔案系統本身有問題

如果磁盤上次非正常關機、強制重啟、或曾經有 I/O 異常，檔案系統可能進入需要修復的狀態。這時即使 fstab 寫對了，系統也可能因為檢測到錯誤而拒絕掛載。ext4、xfs 都有自己的檢查和修復手段，但要先分清楚是哪一種檔案系統，不能拿 ext4 的方法去修 xfs。

4. 掛載點目錄被改動，或掛載目錄不存在

如果 fstab 指向 /data，但這個目錄在重啟前後被刪掉，或者權限被改得不對，系統也可能掛載失敗。雖然 Linux 允許把磁盤掛到已存在的空目錄上，但這個目錄還是要先建立好。若掛載點本身出了問題，系統常常只報一個含糊的錯誤，表面上看起來像磁盤不見了。

5. 雲環境裡的初始化腳本或模板覆蓋配置

有些輕量伺服器會套用初始化腳本，或者你是從自定義鏡像恢復的系統。這類場景中，開機流程可能會覆蓋掉手工修改過的 fstab，或者在某個時點之前掛載操作就開始了，結果因為順序不對而失敗。這種問題最容易被忽略，因為第一次手動掛載沒問題，第二次重啟後又回到原點。

三、第一步：先確認磁盤到底還在不在

排查時不要急著修配置，先把底層狀態看清楚。最實用的是三個命令：lsblk、blkid、df。它們分別從設備、檔案系統、已掛載狀態三個角度看同一件事，拼起來就知道磁盤現在處在什麼位置。

lsblk -f
blkid
df -h
mount | grep data

如果 lsblk 看得到數據盤，卻在 FSTYPE 或 MOUNTPOINT 欄位裡沒有對應內容，說明磁盤存在，但沒掛上。如果 blkid 能查到 UUID 和檔案系統類型，說明分區還是好的，問題大概率在掛載配置上。如果 df -h 看不到 /data，說明系統目前確實沒把它掛起來，而不是你看錯了路徑。

很多人會在這一步被誤導：明明在控制台裡看見雲盤已經連上，就以為系統內一定可用。事實上，雲平台層面的掛載和 Linux 系統內的掛載是兩件事。雲平台只負責把磁盤接到虛擬機上，真正把它變成目錄空間，還得靠操作系統自己掛載。

四、第二步：檢查掛載點和 fstab

如果磁盤在，接下來就查 /etc/fstab。這個文件是系統自動掛載的核心。很多故障都能在這裡直接找到答案，比如 UUID 寫錯、掛載點寫錯、檔案系統類型寫錯、選項不合適、條目格式有誤。先看內容，再看系統識別到的 UUID，兩者是否一致。

cat /etc/fstab
blkid

騰訊雲帳號快速開戶 一個較穩妥的寫法通常像這樣：

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /data ext4 defaults 0 2

如果是 xfs，就把 ext4 改成 xfs。若不想因為非關鍵數據盤的問題卡住開機，可以考慮加上 nofail；但要注意，nofail 只是讓系統在掛載失敗時繼續啟動，並不等於修好了問題。對於承載網站資源、資料庫資料目錄的磁盤，能掛穩還是應該先掛穩，不要把容錯和故障修復混為一談。

還有一個常見錯誤是把設備名直接寫進 fstab，像 /dev/vdb1。這種寫法在測試環境也許能用，但在正式環境不夠可靠。雲主機一旦經歷過磁盤重排，設備名就可能改變。用 UUID 的好處就是不依賴順序，磁盤只要沒有被重新格式化，UUID 一般不會變。

五、第三步：手動掛載，直接看錯誤信息

騰訊雲帳號快速開戶 手動掛載是最快的驗證方式。先確認掛載點存在，再嘗試掛載。如果失敗，系統報錯往往就能直接指出問題方向。

mkdir -p /data
mount /dev/vdb1 /data

如果你的數據盤沒有分區，而是直接整塊盤格式化，那命令可能要改成：

mount /dev/vdb /data

這裡的關鍵在於先搞清楚磁盤是「整盤掛載」還是「分區掛載」。有些教學把兩者混在一起，照抄之後就會出現很奇怪的錯誤。你在 lsblk 裡看到的是 /dev/vdb 還是 /dev/vdb1，決定了後面的操作方式。

如果掛載時提示檔案系統類型不正確、superblock 損壞、或需要檢查，先不要急著格式化。格式化會直接清空資料。應先查看日誌：

dmesg | tail -n 50
journalctl -xe

對 ext4 而言，可能需要做 fsck；對 xfs 而言，則應使用 xfs_repair。兩者不能混用。修復前最好先卸載磁盤，避免在掛載狀態下做破壞性操作。若磁盤正在承載重要業務，最穩妥的做法是先做快照或備份，再處理修復。

六、重啟後目錄看起來丟了，如何判斷是不是誤掛載

很多「目錄丟失」的根源，其實是誤掛載。比如原本 /data 裡有一堆網站文件，結果數據盤沒掛上時，系統顯示的其實是根分區上的 /data 空目錄。你一眼看過去，會以為內容不見了。這時最重要的是別急著往裡寫新資料，而是先看掛載狀態。

可以用下面的方式交叉確認：

mount | grep /data
findmnt /data
lsblk -f

如果 /data 沒有掛載記錄，但磁盤上本來有數據，那些內容通常還在數據盤上，只是被擋住了。只要把正確的分區重新掛上，資料就會回來。反過來，如果你已經在未掛載狀態下往 /data 裡重新建了文件，那這些新文件大概率寫到了系統盤。之後重新掛載數據盤時，這些文件又會消失，於是就形成了「有時有、有時沒有」的假象。

所以在排查前要養成一個習慣：先查 mount，再查 df，再查 lsblk，最後才是目錄內容。順序不能反。只看 ls 和 tree 很容易被表象帶偏。

七、幾個最常見的實戰場景

場景一：控制台已連接，系統內沒有自動掛上

這種情況多半是 fstab 缺失或寫錯。最直接的修復方式是先手動掛載成功，再把 UUID 寫回 fstab，然後執行 mount -a 驗證。如果 mount -a 沒報錯，通常就說明配置大致正確。

場景二：設備名變了

今天是 /dev/vdb1，重啟後成了 /dev/vdc1。這不是磁盤壞了，而是枚舉順序變了。把 fstab 改成 UUID 後，這類問題基本能一次解決。這也是雲主機上最推薦的做法。

場景三：檔案系統損壞，掛載報錯

如果日誌顯示需要 fsck，先卸載再修。若是 xfs，使用 xfs_repair。修復前務必確認沒有程序正在寫入這塊盤。否則你一邊修，一邊還在產生新損壞，結果只會更亂。

場景四：掛載點被錯誤清理

有些人清理環境時把 /data 目錄也刪了，結果重啟後掛載自然失敗。修復很簡單，重新建立目錄即可，但要先確定它是原本的掛載點，而不是臨時資料夾。若原路徑有權限要求，還要順手恢復 owner 和 mode，否則應用服務仍然起不來。

八、從零建立一套穩定的自動掛載流程

如果你是在新買的騰訊雲輕量伺服器上配置數據盤，建議按下面流程一次做完整，避免以後反覆返工。

lsblk -f
mkfs.ext4 /dev/vdb1
mkdir -p /data
blkid /dev/vdb1

拿到 UUID 後，寫入 /etc/fstab，然後立刻測試：

mount -a
df -h

只要 mount -a 沒有報錯，df -h 裡也能看到 /data，這一步就算成功。但還不夠，最好再重啟一次確認。因為很多問題只在開機階段才會暴露，例如掛載順序、依賴服務、檔案系統自檢、網絡存儲等待等。等機器真正重啟通過，才算這套方案可長期使用。

如果 /data 是給某個服務使用，比如 Nginx、MySQL、Redis 或備份程序，掛載完成後要記得調整權限。很多服務不是掛上就能讀寫，還需要屬主屬組對得上。否則磁盤是掛上了，程序還是報沒有權限，容易被誤認成掛載故障。

九、出問題後的處理順序，決定損失大小

碰到重啟後數據盤沒掛上的情況，最怕的是慌。慌就容易做錯事，尤其是三件事：直接格式化、直接往目錄裡寫新資料、直接修改一堆配置而不保留現場。真正穩妥的順序應該是先保現場，再查狀態，再修配置，最後驗證重啟。

如果懷疑資料盤有損壞，先停服務，避免繼續寫入。若業務允許，先做雲盤快照，再修復。若無快照，至少把當前的 /etc/fstab、lsblk、blkid、dmesg 記錄保存下來。這些信息在後續定位時非常有價值，尤其是當問題出在檔案系統層或啟動腳本層時，靠一次臨時觀察很難還原全貌。

十、最後總結

騰訊雲輕量伺服器上，數據盤重啟後未自動掛載，表面看是「目錄丟失」，本質通常是掛載關係斷了。真正要排查的，不是先去找文件，而是先確認磁盤、分區、UUID、掛載點和 /etc/fstab 是否一致。只要數據盤沒有被誤格式化，大多數資料都還在。只要把掛載邏輯理順，這類故障其實很好解。

記住一個最實用的結論：日常運維不要依賴設備名，盡量用 UUID；不要把手工掛載當成完成配置，必須寫入 fstab；不要在未確認掛載狀態時直接操作業務目錄。把這三點做好，重啟後數據盤不自動掛載這類問題，就能少掉一大半。