数据保护和备份概述

 

数据保护

---

 

所谓数据保护是指对当前时间点上的数据进行备份，如果说一份数据被误删除了，可以通过备份数据找回来。从底层来分，数据保护可以分为文件级保护和块级保护。

 

文件级备份

文件级备份：将磁盘上所有文件通过调用文件系统接口备份到另一个介质上。也就是把数据以文件形式读出，然后存储在另一个介质上面。此时备份软件只能感知到文件这一层。

 

　　我们知道一般来说，文件在原来的介质上，可以是不连续存放的，通过文件系统来管理和访问。当备份到新的介质上以后，文件完全可以连续存放。正因为如此，没有必要备份元数据，因为利用新介质进行恢复的时候，反正会重构文件系统。

 

块级备份

块级备份：就是不管块上是否有数据，不考虑文件系统的逻辑，备份块设备上的每个块。

 

　　这样好处是不通过调用文件系统接口，速度更快，缺点的是备份的时候会把所有的块复制一遍，但是实际上很多扇区的数据是不对应真实文件的，也就是会备份很多僵尸扇区。而且备份之后，原来不连续的文件一样是不连续的文件，有很多的碎片。

这种方式的一个典型案例就是磁盘镜像。而磁盘镜像最简单的实现方式就是RAID1。

 

 

 

 

高级数据保护方法

---

 

远程文件复制

远程文件复制：通过网络传输到异地容灾点。典型的代表是rsync异步远程文件同步软件。可以监视文件系统的动作，将文件的变化，同步到异地站点。增量复制。

 

远程卷镜像

这是基于块的远程备份。与远程文件复制不同的地方在于，是把块数据备份到异地站点。又可以分为同步和异步复制。

 

• 同步复制：必须等数据复制到异地站点以后，才通报上层IO成功消息

• 异步复制：写入成功即可回复成功，然后通过网络传输到异地。不能保证一致性，但是上层响应快。

 

　　基于块的备份措施，一般都是在底层设备上进行，不耗费主机资源。

 

       

 

快照

　　远程镜像确实是对生产数据一种非常好的保护，但是需要镜像卷一直在线，主卷有写IO，那么镜像卷也需要有写IO。

 

　　如果想对镜像卷进行备份，需要将停止主卷的读写，然后将两个卷的镜像关系分离。所以当恢复主卷的IO的时候，镜像卷不会再被读写。然后才可以备份镜像卷的数据。

 

　　这样会存在一个问题，主卷上还继续有IO，将会导致数据与备份的镜像不一致。所以主卷上所有的写IO动作，会以位图BitMap方式记录下来，BitMap上的每个位表示卷上的一个块，0表示未写入，1表示已写入，所以当拆分镜像以后，被写入了数据，程序将BitMap文件对应位从0变为1。备份完成以后，再做数据同步即可。

 

　　可以看出上述过程比较的繁琐，而且需要占用一块和主卷一样大小的镜像卷。

 

    

 

　　快照技术就是为了解决这种问题，其基本思想是抓取某一时间点磁盘卷上的所有数据。

 

基于文件系统的快照

 

文件系统管理的精髓：链表、B树、位图，也就是元数据。

 

　文件系统

• 将扇区组合成更大的逻辑块来降低管理规模。NTFS最大块可以到4KB，也就是8个扇区一组一个簇(Block)，这样可以减少管理成本，但存储空间可能会造成浪费。

• 文件系统会创建所管理存储空间上所有簇的位图文件。每个位代表卷上的簇(或者物理扇区)是否被使用，如果被使用，则置1。

• 文件系统保存一份文件和其对应簇号的映射链。因为映射链本身和簇位图也是文件，也有自己的映射链，所以针对重要的元数据，有一个固定的入口: root inode。

 

　写入新数据

• 查找簇位图，找位值为0的簇号

• 计算所需空间， 分配簇号给文件

• 将数据写入簇，再去文件簇号映射链更新

• 将对应的簇映射关系记录下来，到簇位图将对应位置改为1。

 

　删除数据

• 直接在簇号映射链中抹掉

• 簇位图对应簇改为0。

 

　　可以看出删除数据实际上不会抹掉实际的数据。所以，最重要的不是数据，而是文件簇号映射链和位图等元数据。

 

    

 

　　也就是说我们要做备份，只需要把某时刻的文件系统中的映射图表保存下来。但是必须保证卷上的数据不被IO写入了，同时又要保证应用还不能中断。既然原来的空间不能再写了，我们可以写到其他的空闲区域。

 

• 思路一：Copy on First Write (CoFW)，在覆盖数据块之前，需要将被覆盖的数据块内容复制出来，放到空闲的空间。

• 系统中将有两套元数据链，原来的元数据指向当前，快照的元数据链指向历史。原来的存储空间永远是最新的数据，历史数据会逐渐搬出到空闲空间里面。

 

     

    

• 思路二：Redirect on First Write (RoFW)。先复制元数据，然后将针对源文件的更改都重定向到空余空间，同时更新元数据。

• 与CoFW不同的是，原来的数据块不会被覆盖。同样的，系统也有两套元数据，一套是快照保存下来的，永远不更新，一套是源文件系统的，不断的更新。

   

　　其实只有首次覆盖的时候，才重定向，因为重定向以后的数据块，哪怕被覆盖了，也不影响之前快照保存的数据了。

 

　　到这一步，看上去挺完美，实际上存在一个问题: 如果元数据特别大怎么办？对于海量庞大的文件系统，元数据量可能到GB级别。如果复制的话，时间上仍然太多。

 

　　我们可以回头想想，实际上元数据可以看做指针，指向具体存储的位置。我们复制到元数据，相当于复制了一堆指针。现在元数据太多了，我们能不能把这个元数据链的指针给复制了？当然可以，元数据有个根入口块，或者称为Super Block，这个块是固定不变的，里面存放有指向下一级元数据链块的指针。

 

　　那么操作系统每次载入元数据的时候，都需要从这个地址读入Super Block，从而一层一层的遍历。我们还是按同样的方法，只复制Super Block的信息，那么其下所有元数据链自身的变更也要进入快照流程。

 

基于物理卷的快照

 

　　基于物理卷的快照比文件系统快照要简单得多。因为LUN一般在底层磁盘上是恒定的，不像文件系统一样可以随机细粒度的分布。所以可以认为LUN的元数据就是在底层磁盘的起始和结束地址。这样在快照的时候，需要复制的元数据就更少了，但是完成了以后，需要按照一定粒度来做CoFW或者RoFW，还需要记录更多数据映射指针，就比较难受了。

 

　　对于实现了块级虚拟化的系统如NetApp、XIV、3PAR等，它们的LUN在底层位置是不固定的，LUN就相当于一个文件，存在元数据链来进行映射管理的维护，所以这些系统实现快照的原理与文件系统快照类似。

 

　　基于物理卷的快照，相当于给物理卷增加了“卷扇区映射管理系统”。在底层卷实现快照，可以减轻文件系统的负担。

 

　　卷扇区方都是用LBA来编号的，实现快照的时候，程序首先保留一张初始LBA表，每当有新的写入请求的时候，重定向到另一个地方，并在初始的LBA表中做好记录，比如:

 

原始LBA：卷A的10000号，映射到LBA：卷B的100号。

 

　　值得说明的是，文件系统无法感知重定向，文件系统在它的映射图里面还是记录了原始的LBA地址。此时如果来了新的写IO，有两种方式一种是Write Redirect，另外一种是Copy on Write。

 

　　所谓Write Redirect就是将文件系统的读写请求，重定向到卷B，这样每次IO其实都会查找快照映射表，降低了性能。所以引入了Copy on Write。

 

　　所谓Copy on write，就是当写请求来的时候，先把原来的扇区的数据复制一份到空闲卷，然后将新数据写入原卷。不过这种复制操作只发生在原卷某个或者快照之后从未更新过的块上面，若是某个块在快照之后更新过了，说明之前的数据已经转移走了，可以放心的覆盖。

 

　　所以Copy on Write实际上是让旧数据先占着位置，等新数据来了以后先把原来的数据复制走，再更新，而且一旦更新了一次，可以直接覆盖。

 

　　带来的好处是 ，原卷上的数据随时是最新的状态，每个IO可以直接访问原卷的地址，而不需要遍历映射表。

 

     

 

RoFW方式与CoFW方式比较

 

　　不管是RoFW还是CoFW,只要上层向快照后没有更新过的数据块进行写，都需要占用一个新的块。所以如果将所有扇区块都更新了，新卷的容量和原来的容量应该一样大，但是通常不会覆盖百分之百，所以只要预设原容量的30%即可。

 

　　IO资源消耗：

 

• CoFW方式下，如果要更新一个从未更新的块，需要复制出来，写到新卷，然后覆盖原来的块，需要一次读，2写。

• RoFW方式下，只需要一次写即可，也就是直接重定向到新卷上，然后更新映射图中的指(在内存中进行)。

   

所以RoFW相对CoFW方式在IO资源消耗与IO延迟上有优势。

 

　　由于只有首次覆盖才会Copy或者Redirect，那么如何区分是否是首次覆盖呢？可以使用记录表(文件级快照)或者位图(卷快照)来记录每个块是否被覆盖过。

 

　　对于读IO：

 

• CoFW：因为总是更新的源卷，所以源卷总是代表最新的状态，所以任何读IO都会发到源来执行。

• RoFW：需要首先查询位图来确定目标地址是否被处理过，如果是，则转向重定向后的地址。

 

　　RoFW会影响读性能，因为重定向出去以后，数据块排布都是乱的，如果把快照删除后，不好清理战场，严重影响后续的读写性能。

 

　　综合来说，RoFW比较吃计算资源，而CoFW比较耗费IO资源。我们知道其实一般来说读比写多，当覆盖第二次以后：

 

• CoFW不会发生IO惩罚，读IO一直没有惩罚

• 对于RoFW，就算完全被Redirect过了，对于读或者写IO，均需要遍历位图，永远无法摆脱对计算资源的消耗。

 

　　尤其在LUN卷级快照下，原本卷在底层磁盘分布式是定死的，寻址非常迅速。但是RoFW引入了，LUN的块随机定向到其他的空间的，所以需要记录新的指针链，而且被写出的块不是连续排列的。对性能影响非常明显的。

 

　　绝大多数的厂商使用的还是CoFW，但是一些本来就使用LUN随机分块分布模式的存储系统比如XIV、NetApp等，都使用RoFW，因为原本其LUN的元数据链就很复杂，而且原来就是随机分布的，RoFW的后遗症对它们反而是正常的。

 

       

 

快照的意义

 

　　快照所保存下来的卷数据，相当于一次意外掉电之后卷上的数据。怎么理解?

　　上层应用和文件系统都有缓存，文件系统缓存的是文件系统的元数据和文件的实体数据。每隔一段时间批量Flush到磁盘上。而且不是只做一次IO，有可能会对磁盘做多次IO。如果快照生成的时间恰恰在这连续的IO之间，那么此时卷上的数据实际上有可能不一致。

 

　　文件系统的机制是先写入数据到磁盘，元数据保存在缓存里面，最后再写元数据。因为如果先写元数据，突然断电了，那么元数据对应的僵尸扇区的数据会被认为是文件的，显然后果不堪设想。

 

总之，快照极可能生成不一致的数据。

 

 

　　那么为什么还要用快照呢？

　　因为快照可以任意生成，而且占用的空间又不大，更重要的是可以在线恢复，不用停机只需要在内存中做IO重定向，那么上层访问就变成以前时间点的数据了。

 

　　但是快照会存在不一致的问题，如何解决？

　　既然快照无异于一次磁盘掉电，那么利用快照恢复数据之后，文件系统可以进行一致性检查，数据库也会利用日志来使数据文件处于一致。

 

　　在微软的Windows Server平台上，利用Windows Volume Shadow Copy Services (VSS)和它的API，数据库应用程序可以集成并调用快照工具。

　　VSS是专门为结构化数据应用设计的服务框架，可以驱动数据库等应用进入数据一致性的静止状态，在快照开始初始化之前，完成刷新缓存、结束写操作以及系统状态的更新。

　　

　　遗憾的是，目前在Linux和Unix操作系统平台上还没有类似VSS的服务或API。VMware公司的vCenter storage API可以说是一个部分解决方案。快照的发起者可以通过vCenter storage API给vCenter发出一个指令，让虚拟机进入静止状态，然后再执行快照。但这个时候，快照由于没有通过应用程序感知，也许会存在不一致的问题。

 

　　另外，现在主流的快照解决方案是在主机上安装一个代理，执行快照前，先通知文件系统将缓存中的数据全部Flush到磁盘，然后立即生成快照。

 

---

 

　　快照另外一个非常重要的特性是快照一致性组（Consistency Group），这个功能就是支持多个LUN或者叫卷volume同时做快照，保证数据的一致性。

 

　　如果采用阵列的快照来做数据库的备份，必须所有的LUN都是一个时间点的才行，这样数据库恢复的时候才能起来，否则数据库必须回滚到某一个一致的时间点，意味数据的丢失。

 

　　比较完美的做法就是在主机安装一个快照的agent，最好是多路径软件具备这个功能，在高端存储要做快照的时候，对主机的快照agent说，别动， 要照相了。

　　主机agent接受到摄影师的命令后，把ORACEL主机缓存的内容flush一下到陈列来，然后hold住，阵列也尽快把cache的内容flush到硬盘里，ORACLE用到的所有硬盘一块喊”茄子“，摄像师一按快门，一幅完美的快照就产生了。

 

　　一致性组除了保证照相的时候一致性外，还有恢复的时候要一致性恢复。这块的实现的重要性就不如照相的时候重要，可以人工选择同一时间的LUN快照恢复就可以了。最重要的是照相的时候必须要一致，而且这个人工干不了。

 

• 快照还可以预防数据逻辑损坏，也就是比如T1时刻，做了快照，T2时刻，因为管理员操作不当，误删了一个文件，T3的时候，进行了全备份操作。此时，这个文件看似永久丢失了，其实，此时还可以通过快照恢复这个文件。

• 快照还可以降低一致性备份的窗口。如果没有快照，要对某个卷进行一致性备份，需要暂停写IO，所以备份窗口比较长，需要等待备份停止以后才能继续写IO。使用快照的话，只需要复制元数据，然后在后台进行备份，降低了影响。

• 备份完毕以后，如何能检测数据是否是真一致的？若没有快照，需要将备份数据恢复到独立的物理空间里面，挂载到另一台机器上。有了快照，可以将快照直接挂载到另一台主机，避免了数据物理恢复导入的过程。

 

 

 

 

克隆

　　快照类似于某时刻的影子，而克隆则是某时刻的实体。每时刻生成了一份可写的快照，就叫对卷某时刻的一份Clone。然后这份Clone内容没被修改的部分是与源卷共享的，所以源卷没了，则Clone就没了，所以叫虚拟Clone。如果把数据复制出来，生成一个独立的卷，则就叫Split Clone，也就是可以得到实Clone。

 

　　卷Clone最大的好处在于可以瞬间生成针对某个卷可写的镜像，而不管卷的数据量有多大。

 

 

连续数据保护（continuous data protect）

　　CDP是一种在不影响主要数据运行的前提下，可以实现持续捕捉或跟踪目标数据所发生的的任何变化，并且能够恢复到此前任意时间点的方法。

 

　　CDP系统能提供块级、文件级和应用级的备份。

 

　　所谓应用级CDP，是说对数据的连续保护机制是发生在应用程序层的，换句话说，由应用程序自己对自己的数据加以连续保护，记录和保存每一笔更改。

 

　　应用级CDP的典型例子就是比如Oracle和DB2等各种数据库系统，数据库系统对每一笔交易都会进行日志记录，在归档日志模式下，所有曾经对数据库进行的更改操作均会被打入时间戳并记录到日志中，老日志不断地被归档存放以便为新日志腾出空间。当数据库发生问题的时候，利用归档的日志，就能够将数据库状态恢复到任何一个指定的时间点，数据库会顺序读出库中的每一笔交易然后将其重放（Replay），对应的数据重新写入数据库文件。重放完成后，还需要进行Redo和Undo操作，即检查日志中最后一个CheckPoint一致点处，一致点之后发生的交易全部回退。回退完成后，数据库便处于一个一致的状态并且可用。应用层CDP不需要任何其他程序的辅助，不需要任何特殊的存储系统功能，完全由应用程序自身就可以完成。

 

　　应用级CDP是最纯粹、最厚道、最彻底、最实用的CDP。

 

　　文件级CDP就是通过监视文件系统动作，文件的每一次变化（包括实际数据或者元数据的变化，比如重命名、删除、裁剪等属性的改变） 以日志的形式被记录下来。CDP引擎分析应用对文件系统的IO数据流，然后计算出文件变化的部分，将其保存在CDP仓库设备（存放CDP数据的介质）中，可以针对每个文件生成单独的日志链。可以对一个文件，或者一个目录，甚至一个卷来监控。

 

　　文件级的CDP方案，一般需要在生产主机上安装代理，用来监控文件系统IO，并将变化的数据信息传送到CDP仓库介质中，或者使用本地文件系统或者磁盘的某块额外空间来充当日志仓库。

 

　　文件级的CDP，能够保证数据的一致性。因为它是作用于文件系统层次，捕获的是完整事务操作。所有的文件版本管理软件都可以算作是文件级CDP的实现。

 

　　其实日志型文件系统自身也可以算作是一个粗线条的CDP实现，因为日志型文件系统自身也会记录每一笔操作记录和数据，只不过其日志是循环的，并非归档模式，同时默认的日志方式是只记录元数据更改而不记录实际数据，并且也不提供用户自定义回溯时间点的功能。如果能 够直接在文件系统模块中或者外嵌一个模块来针对每个文件记录归档模式的元数据＋实际数据日志，那么恢复的时候就可以指定某个文件的某 个时间点进行数据回滚了。

 

　　块级的CDP，与应用级和文件级的CDP实现思想相同，其实就是捕获底层卷的写IO变化，并将每次变化的块数据打入时间戳并且保存下来。

 

　　基于数据块的数据保护又可以分为基于主机层、基于传输层和基于存储层三类实现方式。一般来讲，基于块的持续数据保护除在主机层实现以外，相关的产品和技术比较复杂，实施成本也相应地比较高，因此适合于有持续数据保护需求的大中型企业。

 

　　CDP持续数据保护技术分为真CDP(True CDP)和准CDP(Near CDP)两类。　　

　　CDP的分类是相对于数据保护时间点而言的。准CDP技术是按照一定的时间频率，持续的记录并备份数据变化，每次备份有一定时间窗口，需要数据恢复时，可以恢复到过去备份的时间点，并不能形成完全意义上的持续保护，因此称为准CDP技术。　　

　　而真CDP技术是持续不间断的监控并备份数据变化，可以恢复到过去任意时间点，是真正的实时备份。

 

 

 

VSS公共快照

　　VSS全称是Volume Shadow copy Service，即“卷影复制服务”

 

　　上面提到，snapshot会生成不一致的数据，为了保证snapshot的一致性，几乎所有的存储厂商都提供了自己开发的针对各种应用程序和文件系统的代理模块。而应用程序有无限多种，存储厂商也有多个，与其每一个厂商为每一种应用程序都开发自己的代理，不如在操作系统中建立一个公共的framework服务，往上适配各种应用程序，往下适配各厂商的代理，做到统一控制调配，统一开发接口。微软在其windows server操作系统中就提供了这样一种公共服务模块，这就是VSS模块被开发的初衷。

 

　　下图是VSS架构：

　　

 

　　整个VSS逻辑架构包含4部分：VSS核心服务，writer，provider，requestor

• writer

　　　　代表各种应用程序，这些应用程序必须支持VSS，运行时便向VSS进行注册。VSS核心服务提供SDK开发接口

• provider

　　　　各个底层存储系统中的快照提供者，说白了就是各个存储厂商的存储系统以及在其主机端的代理程序，存储系统必须只是snapshot

• requestor

　　　　代表各个存储厂商的快照管理程序，当然也可以是快照代理程序，这个程序负责何时出发快照，管理员通过配置来控制快照生成的时间点和频率等

 

　　流程：

• T1时刻，某应用程序正在运行，并不停向卷LUN1写入数据

• T2时刻，系统管理员需要针对LUN1出发一次快照，管理员打开对应存储厂商的requestor程序界面，手动出发snapshot

• T3时刻，requestor程序接收到了管理员的操作，然后立即向VSS请求目前所有在VSS中注册的writer列表返给自己。

• requestor判断writer是否在列表中，如果在，提取注册信息，想VSS发起请求，通知VSS快照请求已经发起，请协助处理后续事宜

• T4时刻VSS收到requestor请求后，根据传送的卷列表信息向所有的provider发起查询谁可以针对LUN1进行快照，对应的provider收到查询后应答

• T5时刻，VSS此时已经得知了所有的必要信息，即哪个应用，哪个卷，哪个provider，VSS立即向writer发起请求，让writer暂时生成一致点，没完成的运算赶紧完成，来不及完成就暂挂，将缓存中的数据该回退就回退，并且暂停对数据卷的写IO操作。writer完成这些之后会通知VSS

• VSS接收到writer已经准备好的通知后，立即向对应的provider发起执行快照的请求，provider收到VSS指令后立即与存储设备通信针对LUN1生成快照

• 一旦快照生成，provider通知VSS快照已生成，VSS再告知writer可以继续正常工作了，然后VSS通知requestor本次快照成功生成

• 系统恢复常态

 

 

备份系统

---

  

备份目标

指将备份对象的数据备份到何处

 

备份到本地磁盘

 

　　备份目的地是在本地的磁盘，则只需要将数据备份到本地磁盘的另外分区中或者目录中。这样不需要网络，缺点是对备份对象自己的性能影响大。还会对其他的IO密集型程序造成影响。

 

　　这种方式一般用于不关键的应用和非IO密集型应用。比如E-mail，对转发实时性要求不高。

 

备份到SAN上的磁盘

 

　　备份到SAN上的磁盘，就是将需要备份的数据，从本地磁盘读入内存，再写入HBA卡缓冲区，然后再通过线缆传送到磁盘阵列上。

 

• 优点：只耗费SAN公用网络带宽，对主体影响小。

• 缺点：对公共网络资源和出口带宽有影响。

 

备份到NAS目录

 

　　备份到NAS目录就是将数据备份到远程共享目录中。比如window中常用的文件夹共享。因为数据一般是通过以太网进行传递的，占用了前端的网络带宽，但是相对廉价，不需要部署SAN。

 

备份到磁带库

 

　　现在出现一种虚拟磁带库，即用磁盘来模拟磁带，对主机来说看到的是一台磁带库，实际上是一台磁盘阵列，主机照样使用磁带库一样来使用虚拟磁带库。要做到这点，就必须在磁盘阵列的控制器上做虚拟化操作，也就是实现协议转换器的作用。可以带来了的好处是：

• 速度提升

• 避免机械手这种复杂的机械装置，取而代之的事控制器上的电路板

• 管理方便，随意增删虚拟磁带

 

 

备份通路

备份经过的路径

 

本地备份

 

数据流向：本地磁盘——总线——磁盘控制器——总线——内存——总线——磁盘控制器——总线——本地磁盘。

 

　　也即数据从本地磁盘出发，经过本地的总线 和内存，经过CPU少量控制逻辑代码之后，流回本地磁盘。

 

通过前端网络备份

 

经过前端网络备份的数据流向是：本地磁盘——总线——磁盘控制器——总线——内存——总线——以太网卡——网线——以太网——网线——目标计算机的网卡——总线——内存——总线——目标计算机的磁盘。

 

　　数据从本地磁盘出发，流经本地总线和内存，然后流到本地网卡，通过网络传送到目标计算机磁盘。

 

• 前端网络：服务器接受客户端连接的网络，也就是服务网络，是服务器和客户端连接的必经之路。

• 后端网络：对客户封闭，客户的连接不用经过这个网络，用与服务器和存储、应用服务器、数据库服务器的连接。可以是SAN，以太网

 

通过后端网络备份

 

通过后端网络备份的数据流向是：本地磁盘——总线——控制器——总线——内存——总线——后端HBA卡——线缆——后端交换设备——线缆——备份目的的后端网卡——总线——内存——磁盘。

 

LAN Free备份

 

　　备份的时候不经过LAN，也就是不流经前端网络，也叫Frontend Free。这样的好处是不耗费前端网络的带宽，对客户终端接受服务器的数据不影响。

 

　　因为前端网络一般是是慢速网络 ，资源非常珍贵。无论是本地、还是网络，都需要待备份的服务器付出代价，即需要读取备份源数据到自身的内存，然后从内存写入备份的目的地。对主机CPU、内存都有浪费。能否不消耗服务器的性能呢？可以，使用Server Free备份。

 

Server Free备份

 

　　Server Free备份的时候，数据不用流经服务器的总线和内存，消耗极少，甚至不消耗主机资源。备份源和备份目标都不会在服务器上，因为如果在服务器上，数据从磁盘读出，要流将总线，然后到内存，这就不是Server Free？那怎么做呢？

 

• 用SCSI的扩展复制命令，将这些命令发送给支持Server Free的存储设备，然后这些设备会提取自身的数据写入备份目的设备，而不是发送给主机。

• 使用另一台专门做数据移动的新服务器，来代替原来服务器移动备份数据。释放运算压力很大的生产服务器。

 

备份引擎

备份引擎：决定整个数据备份系统应该怎么运作，备份那些内容，什么时候开始备份，备份时间有没有限制等的策略。

 

备份服务器

 

　　备份引擎以什么形式体现呢？当然是运行在主机上的程序，所以需要一台计算机来做引擎的执行者。

 

　　那么备份服务器的备份策略和规则，怎么传给整个数据备份系统中的服务器？通过以太网，因为以太网扩展性好，适合节点间通信。相对于以太网，SAN更适合传送大量的数据。所以常用前端网络来连接待备份的服务器和备份服务器，因为备份策略的数据包不多。

 

　　备份服务器如何与每个待备份的服务器建立通话？怎么通话？规则怎么定？需要待备份服务器上运行一个代理程序，专门解释备份服务器发来的命令，根据命令作出动作。

 

　　这个运行在待备份服务器上的程序，就叫备份代理，监听端口，接收备份服务器发来的命令。

 

介质服务器

 

　　若数据备份系统中有一台SCSI磁带机，且多台主机想备份到这台磁带机上。而SCSI磁带机只能同时接到一台主机上。

 

　　那么怎么办呢？可以引入一台专门的计算机，只能由这台计算机来操作磁带机。

 

　　需要备份的计算机通过以太网将数据发给这台掌管磁带机的计算机，然后写给磁带机。

 

　　这样磁带机成为了公用设备，而在整个系统中，只有一台计算机能掌管备份目标，它就类似于一个代理，代理其他服务器执行备份。我们把它称为介质服务器。还有一个问题，如果有多台服务器向介质服务器发出请求，怎么办?当然需要一个协调员，也就是备份服务器，它可以指挥安装在待备份服务器的代理，让每台服务器按照顺序有条理的使用介质服务器提供的备份介质进行备份。

 

 

备份方式

完全备份

　　不管文件多大，只要要备份，都需要将文件都备份下来。

 

差量备份

　　只备份从上次完全备份以来发生变化的数据。差量备份要求必须做一次完全备份，作为差量的基准点

 

增量备份

　　只备份从上次备份以来这份文件中变化过的数据。不管是全备、差备，还是增量备份。

 

方案举例

　　全备份+增量备份方案：假如我们周一做全备份，周二做增量备份是在周一的基础上做的，周三做增量备份是在周二基础上的，后面的类推。。。

　　全备份+差量备份方案：周一做全备份，周二做的差量备份是在周一的基础上做的，周三的差量备份是在周一的基础上做的，后面的类推。。。

 

方案比较：

　　全备份+增量备份，恢复的时候比较麻烦（需要依次恢复之前的每次增量备份直到全备份，比如说，恢复周四的备份，需要依次恢复周四的增量备份，周三的增量备份，周二的增量备份，周一的全备份），但节约空间；

　　全备份+差量备份，恢复的时候比较方便（只需恢复当天的差量备份和周一的全备份），占空间稍大。

 

　　对于数据库的备份，备份软件想知道每个数据文件的变化是不可能的，因为数据库文件内部格式非常复杂，只有自己才能分析和检测出来。所以数据库管理软件有自己的备份工具。第三方备份软件只能调用数据库软件自身提供的命令。

 

总结