损坏的文件不存在SAN到SAN复制的危险,除非它是主站点上的文件服务器破坏它们.每个提供基于块的存储(LUN)复制的SAN都有一些防止损坏和保证一致性的机制.这是一个比大多数人都知道的更棘手的问题,因为出于优化原因,写入通常不按顺序应用于磁盘,即使没有复制也是如此.这就是为什么大多数存储的写缓存都有某种电源故障安全网(如电池或UPS)：没有写入只保存在缓存中,底层磁盘可能已损坏.通常情况下这是可以的,但是如果断电,则需要确保存储器确认的最后一次写入保存到磁盘,以便在磁盘出现时使磁盘保持一致.

复制处理方式有所不同,具体取决于您的复制方式：

>同步复制可确保一致性,因为它不会向本地服务器返回写入确认,直到它确认写入已将其安全地发送到辅助站点.这大大减慢了写入速度,并且没有供应商支持在相对较低距离的恒星连接上执行此操作.实际上,支持的距离通常很低,以至于你很容易受到同样的飓风的影响.很难看到,通常不是唯一的.
>异步检查点复制是迄今为止最常见的算法,绝大多数开放系统存储都使用该算法.该框将定期复制一致的检查点,这意味着它将确保在远程系统上找到的可恢复副本没有丢失的写入.如果它在检查点中间被中断,它会丢弃它并转到最后一个已知的一致点.我见过的系统,只要你的WAN支持它,就可以使用这种方法让你的恢复点为15秒.
>异步有序传递复制比检查点更难和更难,但在我看来是异步算法中最好的.它的作用是按照它们完成的顺序在WAN上发送写入.问题在于,与检查点复制不同,如果这种情况落后,则无需刷新完全重新同步(重新发送所有数据),就无法刷新用于保存未发送写入的存储.通常,如果链接无法跟上写入,它将回退到检查点模式,并在获得最近足够的检查点后再次开始按顺序传递. EMC的恢复点和Hitachi的HUR都这样做,但我没有看到任何其他供应商这样设置.

所有这些机制都为您提供“崩溃一致性”.磁盘处于与突然关闭服务器电源时相同的状态.从崩溃一致的副本中运行文件系统和数据库需要一些工作,但它总是可行的.如果您想要更多内容(您在问题中提到的“更高级别”),则需要将复制与应用程序集成.这通常意味着暂停对应用程序的写入,等待所有内容都已转储到存储,然后启动复制的一致性点.这称为“应用程序一致性”.它通常会提供稍微更旧的恢复点,但恢复时间略低于崩溃一致性.