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環境中，多台主機同時對一個磁盤分區進行讀寫會帶來數據一致性的問題，造成文件系統被破壞或者當前主機寫入后其他主機不能讀取當前寫入數據的問題。
可以通過使用數據共享軟件裝在多台主機上來實現磁盤分區的共享。由數據共享軟件來調配多台主機數據的寫入，保證數據的一致性。