轉至：https://www.cnblogs.com/pincelee/articles/413009.html
StorageTek災難備份與數據恢復及其解決方案
前言及災難備份與數據恢復的方式
我們處在一個信息的年代，信息無所不在。因特網、數據倉庫、email、以及各種不斷涌現的各種新的應用等，導致信息爆炸性地增長。同時，企業的發展推動信息的增長，而企業要發展，也必須依靠其信息。所以，保護好企業的信息成為企業生存和發展的關鍵。但是，在中國越來越多的企業雖然開始意識到存儲信息的重要性，並開始投資搭建存儲架構，大多數企業還沒有意識到災備是信息存儲的一個重要環節。美國9.11事件的發生，使越來越多的企業意識到實施數據災難備份的重要性。災備就像企業為自己的信息購買的一項保險一樣，企業要生存和發展，就必須考慮如何完善地保存它的數據。
美國德克薩斯州大學的調查顯示："只有6%的公司可以在數據丟失后生存下來，43%的公司會徹底關門，51%的公司會在兩年之內消失。"可見，信息已成為一個企業最重要的資產。災備是企業確保信息安全的一個關鍵策略。當然，實施災難備份計划需要企業投入很大的資金，但這應被看成是存儲管理費用中的一部分。企業需要系統管理員確保其應用系統的可用性，同樣，企業也需要IT經理們確保其信息的安全可靠性。
災難備份的實施並不是很復雜的程序，但它要求企業綜合考慮其設施管理、系統管理、存儲管理，從而確保它的商務運作不會因為其中任何一部分發生問題而受到影響。所以，災備計划要求企業內部所有人員的配合，包括CEO和所有下屬管理人員，它要求企業決策者們100%的支持。
災難備份與數據恢復的方式
災難備份的策略制定取決於企業的IT需求，主要有下列幾種實施方式：
1．一個數據中心對應多個數據中心策略
預防自然災害和恐怖襲擊的最好的策略。但選擇地點時，需要察看所有的基礎架構，包括建築本身、網絡、儀器，以及物理環境的安全性。
2．硬件產品的冗余策略
冗余的硬件產品避免單點失誤。如果可能，實施自動切換。但是，硬件冗余並不保護由於操作失誤、應用失誤、病毒和黑客攻擊造成的數據丟失。
3．定點備份策略
備份是恢復損壞的數據的關鍵。數據恢復的需求決定企業的：定點備份時間和頻率，以及要備份的數據量。
4．遠程備份策略
遠程備份關鍵數據用於防止自然的和人為的威脅，既可以通過網絡進行，也可以使用交通運輸工具。方式包括：離線的存檔安全庫（預防恐怖事件和病毒的襲擊）、備份到另一個數據中心（預防本地的災難，被稱為：Cold Site）、存檔工作包給專業公司去管理。
5．網絡傳輸策略
實施這個策略受通訊帶寬、費用和性能需求的影響。
6．數據雙重/多重拷貝策略
數據恢復的需求決定了拷貝的份數和放置拷貝的地點。但該策略受時間和資源的限制。
災難備份的實施並不是很復雜的程序，但它要求企業綜合考慮其設施管理、系統管理、存儲管理，從而確保它的商務運作不會因為其中任何一部分發生問題而受到影響。
熱備份中心策略
7．熱備份中心策略
熱備份要求同步數據的快速恢復，費用很高，實施復雜。但是該策略必須有離線存檔備份和定點存檔的支持，否則就不是一個真正意義的災備了。這一點很重要，離線的災備是防止破壞、敵意的病毒襲擊、應用失誤等的有效方式。因此，如果客戶有必要實施熱備份的災備方案，StorageTek會建議客戶同時采用離線的遠程災備方案（如下圖所示），從而確保數據的100%安全。
本圖災備方案的實施環境是基於SAN，2個熱備份中心和1個遠程冷備份中心，使用StorageTek的產品包括：
VSM虛擬存儲管理器
V960虛擬磁盤陣列+PPRC（同步遠程鏡像）軟件
9310磁帶庫
它的優勢在於：
備份使用磁盤和磁帶兩種介質，使數據得到雙重保護
支持在線同步數據的備份
既支持熱備份，確保關鍵數據的及時恢復；又支持冷備份，確保數據的安全性
選擇何種災難備份數據恢復方式
企業應根據其商務運作的需求來考慮實施什么樣的災難備份計划，包括其系統應用和數據的關鍵性以及恢復操作的速度等。通常，數據分為：
關鍵性的數據。主要包括：用於重要商務程序中的數據、法律要求保存的數據、等。
賴以生存的數據。主要包括：用於正常商務程序並耗費企業很大的資源的數據、災難恢復時不會馬上需要上的數據、牽涉公司的商務機密的數據，等。。
敏感的數據。主要包括：用於正常商務程序但丟失時可以從別處恢復的數據、比較容易重新建立起來的數據、等。
非關鍵性的數據。主要包括：花費很少就可重新建立起來的數據、安全系數要求不高的數據，等。
關鍵性的數據要求瞬間恢復，因為他們支撐着企業的關鍵商務運作，所以恢復這種數據是最貴的。通常，人們認為關鍵數據占企業數據的20%左右。
賴以生存的硬盤數據恢復速度可以是幾分鍾或幾小時，費用也便宜很多。事實上，自動磁帶庫的解決方案很適合用於這類數據的備份和恢復，費用比用於關鍵數據備份和恢復的磁盤鏡像解決方案便宜100%以上。
敏感數據和非關鍵數據適合遠程的電子存儲系統備份方案。企業可以將這類數據存在同一地點，也可以通過網絡傳到另一個備份或存檔的地點。數據恢復可以通過網絡，恢復時間可以是1天、甚至多達4天。
另外，企業所有的操作系統、應用和數據都必須進行備份，並移到另一個安全的地點，確保安全以備萬一。
StorageTek公司的災難備份數據恢復解決方案
StorageTek公司在存儲業界擁有30多年的豐富經驗和完善的存儲產品線，包括：自動磁帶庫、磁盤、網絡產品和業界最先進的虛擬存儲技術。StorageTek以其不斷的發明和創新聞名於存儲業界，在全球55個國家擁有22，000多個裝機客戶。無庸置疑，StorageTek在災難備份的設計和實施方面也是業界最有經驗的公司。這一點在美國9.11事件中得到充分證明。StorageTek在世貿大廈里有將近100個裝機用戶，他們中沒有一家公司丟失任何數據。在StorageTek的積極技術支持下，他們的系統都恢復了正常運行。而且，大多數在幾個小時之內就恢復了運行。
上圖展示的StorageTek災難備份方案實施在一家大型的國際金融機構的數據中心，客戶是一家大型國際金融機構的數據中心。由於很多金融客戶都擁有類似的、異構的系統操作環境，因此該方案比較有代表性。目前，類似的災備方案已被全球眾多StorageTek的金融客戶采用。該方案采用了StorageTek的自動磁帶庫9310，TimberLine、9840和9940磁帶機混裝，以及虛擬存儲產品：VSM（虛擬存儲管理器）和SN6000（存儲域管理器）。同時，有本地和遠程兩個備份中心。
在本地，9310磁帶庫作為SAN環境下的存儲共享池，備份所有開放系統和主機系統上的數據。如果系統發生故障丟失數據，磁帶庫里的數據不會受到影響。而且，磁帶庫備份的數據可以通過網絡直接傳到遠程的備份中心，也可以通過運輸到達異地。充分確保了數據的安全性。
在異地，該金融客戶由於其業務需要，擁有與本地同樣的系統環境。如果本地發生災難，那么遠程的中心可以馬上啟動，確保客戶的業務可以正常進行。當然，不同的客戶根據其業務需求，異地災備中心的配置不一定是本地的復制。
StorageTek為客戶提供的重要商務益處
它為客戶提供了幾個重要的商務益處：
廣泛的兼容性
支持異構的操作系統和服務器平台, 包括：NT、Unix、OS/390、和OS/400。
既支持傳統的直聯式--磁帶庫直接聯在服務器上做網絡備份，又支持開放的、異構環境的SAN架構。
支持不同的連接通道，包括：SCSI、光纖通道、和ESCON。
單點控制，易於管理
所有系統平台共享一個存儲設備池。
混裝的磁帶機，通過SN6000（存儲域管理器）搭建的虛擬SAN架構，支持所有不同的平台和不同的應用。
支持多種備份方式
可以在本地進行備份，然后將備份的數據運輸到另一安全的存儲設施中心；
也可以通過通道延伸進行電子數據傳輸，通過網絡將數據備份到遠程異地完成。
虛擬存儲技術，確保系統應用的高可用
StorageTek的SN6000是世界上第一套虛擬SAN的產品，它分開了服務器與存儲設備之間的直接聯系。后端存儲的任何變化不會導致前端系統的關閉或重新配置。
VSM通過磁盤系統仿真成虛擬的磁帶機和介質，以磁盤做緩存。大部分磁帶操作都直接面對磁盤緩存的、虛擬磁帶的裝帶。裝帶/卸帶都是在瞬間完成的（僅需20秒），提高了磁帶備份和恢復處理的效率。
VSM是實施異地災難備份的理想產品，尤其是針對中國的客戶。因為，解決異地災難備份的難點在於兩地間的通訊介質，由於目前國內用戶可以使用的高速通訊線為E-1，帶寬僅為2Mbps，無法滿足異地實施數據備份的需求。而VSM做為磁盤緩沖，實時備份數據，前端主機可以繼續進行批處理工作，VSM通過后端將數據傳輸到異地的備份中心。
為客戶節省了巨大的費用
雖然使用磁帶遠程備份，數據恢復的時間長達幾個小時（磁盤鏡像只要幾秒鍾），但是，費用大大低於磁盤，多達50%到100%。也許關鍵的業務應用有必要使用磁盤鏡像，但是調查顯示，企業的關鍵數據通常只占20%左右。所以，使用遠程磁盤鏡像備份所有的數據，費用巨大，給客戶造成不必要的浪費，也給客戶實施災備計划帶來預算的困難。
StorageTek強調企業應根據其IT需求，系統中斷對其業務造成的影響度，所需費用以及面臨威脅的程度，來決定采取何種備份方式、以及是否采取多種災難備份方式。在此，為確保客戶的數據安全，我們還要強調只做在線的熱備份是不夠的，它必須要有離線的數據備份支持。 在現有預算不允許災備投資的情況下，StorageTek建議企業可以采取簡單的措施來減少災難發生的可能性，例如：
所在的辦公樓是否有發生自然災害的危險？解決方法為：搬到其它地方。
是不是只有一個電源？解決方法為：增加另一個電源。
有沒有安裝UPS系統？解決方法為：趕緊安裝一套。
數據的備份是否存放在同一樓內？解決方法為：挪到另一個地點。
ext2文件系統下數據進行數據恢復
摘要
ext2文件系統下數據進行數據恢復
---------------------------------------------------------------------
本系的 BBS 系統真是多災多難 (嗯 .... 其實是因為我的疏忽，才會這么多災多難 ....) ，繼這幾日系統時間不正確，造成許多人的 ID 被誤砍后，又一次因系統設定上的問題，將 BBS 的重要備份檔給殺了。這件事是學弟發現后告訴我的，當我上站來一見到他的 mail, 當真是欲哭無淚，差點沒去撞牆。
那時已是周六晚 11:00 左右，我一邊想着要編一套說辭向大家解釋無法替大家進行數據恢復舊信件與設定了，一邊還在想是否能夠挽回局面。大家知道， UNIX like 的系統是很難像 M$ 的系統一樣，做到 undelete 的，所有網管前輩都曾再三警告我們，要小心! 小心! 砍檔之前三思而后行，砍了之后再后悔也沒用。雖然我已漸漸做到砍檔三思而后行，但之次誤砍事件是系統在背景中定時執行的，等到我找出原因時已是數據被砍后一個多小時。我憑着一點點的印象，想起在網絡上，有人討論過在 Linux ext2 filesystem中 undelete 的可能性，但我所見到的多半是負面的答案，但好象真的有人做過這件事，於是我第一個所做的，就是馬上將該數據原來所在的 partition mount成 read-only, 禁止任何的寫入動作，不是怕再有數據被誤砍 (因為已沒什么可砍的了) ，而是怕有新數據寫進來，新資料可能會覆蓋到舊資料原本存在的磁區 (block) 。我們現在唯一個指望，就是企圖將數據原來存在的磁區一個個找回來，並且「希望」這些磁區上的舊資料都還在，然后將這些磁區串成一個數據。終於被我找到了!! 原來這方面的技術文件就存在我自己的系統中 :-))
/usr/doc/HOWTO/mini/Ext2fs-Undeletion.gz
於是我就按照這份文件的指示一步步來，總算將一個長達 8MB 的壓縮檔數據恢復了 99%, 還有一個長達 1.1 MB 的壓縮檔完整無缺地救了回來。感謝上帝、 Linux 的設計者、寫那篇文件的作者、曾經討論過此技術的人、以及 Linux 如此優秀的 ext2 filesystem, 讓我有機會搶救過去。現在，我將我的搶救步驟做一個整理讓大家參考，希望有派得上用場的時候 (喔! 不，最好是希望大家永遠不要有機會用到以下的步數 :-)))
在此嚴正聲明!! 寫這篇文章的目的，是給那些處於萬不得已情況下的人們，有一個挽回的機會，並不意味着從此我們就可以大意，砍檔不需要三思。前面提到，我有一個數據無法 100% 救回，事實上，長達 8MB 的數據能救回 99% 已是幸運中的幸運，一般的情況下若能救回 70% - 80% 已經要愉笑了。所以，不要指望 undelete 能救回一切。預防勝於治療! 請大家平時就養成好習慣，砍檔前請三思!!!
理論分析
我們能救回的機會有多大? 在 kernel-2.0.X 系列中 (本站所用的 kernel 是 2.0.33) ，取決以下兩點:
數據原來所在的磁區是否沒有被覆寫?
數據是否完全連續?
第一點我們可以與時間競賽數據恢復，就是當一發現數據誤砍時，要以最快的速度 umount 該 filesystem, 或將該 filesystem remount 成唯讀。就這次的情況而言，數據誤砍是在事發一個小時后才發現的，但由於該 filesystem 寫入的機會很少 (我幾乎可確定一天才只有一次，做 backup)，所以第一點算是過關了。
第二點真的是數據恢復要聽天由命了，就本站所使用的 kernel, 必須要在假設「長數據」所占的 block 完全連續的情況下，才有可能完全救回來! 一個 block 是 1024 bytes,長達 8 MB 的數據就有超過 8000 個 block。在經常讀寫的 filesystem 中，可以想見長數據很難完全連續，但在我們的系統中，這一點似乎又多了幾分指望。同時，Linux ext2 如此精良的 filesystem, 能做到前 7950 多個 block 都連續，這一點也功不可沒。
好了，以下我就講一下我的步驟。
數據恢復,搶救步驟 I - mount filesystem readonly
該數據的位置原來是在 /var/hda/backup/home/bbs 下，我們系統的 filesystem 組態是:
root@bbs:/home/ftp/rescue# df
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda1 396500 312769 63250 83% /
/dev/sda3 777410 537633 199615 73% /home
/dev/hda1 199047 36927 151840 20% /var/hda
/dev/hda2 1029023 490998 485710 50% /home/ftp
因此 /var/hda 這個 filesystem 要馬上 mount 成 readonly (以下請用 root 身份):
mount -o remount,ro /var/hda
當然也可以直接 umount 它，但有時候可能有某些 process 正在此 filesystem下運作，您可能無法直接 umount 它。因此我選擇 mount readonly。但您也可以用:
fuser -v -m /usr
看一下目前是那些 process 在用這個 filesystem, 然后一一砍掉，再 umount。
數據恢復,搶救步驟 II
執行
echo lsdel | debugfs /dev/hda1 | less
看一下該 filesystem 最近被砍的 inode (數據) 有那些 (為什么是 /dev/hda1? 請見上頭的 df 列表)? 在這奶F數據的重要資訊，如大小、時間、屬性等等。就我們的系統而言，其列示如下:
debugfs: 92 deleted inodes found.
Inode Owner Mode Size Blocks Time deleted
....................................................................
29771 0 100644 1255337 14/14 Sat Jan 30 22:37:10 1999
29772 0 100644 5161017 14/14 Sat Jan 30 22:37:10 1999
29773 0 100644 8220922 14/14 Sat Jan 30 22:37:10 1999
29774 0 100644 5431 6/6 Sat Jan 30 22:37:10 1999
請注意!我們必須要在數據大小、被砍時間等資訊中判斷出要救回的數據是那一個。在此，我們要救回 29773 這個 inode。
數據恢復,搶救步驟 III
執行
echo "stat <29773>" | debugfs /dev/hda1
列出該 inode 的所有資訊，如下:
debugfs: stat <29773>
Inode: 29773 Type: regular Mode: 0644 Flags: 0x0 Version: 1
User: 0 Group: 0 Size: 8220922
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 16124
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x36b31916 -- Sat Jan 30 22:37:10 1999
atime: 0x36aebee4 -- Wed Jan 27 15:23:16 1999
mtime: 0x36adec25 -- Wed Jan 27 00:24:05 1999
dtime: 0x36b31916 -- Sat Jan 30 22:37:10 1999
BLOCKS:
123134 123136 123137 123138 123140 131404 131405 131406
131407 131408 131409 131 410 131411 131668
TOTAL: 14
現在的重點是，數據恢復必須將該 inode 所指的數據，所指的 block 全部找回來。在這它?14 個 block? 不對啊! 應該要有 8000 多個 block 才對啊! 在這卯ilesystem 的「奧密」了。上頭所列的前 12 個 block 是真正指到數據資料的 block, 稱之為 direct block 。第 13 個稱為第一階 indirect block, 第 14 個稱為第二階 indirect block 。什么意思? 該檔的資料所在的 block 位置如下:
各位明白嗎? 第 13 個 (131411) 與第 14 個 block 其實不是 data, 而是 index,它指出接下來的 block 的位置。由於一個 block 的大小是 1024 bytes, 一個 int 在 32 位系統中是 4 bytes, 故一個 block 可以記錄 256 筆資料。以 131411 block 為例，它所記錄的資料即為 (在數據未砍前):
131412 131413 131414 .... 131667 (共 256 筆)
而這 256 個 block 就真正記錄了數據資料，所以我們稱為第一階。同理，第二階就有兩個層 index, 以 131668 來說，它可能記錄了:
131669 131926 132182 .... (最多有 256 筆)
而 131669 的 block 記錄為:
131670 131671 131672 .... 131925 (共 256 筆)
而這 256 個 block 才是真正儲存數據資料的。而我們要的，就是這些真正儲存數據資料的 block 。 理論上，我們只要將這些 index block 的內容全部讀出來，然后照這些 index 把所有的 block 全部讀到手，就能 100% 數據恢復 (假設這些 block 全部沒有被新數據覆寫的話)。工程很大，但是可行。不幸的是，在 kernel-2.0.33, 其設計是，如果該數據被砍了，則這些 index block 全部會規零，因此我所讀到的是
0 0 0 0 0 ..... (共 256 筆)
哇! 沒辦法知道這些 data block 真正所在的位置。所以，在此我們做了一個很大的假設: 整個數據所在的 block 是連續的! 也就是我上頭的例子。這也就是為什么說，只有連續 block (是指后頭的 indirect block) 的數據才能完整救回，而這一點就要聽天由命了。
數據恢復,搶救步驟 IV
好了，現在我們只好假設所有的數據處於連續的 block 上，現在請用archie.ncu.edu.tw去找這個工具: fsgrab-1.2.tar.gz, 並將它安裝起來。因為步驟很簡單，故在此我就不多談。我們要用它將所需的 block 全部抓出來。它的用法如下:
fsgrab -c count -s skip device
其中 count 是只要 (連續) 讀幾個， skip 是指要從第幾個開始讀，例如我要從 131670 開始連續讀 256 個，就這樣下指令:
fsgrab -c 256 -s 131670 /dev/hda1 > recover
現在我們就開始救數據吧! 以上頭的資料，我們必須用以下的指令來救: (注意到頭開的 12 個 block 並沒有完全連續!!!)
fsgrab -c 1 -s 123134 /dev/hda1 > recover
fsgrab -c 3 -s 123136 /dev/hda1 >> recover
fsgrab -c 1 -s 123140 /dev/hda1 >> recover
fsgrab -c 7 -s 131404 /dev/hda1 >> recover
這是開頭的 12 個 block, 對於第一階 indirect, 就資料來看好象是連續的 :-))
fsgrab -c 256 -s 131412 /dev/hda1 >> recover
注意要跳過 131411, 因為它是 index block。對於第二階 indirect, 我們 *假設* 它們都是連續的:
fsgrab -c 256 -s 131670 /dev/hda1 >> recover
fsgrab -c 256 -s 131927 /dev/hda1 >> recover
fsgrab -c 256 -s 132184 /dev/hda1 >> recover
............................................
要一直做，直到 recover 的大小超過我們所要救回的數據大小 (8220922) 為止。要注意在這市 p心地跳過那些 index block (如 131668, 131669, 131926, 132183, ....) 了。
數據恢復,搶救步驟 V
最后一步，就是把數據「剪」出來，並看看我們救回多少了。在這戊]我們重復上述步驟，弄出來的 recover 檔大小為 8294400，而我們要的大小是 8220922, 那就這樣下指令:
split -b 8220922 recover rec
則會做出兩個檔，一個是 recaa, 大小是 8220922, 另一個是 recab 則是剩下的大小，后者是垃圾，扔了即可。現在我們可以檢查這個數據是不是「完整」的那個被誤砍的數據了。由於我們的那個數據是 .tar.gz 的格式，於是我們這個方法來檢查:
mv recaa recaa.tar.gz
zcat recaa.tar.gz > recaa.tar
如果沒有錯誤訊息，那表示成功了! 完全救回來了。但不幸的是，我們沒有成功，將弄出的 recaa.tar 改名再 gzip 之后，與原來的 recaa.tar.gz 比一下大小，發現少了 1%, 表示說該檔原來所在的 block 中最后有 1% 是不連續的 (或者被新寫入的數據覆寫了)，但這已是不幸中的大幸了。
后記
對於在 undelete 時 *必需* 假設所有 block 連續的問題，那份 HOWTO 文件說 Linus 與其它 kernel 設計者正着手研究，看能否克服這個困難，也就是在數據砍掉時，不要將 index block 規零。我剛剛試一下 kenrel-2.2.0 的環境，發現已做到了!! 以下是一個已砍的數據的 inode data (由 debugfs 所讀出):
debugfs: Inode: 36154 Type: regular Mode: 0600 Flags: 0x0 Version: 1
User: 0 Group: 0 Size: 2165945
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 4252
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x36b54c3b -- Mon Feb 1 14:39:55 1999
atime: 0x36b54c30 -- Mon Feb 1 14:39:44 1999
mtime: 0x36b54c30 -- Mon Feb 1 14:39:44 1999
dtime: 0x36b54c3b -- Mon Feb 1 14:39:55 1999
BLOCKS:
147740 147741 147742 147743 147744 147745 147746 147747 147748 147769
147770 157642 157643 157644 157645 157646 157647 157648 157649 157650
157651 157652 157653 157654 157655 157656 157657 157658 157659 157660
157661 157662 157663 157664 157665 157666 157667 157668 157669 157670
157671 157672 157673 157674 157675 157676 157677 157678 157679 157680
157681 157682 157683 157684 157685 157686 157687 1...................
.........9745 159746 159747 159748 159749 159750 159751 159752 159753
159754 159755 159756
TOTAL: 2126
真是太完美了!! 這意味着在 kernel-2.2.X 的環境下，我們不必假設所有的 block 都連續，而且可以百分之百找回所有砍掉的 block! 因此上述的第二個風險就不存在了。