一次“測試”引發的慘案：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
