• 2

Photo Station 不少照片破圖,兇手疑似為 Cloud Sync 的 百度雲

今天仔細點了 Photo Station 的部分相簿
發現有不少照片已經呈現破圖毀損的跡象
開啟原檔案一看,真的是壞掉而不是 Photo Station 的問題
反倒是我同步備份在百度雲的那一份沒有問題
這就帶來了兩個問題

1. 為什麼會造成照片損毀?
我是 DS414 用三顆硬碟做 RAID5
幾個月前有壞掉一顆但是也 rebuild 成功了
理論上一顆硬碟壞掉不會造成檔案壞掉才是吧

2. 本地檔案變更了,為什麼雲端同步的百度雲還可以保留好的那一份而不會被同步壞掉?
不過百度雲bug多多,再加上他幫我救回照片,所以這一點純粹只是好奇而已
2014-09-18 17:49 發佈
可怕的是,我在 Synology Conference 2015 拍的照片剛剛也發現一張破圖,但百度雲的檔案一樣是好的
所以上次硬碟掛掉造成的因素可以排除了
而壞掉的照片的檔案修改時間正好都是Cloud Sync 百度雲的檔案上傳日期
該不會是Cloud Sync有什麼Bug
還是先關掉好了,真是太可怕了
分享的文章沒人回應,只好越貼越少
Mowd wrote:
可怕的是,我在 Synology Conference 2015 拍的照片剛剛也發現一張破圖...(恕刪)


所謂破圖, 請 check NAS photo station 上的相片檔(photo目錄下) 和你原始相片檔(如有其他備份或是 memory card) 是否相符? 還是 photo station 上顯示為破圖?
FB: Pctine

pctine wrote:
所謂破圖, 請 check NAS photo station 上的相片檔(photo目錄下) 和你原始相片檔(如有其他備份或是 memory card) 是否相符? 還是 photo station 上顯示為破圖?


確定是原檔案損毀
感覺是Block Sync的時候出了問題
附上損壞前後檔案供有興趣的人研究
已將問題回報客服,有啟用 Cloud Sync 的人請檢查是否有類似情形發生
機率不高,大概幾百張照片會破個幾張...

我要來檢查2005到2014的相簿了...有100多G...



附加壓縮檔: 201409/mobile01-0f85f8b233c4cd4e9aeec9f9009265ea.zip
分享的文章沒人回應,只好越貼越少
Mowd wrote:
確定是原檔案損毀
感覺是Block Sync的時候出了問題
附上損壞前後檔案供有興趣的人研究...(恕刪)


還好我百度云主要是用於將資料下載同步至 NAS, 而並非將 NAS 重要資料和百度云同步.

不確定是否有相關連, 之前有些網站提供影片儲存於百度云上, 我都是將其歸檔至百度云 sync 目錄下, 這樣因為於 NAS 上有安裝 cloud sync 套件, 它會自動將影片同步回 NAS. 但發生好幾次抓回來的壓縮檔解不開, 出現 CRC error, 但小弟覺得這些網站不太可能犯這種錯誤才對 (例如 area11 這網站也頗具規模), 因為PC也能重新下載檔案, 小弟也沒有再去認真追蹤了.

至於你的相片發生損毀的情況, 剛才看了一下, 檔案長度是相同的, 但檔案內容裡面有部份的 block 發生不相同的情況, 畢竟現在 cloud sync 沒有提供 log, 所以也看不出檔案何時被複寫過了. (等 5.1 beta 後 cloud sync 有提供 log 看有沒有幫助)


不過提供另一個較安全的做法供你參考, 小弟 NAS 上重要的資料是每日排程備份至另一台 NAS, 然後做 cloud sync 的目錄並非原始目錄, 而是另一備份目錄, 這樣就比較不會發生 cloud storage 上面的檔案因為種種失誤去複蓋掉 NAS 上重要原始檔案的情況.
FB: Pctine

1. 同步到雲端的動作

你本地端只是純粹讀取而已, 會做寫入動作的地方是在雲端主機

檔案原本好的, 做了同步的動作反而壞掉的機率不是沒有, 但不高

請問大大上次打開這些照片, 是在多久之前?


