本文是本番環境等やらかしちゃった人 Advent Calendar 2025的第20篇文章。
那時候或許RHEL 6已經推出,但CentOS 6還不存在於這個世界上。
為了將提供內部服務的本地實體伺服器群未來遷移至虛擬基礎建設,我建造了一個所謂的3層結構,利用未來將作為虛擬基礎建設的實體伺服器和用於數據的iSCSI存儲進行自建構。
實體伺服器使用CentOS 5,虛擬機管理程式則選擇KVM。因為iSCSI存儲不支持區塊卷的精簡配置,所以並不是直接將虛擬伺服器的區塊卷附加到各伺服器,而是將整個存儲確保為一個區域,並在實體伺服器上掛載使用。
隨著對虛擬伺服器的創建和運行逐漸熟悉,我開始在一些對故障影響有限的服務上試驗性地使用虛擬伺服器進行本番運行。
某天,我計劃構建一個新的虛擬伺服器,通過IP-KVM設備連接到伺服器控制台,啟動Virt-manager開始作業。因為使用virsh命令創建虛擬機的過程相對繁瑣,且我也擔任了幫助台的職位,所以每次都需要移動到伺服器室進行操作,這使得我選擇利用IP-KVM通過工作電腦的網頁瀏覽器連接到實體伺服器的KVM切換器。
然而,執行過程中Windows卻突然停止響應,無論如何都無法恢復。等了幾分鐘情況仍未變化,我喃喃自語「真是的……就是這樣所以Windows才……」,然後按下了Ctrl+Alt+Del。隨即,畫面突然恢復,網頁上開始顯示關機處理的進度。沒錯,Ctrl+Alt+Del透過IP-KVM被發送到遠端的實體伺服器,伺服器開始重新啟動!
我懷疑自己的眼睛,思考接下來需要做的操作。由於CentOS 5的某些規範,當iSCSI掛載的磁碟在卸載前,網路連接就已經提前中止,因此出現了 iSCSI 卸載失敗,關閉處理中途停止的現象。所以,在正常運行中,我會手動先卸載磁碟,然後再進行關機處理。果不其然,關機處理途中停止,因此我手動前往伺服器室關閉電源。我以為手動重新啟動電源就能解決問題,但當時……
我強制斷電再重新啟動伺服器,檢查控制台後,實體伺服器並沒有正常重新啟動。奇怪的是,iSCSI存儲的掛載也失敗了。重啟進入救援模式後檢查iSCSI磁碟,竟然發現沒有任何分區!我的腦中一片空白。
我將情況報告給上司,並考慮應對措施。雖然有晚上的備份,但那僅僅是數據,而並不預期像這次這樣虛擬伺服器也會同時被刪除的狀況。根據手邊的作業手冊,我預估能夠恢復影響到用戶的服務,最快要到第二天。
但這很奇怪。整個磁碟在重新啟動時出現不一致而消失的情況根本無法想像。因此,我向一位熟悉數位取證的朋友尋求幫助。當你溺水的時候,任何能浮起來的東西都想緊緊抓住。他告訴我:「準備一個相同容量的磁碟,覆蓋最前面的XXX(是512嗎?)位元組的複製。」
我心中有些懷疑,這樣真的能解決嗎?但是幸運的是,存儲系統中有兩台完全相同的設備,其中一台用作備份,因此我決定從那個設備獲取dd數據轉存。儘管在備份處理時才會掛載,因此並沒有受到重啟的影響。
於是,我按照對方的指示進行操作,奇蹟般地,存儲的磁碟區域居然恢復了!我一時難以置信,但檢查運行狀態也沒有問題,服務成功恢復。從重新啟動到現在總共花了一個小時多。用戶被通報為系統故障,並且處理完成。