数据亲和架构在设计上，要确保数据和程序的亲和性，在程序需要的时候，就可以自动得到所需要的数据。基于数据同步技术，会在多个地方保存数据，在程序失效的场景下，并不会引起数据丢失。失败恢复在数据亲和架构下，不会成为一个关键问题。因此，我们这里要讨论的，不是如何正确失败恢复，而是如何在正确失败恢复情况，做到最快恢复。
从数据规模来看，规模越大的，恢复难度越高。就在不久前，一个顺丰DBA顺手删除了数据库，导致顺丰590分钟下线。不说复杂，就一个简单1G数据文件，要从一台机器拷贝到另外一台机器，都要好几秒，如果在生产环境中，还可以冲击到网络环境，导致其他网络通讯阻塞。在应对这类需要大规模数据迁移的场景，就是要提早将该数据分布到多台机器上，即使某些备份会滞后，真到要用的时候，也只要增量恢复这个滞后部分的数据。
针对大规模数据，还有两个策略可以予以完善。一个是冷、温、热三类数据分层，优先恢复热点数据，访问时恢复温数据，冷数据暂时不管。这个策略光技术手段还不行，需要业务逻辑介入。因为冷数据不代表在业务上不重要，如果业务需要得不到满足，极可能导致这个策略在应用上失效，而被遗弃。另外一个策略，是将数据按关联度分割成多个独立实体，最简单的就是每个表都可以直接视为一个独立实体。再将这些独立实体分散在多个机器上，于是一个大规模的数据，就被拆成一个小规模数据集了。大规模数据恢复的技术难度就不复存在。
从数据延迟来看，实时数据要尽量保持在内存中，而程序尽量在原地重启恢复。在机器或者网络失效的情况下，显然不能原地复活，如何在远程恢复也是必须考虑的问题。和大规模数据相同的是，依然是基于同步技术，不同的是，实时数据是在内存中进行同步。
数据亲和架构，在失败恢复策略上，和其他架构有一个很大的差别。比如K8S是以程序为核心，在一个机器失败时，它会将程序迁移到其他机器上重启，之后再重新加载数据。程序迁移很快，但是数据恢复就不好说了，还要考考虑业务情况。而数据亲和架构要保证数据和程序之间的绑定，所以他会先准备好数据，而将程序迁往他的数据所在。是先程序再数据，还是先数据再程序，这是有本质上的区别。