2. 使用raid和檔案會不會壞掉 一點關係都沒有

基本上raid保護的是你整顆硬碟掛掉的情況

但如果有某幾個位元, 因為某種神秘原因, 1變0, 0變1

你的raid是無能為力的

舉例來說假如是raid1

或許他能發現兩顆硬碟的某筆資料不一致

但兩筆資料都是一堆0101

他要怎麼知道哪筆資料才是對的? 哪筆是錯的?

況且raid1很多時候為了加速, 他會把讀取的要求拆分給兩顆硬碟平行執行

在這種情況下, 每筆資料只會從某一個硬碟讀一次, 而不是兩個各讀一次

所以他連你資料壞掉都不見得曉得

而raid1已經是最高保護等級的raid了

大大用的raid5就更不用說了

所以raid對檔案的正確性, 一般是沒什麼防護能力的


以大大的例子

有可能是同步的時候是好的

所以上傳到百度的那份是正常的

但後來本機上的檔案因某種原因損毀

或許是壞軌或其他原因

因為不是使用者的人為寫入, 所以沒有觸發他再做一次同步

雲端的檔案就因此保持完好
感謝兩位的回文,會懷疑Cloud Sync不是沒有原因的
舉例來說我本機的資料夾有五張照片
C.jpg 是壞掉的

Filename Last Modify Time
A.jpg 2014/03/01 13:56:12
B.jpg 2014/03/01 13:56:12
C.jpg 2014/05/30 05:15:31
D.jpg 2014/03/01 13:56:12
E.jpg 2014/03/01 13:56:12


而百度雲上的檔案修改時間
Filename Last Modify Time
A.jpg 2014/05/30 05:15:31
B.jpg 2014/05/30 05:15:31
C.jpg 2014/05/30 05:15:31
D.jpg 2014/05/30 05:15:31
E.jpg 2014/05/30 05:15:31


種種巧合讓我不得不懷疑不是Cloud Sync就是百度雲出了問題

如果有人從本地同步到百度雲的話
應該會注意到進度列顯示的不只是上傳
偶而還有詭異的下載出現
至於到底是什麼原因,我就不得而知了
分享的文章沒人回應,只好越貼越少
pctine wrote:
不過提供另一個較安全的做法供你參考, 小弟 NAS 上重要的資料是每日排程備份至另一台 NAS, 然後做 cloud sync 的目錄並非原始目錄, 而是另一備份目錄, 這樣就比較不會發生 cloud storage 上面的檔案因為種種失誤去複蓋掉 NAS 上重要原始檔案的情況.


非常贊同P大的作法

因為你的雲端空間本身有可能是和其他client同步的

例如和你的桌機或是和你的手機同步

而這所有的client只要有一個人做了錯誤的寫入動作

就有可能發生, 你的雲端空間和你的NAS都被同步寫入錯誤的資料


至於大大的狀況, 只能請廠商來試著找原因了

如果是單純從本地同步到雲端的話

照理說比較不容易發生, 來源是壞的, 但目的地是好的的情況

但像他這種雙向同步的case就會變得很複雜...




filesystem wrote:
非常贊同P大的作法因...(恕刪)


我也是單向同步
所有變更只在 NAS 端完成
百度雲純備份,也不會有任何資料寫入,也沒有其他用戶端連線
等客服回覆之後再把結果 update 上來
分享的文章沒人回應,只好越貼越少

Mowd wrote:
我也是單向同步
所有變更只在 NAS 端完成
百度雲純備份,也不會有任何資料寫入,也沒有其他用戶端連線...(恕刪)


這裡的單向同步並非系統所定義的 "單向", 而是人以為的單向, 所以即使你的資料變更都只在 NAS 上, 照理說應該只有 "單向" 同步至 cloud storage, 但事實上可能並非如此, 雲端上的檔案那怕是因種種原因被異動了, 甚至於只是檔案日期被修改了, 都可能造成資料從 cloud storage 重新同步回 NAS.
FB: Pctine
  • 2
內文搜尋
X
評分
評分
複製連結
Mobile01提醒您
您目前瀏覽的是行動版網頁
是否切換到電腦版網頁呢?