Re: [請益] NAS壞過後 新的備份方式推薦?

看板Storage_Zone作者 (司馬雲)時間9年前 (2014/10/31 14:53), 9年前編輯推噓4(4推 0噓 66→)
留言70則, 6人參與, 最新討論串4/10 (看更多)
→
10/31 14:40,
恩...純好奇...為什麼1算一份...
10/31 14:40
→
10/31 14:41,
而且如果要防手殘砍檔案的話，就算自動化排程Sync
10/31 14:41
→
10/31 14:41,
也很危險...因為不一定在時間內救得回來，而且資料
10/31 14:41
→
10/31 14:42,
一大量...就算先分析差異報表有辦法馬上抓出問題嗎
10/31 14:42
→
10/31 14:42,
總覺得如果要提到這點，會變成無解Orz...
10/31 14:42
→
10/31 14:43,
你的喜好應該是很著重在異地，這點可以理解
10/31 14:43
→
10/31 14:43,
但是總覺得這個概念跟RAID的安全性不一定相關....
10/31 14:43
raid1當然算一份 你手殘砍掉，覆蓋，raid1一樣救不回來 就像ptt有做raid1，但如果沒有做其它的備份 站長哪天手殘把ptt程式搞掛了，raid1一樣無解(我只是舉例) raid1只防硬體故障不防軟體出包 要備份的話，可以選每日、每周sync，或是上git啊 每次更改都會有紀錄，只要你能找出哪一個時間點的檔案是正確的，就能回覆回來 怎麼會是無解?有備份就會有解，只要你的備份還在 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.135.113.202 ※ 文章網址: http://www.ptt.cc/bbs/Storage_Zone/M.1414738399.A.F88.html
→
10/31 14:59, , 1F
大概知道彼此申論上的差異性了...前面提到的重點是
10/31 14:59, 1F
→
10/31 15:00, , 2F
防硬碟故障的方案，原原PO指的是防NAS壞掉的方案
10/31 15:00, 2F
→
10/31 15:00, , 3F
的確RAID的硬體依賴性過大，這點也是在下不喜歡RAID
10/31 15:00, 3F
→
10/31 15:01, , 4F
的原因。然後你跟前面comipa的重點則在於資料正確性
10/31 15:01, 4F
→
10/31 15:02, , 5F
，但問題可能在於有些人手動備份常常壞了就要損失一
10/31 15:02, 5F
→
10/31 15:02, , 6F
整個月的進度，或者變成神經質想到就按一次最後乾脆
10/31 15:02, 6F
→
10/31 15:03, , 7F
開自動。而自動Sync也無法防各種手殘，因為人沒有
10/31 15:03, 7F
→
10/31 15:03, , 8F
那種心力去每天盯著修改清單報表看。而真正重要的東
10/31 15:03, 8F
→
10/31 15:04, , 9F
西如上面說的，這不只不能開自動備份，甚至要做版本
10/31 15:04, 9F
→
10/31 15:04, , 10F
控制留下N個階段的版本，以便隨時回溯，應該不只確
10/31 15:04, 10F
→
10/31 15:05, , 11F
認這次修改沒問題就好，而一般的檔案不需要做到這點
10/31 15:05, 11F
→
10/31 15:09, , 12F
。還是老話一句，這是無底洞，個人覺得一般使用者
10/31 15:09, 12F
→
10/31 15:09, , 13F
除非是專門做這一個控管的行業，不然最後都是盡人事
10/31 15:09, 13F
→
10/31 15:09, , 14F
之後也只能聽天命
10/31 15:09, 14F
沒有這麼麻煩，而且每個檔案也不會天天改 我一些文字檔也是上git備份，有問題做checkout來回覆跟本是家常便飯 沒有你想像的這麼複雜，更何況像群輝都有git套件可以裝 只要在windows端裝git軟體就可以開始用了 雖然使用git有一點門檻在，但備份這種事情本來就應該要花點心思 什麼都不做就希望檔案會自己備份，那跟祈禱硬碟不要出包沒什麼差別 ※ 編輯: filiaslayers (220.135.113.202), 10/31/2014 15:16:19
→
10/31 15:11, , 15F
突然想到= =如果弄了八顆硬碟之類的
10/31 15:11, 15F
→
10/31 15:12, , 16F
AB CD EF GH 分別做RAID1 然後ACEG做Sync
10/31 15:12, 16F
→
10/31 15:12, , 17F
而且是A一星期Sync到C，C一個月Sync到E，E一個月(ry
10/31 15:12, 17F
→
10/31 15:13, , 18F
這樣就可以在多重硬碟保護下不用人工看報表還可以
10/31 15:13, 18F
→
10/31 15:13, , 19F
保留約三個月的個別進度差，有三個月的時間可以救
10/31 15:13, 19F
→
10/31 15:13, , 20F
，好吧再加上異地....可是有誰能做到這樣...
10/31 15:13, 20F
問題是你這樣的意義在哪裡? 假如我今天有8顆，兩兩做raid1，這樣有4組 我可以設定說a組是每日備份，b組是每周，c組是每月，d組我就不知道要幹麻XD每年? 你發現某檔案有問題，大概是三天前出問題 你當然是去找b組撈啊，如果是兩個禮拜前出問題，當然是c組撈啊 你硬碟夠多，你願意花時間花錢就可以 我手上比較重要的資料，是有4份 一份在本機、一份在nas、一份在隨身硬碟，一份在google drive 搭配best sync，除了隨身硬碟要手動插拔，其它都能自動化 誰說不可能呢? ※ 編輯: filiaslayers (220.135.113.202), 10/31/2014 15:22:01
推
10/31 15:30, , 21F
假如我今天買得起兩千顆硬碟.....
10/31 15:30, 21F
→
10/31 15:31, , 22F
所謂有誰做到這樣的是那個建置費不是自動化...
10/31 15:31, 22F
→
10/31 15:31, , 23F
我這麼有錢，那我還花時間備份幹嘛
10/31 15:31, 23F
有錢就不用備份，所以你覺得有錢的大公司他們花大錢買機櫃備份資料是不必要的? 你沒看版上不少願意出錢救資料，但救不回來的人嗎?
→
10/31 15:31, , 24F
你這樣等於八顆硬碟當一顆用.....
10/31 15:31, 24F
資料分四個時間備份，何來當一顆硬碟用?不然你來指教一下?
→
10/31 15:32, , 25F
我覺得比較好的的方式是 祖 - 父 - 子
10/31 15:32, 25F
你這是當資料會生小孩?
→
10/31 15:32, , 26F
而且才說之後就一直在討論版本控制的問題...這個對
10/31 15:32, 26F
→
10/31 15:32, , 27F
於一般想到要備份的使用者來說太遠...
10/31 15:32, 27F
看你怎麼定義一般使用者 業餘寫程式的算不算一般使用者?寫書、作曲的算不算?這些人也需要版本控制吧 當然你也可以說一旦需要版本控制就稱不上一般使用者 但問題就是版本控制是很常見的事
→
10/31 15:33, , 28F
加上異地、多份... raid ... 啥的
10/31 15:33, 28F
→
10/31 15:33, , 29F
嘴巴講講我最厲害！反正
10/31 15:33, 29F
是，你是高手
→
10/31 15:33, , 30F
當然手上有的專案也是有在做版本控制，但RAID也是
10/31 15:33, 30F
※ 編輯: filiaslayers (220.135.113.202), 10/31/2014 15:42:46
→
10/31 15:35, , 31F
其中的一環，這個著眼點已經不一樣了...
10/31 15:35, 31F
推
10/31 15:37, , 32F
嗯，後來這幾篇還有推文很大部分在講版本控制了，
10/31 15:37, 32F
→
10/31 15:37, , 33F
那已經是另外的議題，跟NAS/RAID沒啥關連了
10/31 15:37, 33F
→
10/31 15:37, , 34F
前面一直強調拿那種專案開發的概念去跟一般使用者說
10/31 15:37, 34F
→
10/31 15:39, , 35F
根本是找麻煩
10/31 15:39, 35F
→
10/31 15:41, , 36F
話說比較複雜的開發案有可能每天CheckIn嗎...
10/31 15:41, 36F
→
10/31 15:42, , 37F
但是如果一周CheckIn一次，會想損失這一周進度嗎
10/31 15:42, 37F
→
10/31 15:42, , 38F
最後還是要回到每個階段都要RAID一組的問題吧...
10/31 15:42, 38F
我沒有否認raid1的必要性，這點請不要搞錯 然後不管是svn還是git，都是業界常用的軟體 寫出svn或是git不是笨蛋(正確的說是政府官員) 他們不會弄出一個鳥蛋軟體，搞的沒人要用 更何況git還是當初為了管理linux kernel的程式碼，由寫linux kernel的那幫人搞出來的 控制檔案備份的時機，也是可以做到簡單的版本控制 更何況對於照片或是音樂的備份，跟本是殺雞用牛刀 我只有在備份我自己的程式碼才會上git ※ 編輯: filiaslayers (220.135.113.202), 10/31/2014 15:50:12
→
10/31 15:44, , 39F
資料分四個時間備份...但是最後資料會長一樣
10/31 15:44, 39F
我舉的例子裡，最長就一個月，如果你一個月都沒改東西 當然最後會一樣啊，不是廢話... 如果你每天都有改，每天備份的跟每個月備份的怎麼會一樣 除非你全部都排在一起備份，這先不說很蠢，光頻寬就卡死了XD
→
10/31 15:44, , 40F
那些容量不能挪做他用，這就是當一顆用.....
10/31 15:44, 40F
只備份不做其它用途就是當一顆用這言論你看誰會接受...
→
10/31 15:44, , 41F
不然RAID1容量1/2的說法到底是...
10/31 15:44, 41F
→
10/31 15:46, , 42F
好吧我先說我的立場，扯到版本控制就不是一般使用者
10/31 15:46, 42F
→
10/31 15:46, , 43F
這個是可以確定的，如果看法有差，大概就在這吧
10/31 15:46, 43F
推
10/31 15:47, , 44F
真的要在推文中討論版本控制嗎？ XD
10/31 15:47, 44F
推
10/31 15:49, , 45F
小舞妳另開吧... 推文推這麼長看起來也很累...
10/31 15:49, 45F
※ 編輯: filiaslayers (220.135.113.202), 10/31/2014 15:54:59
→
10/31 15:51, , 46F
另外開文前若可以的話定義一些詞 ex一般使用者
10/31 15:51, 46F
→
10/31 15:52, , 47F
這樣討論時大家的基礎才不會不一樣...
10/31 15:52, 47F
※ 編輯: filiaslayers (220.135.113.202), 10/31/2014 15:55:27
→
10/31 15:55, , 48F
版控有另外專門的系統啊～應該不是備份的範疇了XD
10/31 15:55, 48F
沒錯orz 不過git或svn因為都能搭配遠端的server做管理 所以常常會把版控當備份，不過這的確是不正確的觀念 因為沒有搭配遠端的server，那就只是在本機的檔案多複制一份，稱不上備份 ※ 編輯: filiaslayers (220.135.113.202), 10/31/2014 15:58:26
→
10/31 15:57, , 49F
只要考慮備份資訊足以還原版控系統就好XD
10/31 15:57, 49F
→
10/31 15:59, , 50F
Orz，反過來想問哪個不是這樣想的....
10/31 15:59, 50F
→
10/31 16:00, , 51F
RAID說明都會寫到可用容量為原本總和容量的多少
10/31 16:00, 51F
→
10/31 16:01, , 52F
這就表示在一般說明認知上，等於你買N顆硬碟卻只能
10/31 16:01, 52F
→
10/31 16:01, , 53F
用到其中一部分的容量，反過來說就是為了擴增容量
10/31 16:01, 53F
→
10/31 16:01, , 54F
就得花N倍的錢。當然你要說備份=拿來用，這點我認同
10/31 16:01, 54F
→
10/31 16:02, , 55F
，但我不想在這個節骨眼上去跟一般使用者說明= =...
10/31 16:02, 55F
→
10/31 16:02, , 56F
多買一顆硬碟=要他老命...肯買NAS+RAID算他有見地了
10/31 16:02, 56F
→
10/31 16:04, , 57F
是說NAS+RAID明明就比買個外接來備份還貴阿XD"
10/31 16:04, 57F
→
10/31 16:04, , 58F
有在做備份的不見得會做版控，會做版控的根本不需要
10/31 16:04, 58F
→
10/31 16:05, , 59F
跟他多說明何謂備份了...不就是這樣嗎...
10/31 16:05, 59F
→
10/31 16:05, , 60F
另外小舞的問題沒那難.姑且不說那種還沒備份到東西
10/31 16:05, 60F
→
10/31 16:05, , 61F
就壞了的case,TrueImageHome這麼便宜的軟體都能做
10/31 16:05, 61F
→
10/31 16:05, , 62F
versioned backup,真的沒有這麼困難
10/31 16:05, 62F
→
10/31 16:07, , 63F
當然我這邊版控不是指SVN/GIT那種東西,而是TI本身就
10/31 16:07, 63F
→
10/31 16:07, , 64F
能保留好幾個version(只記錄version間差異)
10/31 16:07, 64F
→
10/31 16:08, , 65F
我是這樣覺得，只留一個版本差的版控不算版控
10/31 16:08, 65F
→
10/31 16:08, , 66F
而肯花一個檔案N倍容量的空間去做版控，也不需要
10/31 16:08, 66F
→
10/31 16:08, , 67F
跟他說明這些東西了，一定是業界的。說到version差
10/31 16:08, 67F
→
10/31 16:09, , 68F
就更麻煩了，不是所有專案都只要記錄version差就好
10/31 16:09, 68F
→
10/31 16:09, , 69F
當然不只一個嘍,看你硬碟多大可以設好幾個
10/31 16:09, 69F
→
10/31 16:09, , 70F
了，又不是每個專案都code(ex.等身抱枕圖= =....
10/31 16:09, 70F
‣ 更多 filiaslayers 的文章
文章代碼(AID): #1KKp7V-8 (Storage_Zone)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 4 之 10 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共10篇)
‣ 更多 filiaslayers 的文章
文章代碼(AID): #1KKp7V-8 (Storage_Zone)