一次“測試”引發的慘案:dd 命令寫錯目標,系統徹底崩盤!
最近,為一批備份服務器進行漏洞修復工作,并按常規進行了重啟。遺憾的是,這次重啟卻意外地導致了幾臺備份服務主機無法正常啟動,操作系統出現了故障,備份服務也因此中斷。
經過緊急排查后,我們發現了一個之前未曾注意到的問題:原來很久以前有人執行了一條dd命令,但當時并沒有立即重啟服務器。直到這次為了修復安全漏洞而進行的重啟操作,才觸發了這個問題。這條命令就像一顆隱藏的定時炸彈,最終引發了這次嚴重的故障。

這條dd命令毀了系統!
在系統重啟前,一切運行正常,沒有任何報警信號。而重新啟動之后,系統提示:

先檢查了磁盤、BIOS設置和啟動配置這些常見的地方,但沒發現什么問題。然后在其他還沒重啟的機器上查看了之前執行過的命令,結果找到了一條危險的命令,如下圖所示:

dd if=/dev/zero of=/dev/sda bs=10G count=1 iflag=dsync這條命令將 10GB 的全零數據以同步方式直接寫入系統磁盤 /dev/sda 的起始位置,徹底覆蓋啟動扇區和所有原始數據,極具破壞性!

而這位同事的本意,其實是想測試磁盤的讀取性能。他原本想執行的命令應該是:
ddif=/dev/sda of=/dev/null bs=32k count=32768 iflag=dsync只是將 if=和 of=位置寫反了,就把整個啟動盤最關鍵的引導區域給毀了!
dd是什么?
dd 是Linux/Unix系統中一個用于按塊block進行讀寫數據的命令,能夠在設備之間或文件之間進行底層復制、轉換、備份與恢復。它被廣泛用于:
- 制作啟動盤
- 系統備份還原
- 磁盤性能測試
- 清空磁盤數據(數據粉碎)
然而,dd 因其“直接對塊設備操作”的特性,也被稱為:
“Data Destroyer(數據毀滅者)”
一不小心,輕則誤刪文件,重則系統癱瘓!
基本語法:
dd if=<輸入源> of=<輸出目標> [參數]- if(input file):指定輸入源,可以是文件或設備,如 /dev/sda
- of(output file):指定輸出目標,如磁盤、文件或 /dev/null
常配合其他參數使用,如塊大小、計數方式、同步策略等。
常用參數說明:
參數名 | 含義 | 示例 |
if= | 輸入源 | if=/dev/sda |
of= | 輸出目標 | of=/backup.img |
bs= | 設置塊大小(block size) | bs=1M 代表每次讀寫1MB |
count= | 復制的塊數 | count=1024 表示復制1024個塊 |
skip= | 跳過輸入文件的前N個塊 | skip=1 從第2個塊開始復制 |
seek= | 跳過輸出文件的前N個塊 | seek=1 寫入時從第2個塊開始 |
iflag= | 輸入標志 | dsync 強制同步讀取 |
oflag= | 輸出標志 | direct , sync, append 等 |
status= | 控制輸出信息 | status=progress 顯示實時進度 |
總結
我這次完全跳進被人挖好的坑,在重啟服務器的時候,一定要仔細檢查每一步。建議你注意下面幾點,這樣可以避免重啟后系統進不去:
(1) 請檢查/etc/fstab文件,確認以下內容是否正確:
- 磁盤路徑
- 磁盤/分區UUID
- 掛載目錄的存在性及準確性
- 關鍵字(如defaults, xfs, ext4)的正確性
lsblk -f
cat /etc/fstab(2) 請檢查您的磁盤或分區狀態是否顯示為“rw”,這表示一切正常。
mount|grep"^/dev"(3) 看看日志里有沒有提到文件系統損壞的問題,這樣可以防止因為文件系統壞了而進不去操作系統。
cat /var/log/messages |egrep-i"xfs|ext"|grep-E'corrupted|corruption|Failed|error|metadata'
dmesg-T|egrep-i"xfs|ext"|grep-E'corrupted|corruption|Failed|error|metadata'(4) 審查歷史命令,查看是否執行了一些高危的操作
history|grepdd|grep sda























