灾难备份与数据恢复及其解决方案

转至：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! 因此上述的第二个风险就不存在了。