有些話在資訊系統裡,天生就有安定人心的效果。
例如:
「有備份。」
只要這三個字一出現,會議室裡通常會稍微安靜一點。
資料壞掉?
有備份。
硬碟掛掉?
有備份。
系統被勒索?
沒關係,我們……
有備份。
聽起來很好。
而且這次真的不是騙人的。
備份有做。
排程有跑。
檔案也確實存在。
如果只看備份工作有沒有執行,甚至可以說它非常勤勞。
直到有人多問了一句。
「那備份在哪裡?」
答案是:
「就在那台主機裡。」
很好。
正式資料在那台主機。
備份資料也在那台主機。
正式環境跟備份環境相處得非常融洽,甚至可以說感情深厚。
深厚到正式資料被勒索的時候,備份也決定一起共患難。
這時候你就會開始發現,「我們有備份」這句話,其實只完成了一半。
另外一半叫:
備份出事的時候,備份還在不在。
這種設計放回比較早期的環境,其實並不難理解。
當年很多系統面對的主要問題,不一定是今天這種大規模勒索軟體、橫向移動或整批資料加密。
更常見的情況可能是:
硬碟壞了。
有人誤刪資料。
程式更新後跑不動。
某個檔案突然不見。
在這些情境裡,把資料每天複製一份,確實非常有用。
昨天的資料壞了?
拿前天的回來。
某個檔案被刪了?
從備份目錄撈回來。
這套方法曾經真的解決過問題。
問題不是它從第一天就完全沒有用。
問題是後來世界變了。
以前比較像是:
「冰箱裡的牛奶壞掉,所以我們另外買一瓶備用。」
後來的威脅變成:
「整間房子被搬走了。」
這時候你才發現,兩瓶牛奶都放在同一個冰箱裡。
備份策略本身沒有突然變笨。
是事故的範圍變大了。
勒索事件最麻煩的地方之一,就是它通常不會很有禮貌地只碰正式資料。
只要系統看得到、帳號碰得到、主機掛得到的地方,都可能一起成為事故範圍。
所以「有另一份檔案」和「有一份能活過事故的備份」,其實是兩件不同的事。
這也是為什麼有些地方明明每天都收到:
「Backup completed successfully」
真的出事時,現場卻還是會陷入一種很哲學的狀態。
備份成功了。
但是還原不了。
或者更直接一點:
備份成功地被一起加密了。
技術上,它確實很成功。
只是成功的方向跟大家期待的不太一樣。
於是後來我們開始不太滿足於問:
「有沒有備份?」
而是會繼續問:
備份跟正式環境是不是在同一個失效範圍?
備份是不是永遠在線?
正式系統的管理帳號能不能直接碰到它?
如果主要環境整批出事,它還能不能獨立存在?
最後一次真的還原是什麼時候?
這些問題其實沒有很玄。
它們只是把「備份」從一個檔案,重新變成一種復原能力。
很多人第一次接觸備份時,會先認識一堆數字。
一天備幾次。
保留幾天。
容量多少。
全備、增量、差異。
這些都重要。
但真正遇到事故後,大家通常會突然開始關心另外兩件事。
第一個是:
我最多可以接受少掉多少資料?
第二個是:
我最多可以接受系統多久回不來?
這兩件事情聽起來很像管理語言,但其實非常生活化。
如果今天是公司網站壞掉,也許晚一點恢復還能接受。
如果今天是交易資料,少掉一天可能就完全不是同一個故事。
備份不是備得越多越好。
而是出事的時候,要知道自己準備恢復到哪裡。
更有趣的是,很多組織真正第一次驗證備份,都是在事故發生的那一天。
平常大家知道備份有跑。
每天綠燈。
報表正常。
空間沒有爆滿。
於是所有人默默相信:
需要時應該可以用。
這裡的「應該」非常重要。
資訊系統裡很多都市傳說,都是從「應該」開始的。
「這應該有人在備份。」
「這應該可以還原。」
「這應該有第二份。」
「這應該不會一起壞。」
久而久之,「應該」就會慢慢變成組織記憶。
最後再被寫成一句:
「我們有備份。」
真正比較成熟的做法,不是從此宣布原本的人都做錯了。
而是重新問:
現在我們要防的是什麼?
如果只是硬碟故障,本機另一份確實可能有幫助。
如果要面對勒索事件,就需要考慮離線、不可任意修改、不同帳號邊界,甚至異地。
如果要面對機房級事故,那又是另外一個層次。
控制措施要跟事故模型一起長大。
這才是重點。
所以後來有人再說:
「放心,我們有備份。」
我通常不會馬上反駁。
我會說:
「很好。」
然後問下一句。
「最近一次真的還原,是什麼時候?」
這句話通常可以讓一場五分鐘的會議,很自然地變成四十分鐘。
但至少從那一刻開始,我們討論的不再只是「有沒有一份檔案」。
而是在討論:
真的出事時,我們回不回得來。
這也是資訊安全裡一個很容易被忽略的地方。
真正讓人安心的,從來不是「我們有備份」。
而是:
我們知道它在哪裡,而且知道怎麼把它帶回來。
至於那一份跟正式資料住在同一台主機裡的備份——
不能說它沒有價值。
它只是有點太重感情。
正式資料去哪裡,它就去哪裡。
連出事都要一起。
這台資訊安全奇聞車,今天先停在備份站。