|
||
|
Golden Member
 
加入日期: Dec 2002 您的住址: 飛機跟捷運在窗外跑來跑去...
文章: 2,531
|
我不是學程式或資料庫的
許多年前去一間公司做派遣的資訊工 跑2間公司,其中一間是dvd出租店 記得是一間叫環什麼宇的(就是金獅影音之後承接的公司) 那時候全省的店家收得差不多,好像只剩2~3間店 我的工作一項就是固定一週一次的資料備份 備份的工作是一張指令表 一項一項照著打進去就好了 因為我本身不是很懂這些指令的涵意,所以我不會多打,也不會少打 印象是上了2,3個月的班之後 有次打完指令,一如往常的做完備份 離開後隔了幾小時卻接到電話說... 每間店都讀不到資料庫了  什麼客戶的儲值金,借出的片子,通通查不到了~ 這時我派遣公司的老闆也沒辦法(他本身也不懂操作) 試了老半天也恢復不了 還想找ibm的原廠工程師來技術協助 但DVD店的老闆聽到費用覺得太貴 直接就這麼算了... 我也不知道他是怎麼處理客戶的問題 反正最後這幾間分店也就順勢收起來了 如果有人在這家租片子遇到最後倒店的糾紛 說真的... 應該不是我害的...  |
|||||||
2017-02-03, 11:27 PM
#21
|
|
|
Golden Member
加入日期: Apr 2003
文章: 2,598
|
引用:
有點像燒古蹟、燒輪胎庫房的意思... |
|||
|
2017-02-04, 12:02 AM
#22
|
|
|
*停權中*
加入日期: Sep 2001
文章: 1,253
|
引用:
應該是過程中有打錯了， 只作備份沒考慮遠端跑 script? 不是你害的難道是莫名？ |
|
|
2017-02-04, 10:44 AM
#23
|
|
|
Advance Member
  
加入日期: Mar 2003 您的住址: Land of living sky
文章: 334
|
Shouldn't be too big a problem for the users? Could still push local repo back to master/origin.
|
|
2017-02-04, 12:23 PM
#24
|
|
|
Advance Member
加入日期: Mar 2002
文章: 484
|
引用:
https://about.gitlab.com/2017/02/01...abase-incident/ lvm快照 24備份一次 幸運的是苦主6小時前手動備份 常規備份 不work 這個有點詭異 s3 空空的 甚麼都沒有 azure 不是db備份 同步備份 一開始是處理replication的問題 後來不小心動到主要db 災難就開始了 所以呢 有時候簡單的方法熟悉的方法反而是好方法 git repository 好好的沒出事 此文章於 2017-02-04 02:35 PM 被 ycli6921 編輯. |
|
|
2017-02-04, 02:33 PM
#25
|
|
|
Advance Member
加入日期: Mar 2002
文章: 484
|
報導說的熬夜工作也不是事實
為了處理replication的問題拖了兩三個小時 要命的錯誤出在晚上十一點 指令跑在錯誤的伺服器上 |
|
2017-02-04, 02:51 PM
#26
|
|
|
Elite Member
加入日期: Mar 2003 您的住址: Vancouver, Canada
文章: 15,006
|
引用:
 |
|
|
2017-02-04, 03:54 PM
#27
|
|
|
Junior Member
加入日期: Nov 2016
文章: 716
|
所以梅菲定律又一次得到驗證
 |
|
2017-02-04, 04:44 PM
#28
|
|
|
Regular Member
 加入日期: Feb 2015
文章: 65
|
引用:
有一個疑問 指令表這種東西不是都寫成排程嗎? 為什麼還需要人手動去做備份 手動key指令無論怎麼想感覺風險都很大 誰知道會不會又不小心key成 rm -rf |
|
|
2017-02-07, 10:04 AM
#29
|
|
|
*停權中*
加入日期: Jul 2013
文章: 331
|
引用:
理論上是這樣 但我在資訊界這麼久，令人感到不解的作業方式通常是俯拾即是 |
|
|
2017-02-07, 10:30 AM
#30
|
|
