資料親和架構在設計上，要確保資料和程式的親和性，在程式需要的時候，就可以自動得到所需要的資料。基於資料同步技術，會在多個地方儲存資料，在程式失效的場景下，並不會引起資料丟失。失敗恢復在資料親和架構下，不會成為一個關鍵問題。因此，我們這裡要討論的，不是如何正確失敗恢復，而是如何在正確失敗恢復情況，做到最快恢復。

        從資料規模來看，規模越大的，恢復難度越高。就在不久前，一個順豐DBA順手刪除了資料庫，導致順豐590分鐘下線。不說複雜，就一個簡單1G資料檔案，要從一臺機器拷貝到另外一臺機器，都要好幾秒，如果在生產環境中，還可以衝擊到網路環境，導致其他網路通訊阻塞。在應對這類需要大規模資料遷移的場景，就是要提早將該資料分佈到多臺機器上，即使某些備份會滯後，真到要用的時候，也只要增量恢復這個滯後部分的資料。

        針對大規模資料，還有兩個策略可以予以完善。一個是冷、溫、熱三類資料分層，優先恢復熱點資料，訪問時恢復溫資料，冷資料暫時不管。這個策略光技術手段還不行，需要業務邏輯介入。因為冷資料不代表在業務上不重要，如果業務需要得不到滿足，極可能導致這個策略在應用上失效，而被遺棄。另外一個策略，是將資料按關聯度分割成多個獨立實體，最簡單的就是每個表都可以直接視為一個獨立實體。再將這些獨立實體分散在多個機器上，於是一個大規模的資料，就被拆成一個小規模資料集了。大規模資料恢復的技術難度就不復存在。

        從資料延遲來看，實時資料要儘量保持在記憶體中，而程式儘量在原地重啟恢復。在機器或者網路失效的情況下，顯然不能原地復活，如何在遠端恢復也是必須考慮的問題。和大規模資料相同的是，依然是基於同步技術，不同的是，實時資料是在記憶體中進行同步。

        資料親和架構，在失敗恢復策略上，和其他架構有一個很大的差別。比如K8S是以程式為核心，在一個機器失敗時，它會將程式遷移到其他機器上重啟，之後再重新載入資料。程式遷移很快，但是資料恢復就不好說了，還要考考慮業務情況。而資料親和架構要保證資料和程式之間的繫結，所以他會先準備好資料，而將程式遷往他的資料所在。是先程式再資料，還是先資料再程式，這是有本質上的區別。