我可以製作EBS卷的真正增量跨區域快照副本嗎？

Question

通過閱讀文檔，看起來相同卷的快照副本是增量式的。但是，當我將該卷的快照複製到另一個區域時，即從us-east-1到us-west-2，這看起來並不是我所看到的，性能明智的。

我會真的喜歡做的事是創建卷直接到西部地區的初始快照，但似乎並沒有成爲一種選擇。所以我必須先在東部創建一個快照，這個快照的唯一目的是複製到西部。

那麼我現在做的是

1. 創建東臨EBS卷的快照。這確實表現得好像是增量式的，比來自相同大小的不同卷的新原始快照要快得多。
2. 通過定期輪詢新的快照編號
3. 等待直到此快照完成後，將新快照從東向西複製。這似乎沒有像增量式那樣表現出來，每個人花費的時間和原始快照一樣多，而且大小相當穩定。

它所似乎喜歡我是因爲它不是直接從卷或相同的快照每次複製，快照複製到西不知道是增量。

當然，我也願意接受我以而不是看到我認爲我看到的東西，而跨區域快照副本確實是增量式的。但是考慮到每當它沒有這種感覺時，複製需要9個小時才能完成。我所閱讀的大多數文檔似乎都是從同一個EBS卷中增加的，而當我對向西拷貝的快照進行描述時，它沒有提到原始卷ID，而是一個虛擬ID，而不是當然是WAD。

- 對數據

的自然背景信息只是一些信息，因爲有些人可能想知道給我們的副本病程延長到西有多少數據 - 原來EBS卷的數據量ec2實例用於存儲由其專有備份工具生成的源代碼控制系統的備份。

數據卷有幾個「供應商快照」，這些快照是在rsync下創建的，所以每個新的「供應商快照」在運行和很多通用性之間都有很多硬鏈接，可能有5％數據在AWS快照副本之間切換。
總的EBS卷大小爲3TB，其中40％是未使用的空間，因爲我們減少了我們保留的併發備份數量。

Answer 1

我回到了這個問題，並再次挖掘文檔。我不知道是否有文檔的補充，或者我最初錯過了，但現在有文檔解釋它。 爲了使加密的跨區域快照副本爲增量式，您必須使用默認的加密密鑰。 執行此操作後，我們的跨區域副本從4-12小時之間的任何地方到10-35分鐘之間。爲我們的災難恢復實現合理的RPO更容易管理。