我不是學程式或資料庫的
許多年前去一間公司做派遣的資訊工
跑2間公司,其中一間是dvd出租店
記得是一間叫環什麼宇的(就是金獅影音之後承接的公司)
那時候全省的店家收得差不多,好像只剩2~3間店
我的工作一項就是固定一週一次的資料備份

備份的工作是一張指令表
一項一項照著打進去就好了
因為我本身不是很懂這些指令的涵意,所以我不會多打,也不會少打
印象是上了2,3個月的班之後
有次打完指令,一如往常的做完備份
離開後隔了幾小時卻接到電話說...
每間店都讀不到資料庫了 :jolin:
什麼客戶的儲值金,借出的片子,通通查不到了~
這時我派遣公司的老闆也沒辦法(他本身也不懂操作)
試了老半天也恢復不了
還想找ibm的原廠工程師來技術協助
但DVD店的老闆聽到費用覺得太貴
直接就這麼算了...
我也不知道他是怎麼處理客戶的問題
反正最後這幾間分店也就順勢收起來了

如果有人在這家租片子遇到最後倒店的糾紛
說真的...
應該不是我害的... :laugh:

有點像燒古蹟、燒輪胎庫房的意思...

應該是過程中有打錯了， 只作備份沒考慮遠端跑 script?
不是你害的難道是莫名？

Shouldn't be too big a problem for the users? Could still push local repo back to master/origin.

https://about.gitlab.com/2017/02/01...abase-incident/

lvm快照 24備份一次 幸運的是苦主6小時前手動備份
常規備份 不work 這個有點詭異
s3 空空的 甚麼都沒有
azure 不是db備份
同步備份 一開始是處理replication的問題 後來不小心動到主要db 災難就開始了

所以呢 有時候簡單的方法熟悉的方法反而是好方法

git repository 好好的沒出事

報導說的熬夜工作也不是事實
為了處理replication的問題拖了兩三個小時
要命的錯誤出在晚上十一點
指令跑在錯誤的伺服器上

:shock: :shock: :shock:

所以梅菲定律又一次得到驗證 :shy:

有一個疑問
指令表這種東西不是都寫成排程嗎?
為什麼還需要人手動去做備份
手動key指令無論怎麼想感覺風險都很大
誰知道會不會又不小心key成 rm -rf :laugh:

理論上是這樣

但我在資訊界這麼久，令人感到不解的作業方式通常是俯拾即是 :laugh: