数据库和文件系统的快照snapshot

1.快照用途

通俗法：快照的作用主要是能够进行在线数据恢复，用数据库采集下系统某一时刻的数据，将数据存入数据库中，当存储设备发生应用故障或者文件损坏时可以进行及时数据恢复，将数据恢复成快照产生时间点的状态。快照的另一个作用是为存储用户提供了另外一个数据访问通道，当原数据进行在线应用处理时，用户可以访问快照数据，还可以利用快照进行测试等工作。利用不同时间点的快照，还可以生成报告，用来检测系统在这段时间的性能趋势。

学术法：数据库快照是数据库（源数据库）的只读静态视图。在创建时，每个数据库快照在事务上都与源数据库一致。在创建数据库快照时，源数据库通常会有打开的事务。在快照可以使用之前，打开的事务会回滚以使数据库快照在事务上取得一致。

2.快照分类

快照通常有六种类型：

（1）Copy-on-write 复制写

（2）Redirect-on-write 重定向写

（3）Clone or split mirror 克隆或镜像

（4）Copy-on-write with background copy  后台拷贝的复制写

（5）Incremental 增量快照

（6）Continuous data protection 持续数据保护

复制写和重定向写快照

Copy-on-write（COW） 复制写

COW快照需要消耗一些存储空间建立快照卷。当我们为一个数据卷创建一个快照后，这些预留的空间用来存放而被变化数据更新的旧数据。COW快照在初始化的过程中仅仅创建用来描述源数据块位置的指针信息（元数据），而不是完整的将源数据拷贝过来。因为初始化的过程几乎可以再瞬间完成，对系统的影响也很小。

COW快照会跟踪数据卷的写操作和数据块的变化。当某个数据块发生改变时，在将旧的数据覆盖之前，首先将该块的旧数据复制到预留的快照卷，该步骤仅在数据卷相应数据块位置发生第一次写操作请求时进行。这个处理过程确保快照出来的数据与发起快照的那个精确时间点保持完全一致。这个过程也描述了“copy on write”这个名字的含义。

如果我们需要访问某个时间点的快照数据，对没有改变过的块直接从数据卷读取；对已经改变并被复制的块则从快照空间读取。从快照被创建那一刻起，每个快照都会跟踪记录描述块改变的元数据信息。

COW快照的主要优势在于空间的高效利用，因为快照卷只需要保留发生过变化的数据块，与数据卷相比要小得多。但是我们也知道COW快照有个缺点，它会引起数据卷性能的下降，这是因为创建快照之后，对数据卷的写操作会增加一个等待的过程-即旧数据复制到快照卷的过程。另外一个关键问题是每个快照卷必须依赖一个完整的数据卷。

Redirect-on-write(ROW)重定向写快照

“ROW重定向写”与“COW复制写”是相对的概念，它可以避免两次写操作引起的性能损失。ROW 同COW一样在空间利用方面效率非常高。那是什么让ROW快照避免了写性能的损耗？其中的原因是ROW把对数据卷的写请求重定向给了快照预留的存储空间，而写操作的重定向设计则把需要两次写才能完成的操作减少为一次。我们知道COW的两次写包括：1.将旧数据写入快照卷；2.在数据卷写入新数据。而ROW只写入新数据一步。

使用ROW快照，数据卷存放的是上一个快照时间点的旧数据，新数据最终存放在预留的快照空间。这里也有一个复杂的问题，就是快照的删除。被删除的快照上的数据必须被复制到原始数据卷，并且做一致性回退。创建的快照越多，维护快照的复杂度也会以指数级别上升。这些复杂性包括对原始数据的访问、快照数据和原始数据卷的跟踪、以及快照删除后的数据调整。另一个直接引发的严重问题是，原始数据集中会产生大量的碎片。

克隆或分割镜像快照与后台拷贝的复制写快照技术

Clone or split-mirror 克隆或分割镜像快照

Clone（或split-mirror）快照所创建的是数据的完整副本。Clone（或split-mirror）快照的对象可以是一个存储卷、一个文件系统或是一个Lun(logical  unit  number 逻辑单元号)。Clone快照的优点是它们具有高可用性；缺点是所有的数据都要完整的复制一份，复制的过程也不可能在瞬间完成。我们可以分割一对保持同步状态的镜像卷来启用Clone快照，分割的过程瞬间即可完成。然而，当镜像被分割成Clone快照之后，数据卷也就失去了他的同步镜像。

使用Clone快照需要面对一个非常严重的问题是每个快照都需要和数据卷一样大的存储空间。尤其是当我们在任何时刻都需要保持一份以上Clone卷的情况，这个成本会非常高。另一个缺点是影响性能，因为在镜像卷之间保持写同步需要一定的系统开销。

Copy-on-write with background copy 后台拷贝的复制写快照

