1.Cache引起的数据一致性问题
主要原因是位于数据IO路径上的各种Cache和Buffer（包括数据块Cache，文件系统的Cache，存储控制器的Cache，磁盘Cache等），由于不同系统模块操作处理数据IO的速度有差异，所以就需要添加Cache来缓存IO操作，适配不同模块的处理速度。这些Cache在提高系统处理性能的同时，也可能会‘滞留’IO操作，带来一些负面影响。如果在系统发生故障时，仍有部分IO‘滞留’在IO操作中，真正写到磁盘中的数据就会少于应用程序实际写出的数据，造成的数据不一致。当系统恢复时，直接从硬盘中读出的数据可能存在逻辑错误，导致应用无法启动。尽管一些数据库（Oracle，DB2）可以根据redo日志重新生成数据，修复逻辑错误，单着过程是非常耗时的，而且也不一定每次都能成功。对于一些相对功能较弱的数据库（SQL Server），这个问题就更加严重了。
解决办法
关闭Cache或者创建快照。尽管关闭Cache会导致系统系统性能下降，但在有些应用中，这却是必要的选择。比如一些高等级的容灾方案中（RPO为0），都是利用同步镜像技术在生产中心和灾备中心之间实时同步复制数据。由于数据是实时复制的，所以就必须要关闭Cache。
快照的目的是为数据卷创建一个在特定时间点的状态视图，通过这个视图只可以看到数据卷在创建时刻的数据，在此时间点之后元数据卷的更新（有新的数据写入），不会反映在快照视图中。利用这个快照视图，就可以做数据的备份或者复制，那么快照视图的数据一致性如何保证？
这涉及到多个实体（存储控制器和安装在主机上的快照代理）和一系列的动作。典型的操作流程是：存储控制器要为某个数据卷创建快照时，通知快照代理；快照代理收到通知后，通知应用程序暂停IO操作（进入backup模式），并flush数据库和文件系统中的Cache（强制将缓存中的数据写入到文件或者数据库，写满了在发），之后给存储控制器返回消息，指示已可以创建快照；存储控制器收到快照代理返回的指示消息后，立即创建快照视图，并通知快照代理快照创建完毕；快照代理通知应用程序正常运行。由于应用程序暂停了IO操作，并且flush了主机中的Cache，所以也就保证了数据的一致性。
创建快照是对应用性能是有一定的影响的（以Oracle数据库为例，进入Backup模式大约需要2分钟，退出Backup模式需要1分钟，再加上通信所需时间，一次快照需要约4分钟的时间），所以快照的创建不能太频繁。
2.时间不同步引起的数据一致性问题
引起数据不一致性的另外一个主要原因是对相关联的多个数据卷进行操作（如备份、复制）时，在时间上不同步。比如一个Oracle数据库的数据库文件、Redo日志文件、归档日志文件分别存储在不同的卷上，如果在备份或复制的时候未考虑几个卷之间的关联，分别对一个个卷进行操作，那么备份或复制生成的卷就一定存在数据不一致问题。
此类问题的解决方法就是建立“卷组（Volume Group）”，把多个关联数据卷组成一个组，在创建快照时同时为组内多个卷建立快照，保证这些快照在时间上的同步。之后再利用卷的快照视图进行复制或备份等操作，由此产生的数据副本就严格保证了数据的一致性。
3.文件共享中的数据一致性问题
通常采用的双机或集群方式实现同构和异构服务器，工作站与存储设备间的数据共享，主要应用在非线性编辑等需要多台主机同时对一个磁盘分区进行读写。
在NAS环境中，可以通过网络共享协议NFS或者CIFS做到数据的共享。但是如果不在NAS环境中，多台主机同时对一个磁盘分区进行读写会带来数据一致性的问题，造成文件系统被破坏或者当前主机写入后其他主机不能读取当前写入数据的问题。
可以通过使用数据共享软件装在多台主机上来实现磁盘分区的共享。由数据共享软件来调配多台主机数据的写入，保证数据的一致性。