一致性问题一般是指数据前后之间的逻辑关系是否一致（正确和完整）。简单举例来说，比如A用户正在写数据N的时候，B用户开始读数据N，由于A用户刚写了一半，所以B用户读的数据就不是前后逻辑一致性的，这就是一致性问题的一种。
一致性问题在各个领域都存在，提的比较多的是分布式存储的一致性问题，数据库的一致性问题，以及崩溃一致性问题。
我们黑方主要涉及到的可以认为是数据备份中的一致性问题，和上面说到的一致性问题有关联性，又不完全相同。
数据备份中的一致性问题是指备份的文件及数据是否和待备份数据保持一致。主要两个因素导致：
1、由于各种cache的存在，导致实际存储在硬盘上的数据和用户实际看到的并不一致；
2、在备份过程中，数据又可能发生变化，导致前后备份的数据处于不一致状态。
对于备份中的一致性问题，黑方的解决方案按备份方式的不同而有变化：
1、对于定时备份来说：
（1）普通文件定时备份，windows系统，可以采用vss卷影的方式备份来解决一致性问题，VSS服务本身保证了在创建卷snapshot时数据是一致的。
（2）数据库文件备份，可以用数据库提供的备份接口来解决，由这些接口API来负责提供数据一致性保障；
对于没有提供接口API的，就以普通文件形式直接备份，此时是存在崩溃一致性问题的，就是备份过程中数据发生变化，但考虑到数据库自身的健壮性，一般会检查到数据不一致，从而触发回滚到上一个一致性的状态，在实际使用过程中，是可行的（不过理论上不完美）。
（3）OS系统备份，windows下也是用vss卷影的方式；linux用文件打包的方式，文件的粒度相对于整个卷来说比较小，这样可以认为是近似数据一致（理论上不完美，但实际可行）。
2、对于实时备份来说：
黑方的实时备份主要是两方面，文件cdp以及卷cdp。
两者对于一致性的处理基本方法一致，首先做完整备份，备份之前在驱动层做snapshot，然后开始备份，备份过程中如果发生数据更新，依据数据的不同会有两种处理方法：
（1）、文件cdp会将数据更新的部分先备份下来，然后更新到备份集里；
（2）、卷cdp会将数据更新的部分加上脏标志，在备份完毕后重新对脏标志的数据再次进行备份。
总结来说，黑方就是尽可能保证数据一致性，如果实在达不到，就要做到崩溃一致性。
崩溃一致性通常是指突然断电或死机崩溃时的数据所处的一致性状态，理论上任何app都应该能处理突然断电的情况，所以能做到崩溃一致性也可以满足需求。