copy-on-write with background copy快照有两个生成步骤：首先创建一个瞬时即可生成的COW快照；然后利用后台进程将数据卷的数据复制到快照空间，最后生成一份数据卷的克隆或镜像。

创建这种快照的目的是发挥COW快照的优势，同时尽量屏蔽它的不足。因此，这种快照常常被形容为COW和Clone快照的混合体。

增量快照与持续数据保护

（Incremental）增量快照

增量快照的特点是可以跟踪数据卷和快照卷的变化。当一个新的增量快照生成之后，旧的快照数据将被刷新。第一个快照和随后创建的每一个增量快照数据上都有时间戳标记，利用时间戳我们能够快照数据回滚到任意的一个时间点。增量快照技术能够加速后续快照的生成速度，而且仅仅在名义上多消耗一点空间而已。因此，我们可以提高创建快照的频率，也能让快照保留的更久一点。

增量快照的不足之处是它需要依靠上面所提到的其它基础技术来创建第一个快照(COW,ROW,clone/split mirror，copy-on-write with background copy)。如果用Clone方式，那么第一个快照需要较长的初始化时间，如果用COW方式，数据卷的性能会降低。

持续数据保护（CDP）

CDP的出现是为了实现零数据丢失的RPO指标，以及瞬时数据恢复的RTO指标。它本身与同步数据镜像很相似，不同之处在于CDP还可以对软件灾难进行恢复。包括认为误操作、恶意软件攻击、意外删除、数据损坏等情况。

持续数据保护颇像频率很高的增量快照。它会捕获并复制任何时刻发生的数据变化，并且给这些数据块打上时间戳。CDP本质上相当于每个时刻都创建一份增量快照，提供细粒度的精确数据恢复。有些CDP产品同时提供基于时间和基于事件（例如应用程序升级事件）两种粒度的恢复方式。还有一个理解CDP概念的好方法就是将它看成一个快照的journal日志。

对于邮件系统、数据库和基于数据库的应用来说，CDP是一个极好的保护方案，能将数据回滚到任意的历史时间点，恢复过程也简便、迅速。最有代表性的CDP产品是飞康公司的IPStor，它是一个集成了CDP功能的存储系统兼存储虚拟化设备。

随着越来越多的数据需要保护，备份窗口也变得越来越紧张，因此需要快照技术来帮助我们解决备份问题。在现实的应用环境中，快照利用的是否恰当对数据保护的等级和恢复的速度有着很大的影响。尽管各类型快照之间存在的技术差异并不太容易理解，但无论如何，快照技术都将在数据保护领域和日常存储管理中扮演重要的角色。

特别注意：快照的一致性问题

如果用快照来处理结构化数据，可能会存在一些问题。结构化数据涉及到数据库，以及数据库类的应用（例如邮件系统、ERP或CRM等等）。许多产品中的快照并不能与这些应用程序集成或被直接调用。有一种可能的情况是，在我们创建快照的瞬间，数据库恰好不在静止状态（缓存正在刷新、写操作事务尚未完成、索引和元数据正在更新等等），此刻生成的数据快照是不一致的，很有可能无法正常使用。

在微软的Windows Server平台上，这个问题要简单的多，利用windows Volume Shadow Copy Services(VSS)和它的API，数据库应用程序可以集成并调用快照工具。VSS是专门为结构化数据应用设计的服务矿建，可以驱动数据库等应用进入数据一致性的静止状态，在快照开始初始化之前，完成刷新缓存、结束写操作以及系统状态的更新。

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

这里还有一个好办法，可以不通过windows VSS，获得数据库的一致性快照。这个办法需要备份软件的配合。将快照技术的API同备份软件集成，就可以从备份服务器端驱动备份软件的数据库代理Agent。Agent备份代理程序可以驱动数据库进入静止状态，然后反向让备份服务器通知快照工具开始执行创建快照的操作。这也是一个比较有效的办法。

3.GFS的snapshot

GFS的snapshot采用的是写时复制的机制进行的，COW，GFS快照操作几乎可以瞬间完成对一个文件或者目录树（“源“）做一个拷贝，并且几乎不会对正在进行的其它操作造成干扰。我们的用户可以使用快照迅速的创建一个巨大的数据集的分支拷贝（而且经常是递归的拷贝），或者是在做实验的数据操作之前，使用快照操作作备份当前状态，这样之后就可以轻松的提交或者回滚到备份时的状态。

参考：

http://www.db110.com/%E8%BD%AC-%E4%B8%8D%E5%90%8C%E7%B1%BB%E5%9E%8B%E7%9A%84%E5%BF%AB%E7%85%A7%E5%8F%8A%E5%B7%A5%E4%BD%9C%E5%8E%9F%E7%90%86/

http://blog.csdn.net/yuanrxdu/article/details/22887965