恢复失败可能是一个复杂的问题，特别是对于分布式系统，其中可能有多个参与设备和多个故障点。在程序中找到不同的角色并询问每个角色，“如果程序的那部分失败会发生什么？”这是非常有益的。设计一个可以从故障中恢复的可靠系统需要识别系统必须处理的故障类型。
在分布式系统中，我们主要需要处理四种类型的故障 -
交易失败（中止），
站点（程序）故障，
媒体（磁盘）故障，以及
通讯线路故障。
其中一些是由于硬件，一些是由于软件。
在任何系统中，事务都可能因各种原因而失败。不这样做可能是由于不正确的输入数据和检测到当前或潜在问题而导致的交易错误。此外，一些同步现金管理算法不允许交易继续或等待他们当前尝试访问的数据被其他服务检索。这可以被认为是失败的。
在事务失败的情况下最常见的方法是采取行动，从而在此事务开始之前将数据库重置为其原始状态。
系统故障的原因可以通过识别是硬件故障还是软件故障来追溯。系统故障通常被认为会导致核心内存内容丢失。因此，由于系统故障，主内存条中的数据库的任何部分都将丢失。但是，存储在二级存储上的数据库被认为是安全和准确的。
在分布式数据库名称中，系统故障称为站点故障，因为它们会导致故障站点在分布式系统中的其他站点上不可用。
我们经常区分分布式系统中的轻微故障和完全故障。完全失效是指分布式系统中所有站点同时失效；部分故障仅反映特定站点的故障，其他站点仍可运行。可以通过尽快重新启动系统并在确定故障点后更换故障点来恢复。
媒体故障是指辅助数据存储设备的故障。此类故障可能是由于操作系统错误和硬件错误，例如头痛或控制故障。关键点是第二个存档中的全部或部分数据库被认为是降级和不可访问的。集成磁盘存储和归档是处理此类灾难性问题的常用策略。
媒体故障通常被视为局部问题，因此无法在分布式 DBMS 系统的可靠性中直接解决。
存在多种类型的通信故障。最常见的错误是消息排序不正确、消息丢失和通信线路故障。前两个错误是计算机网络的功能；我们不会进一步研究它们。因此，在我们的 DBMS 忠诚度分配谈判中，我们期望计算机网络下的硬件和软件能够确保从特定站点的站点从进程发送到目的地的两条消息都没有任何错误地发送。
丢失或未经请求的消息通常是通信线路故障或（目标）站点故障的结果。如果通信线路出现故障，除了丢失发送的消息外，还可能将网络分成两个或多个不相关的组。这称为网络碎片。如果网络碎片化，每个部门的站点可能会继续运行。在这种情况下，使访问存储在多个分区上的数据的事务成为一个重大问题。