答案當然是有的，而且還是早就已經存在許久的作法。首先，當然就是老生常談的備份。除了定期的備份，針對重要資料甚至可以採用即時備援的架構，以避免備份時間點與意外發生時間點差異所造成的資料損失。備份與備援可以減少原始資料損失時所造成的影響，算是比較被動的作法。比較積極的作法，可以考慮將系統與資料分別存放在不同的檔案系統、不同的硬碟、甚至是不同的 RAID 陣列。事實上，在早期的 Linux 建構建議中，將系統與資料放在不同的檔案系統，一直是一個不可輕忽的作法。但是後來 Linux 的安裝過程過於自動化，連檔案系統的劃分也不需要管理者人工設定，所以這個建議事項越來越難被落實，甚至也很少聽到有人再提起。
無獨有偶的，前一陣子另外一位朋友公司的 ERP 系統，也因為停電而造成資料庫的損毀。資料庫損毀？是的，而且他們用的可是資料庫市場的領導品牌。更何況這可不是意外的停電，而是大樓事先公告的維護性停電。大樓公告被無視化、停電時剛好在進行當日資料庫的備份作業、斷電後重新供電不穩定、前一天資料庫備份無法使用...一連串的巧合，讓他們損失了不少的資料。又是運氣不好？是的，連我一個第三者都覺得運氣真的是太差了吧。
這個事件同樣也只能怪罪於運氣不好嗎？當然不是！大樓管理單位對於停電這麼重要的事情竟然只貼了公告，而沒有主動通知，肯定有所失職。但是大樓管理單位通常不是我們能夠控制的變數，所以我們更應該著力於我們可以控制的事項上。首先，是 UPS 系統的使用。UPAS 可不光是買了接上就行，包含電力不足時的自動關閉也是同樣重要的。此外，針對伺服器在停電後重新恢復供電的行為，是否該設定為自動啟動？還是應該設定為手動啟動？這也是一個值得仔細推敲的問題。最後，備份資料的確認，同樣是容易被許多系統管理者所忽視的重點工作事項。不管是透過雜湊值 (如 MD5) 來確保檔案的完整性，或者是透過匯入的動作來確保資料庫備份資料的正確性，都可以避免日後從口中發出 WTF 的憾事。
這兩個看似完全不相關的事件，同樣都因為新技術的導入，而忽略了原本系統就存在的風險。RAID 讓我們可以避免硬碟損毀所造成的意外，但是它卻無法避免其他意外的發生 (甚至 RAID 本身也可能出錯)。資料庫領導品牌強調他們的資料庫有多種機制可以確保資料不會損毀，但是依舊無法提供 100% 的保證。所以我們在面對這些技術時，千萬別因為這些新奇的保證而忘了其他存在的風險。採用多種保護措施，本來就是管理者用來應付風險的主要策略，千萬不要認為這是資源的重複投資與浪費而縮手。尤其在面對重要資料的保護時，小心、謹慎永遠是不嫌多的，將來有一天你會感謝自己曾經注意到這些"小細節"。
