今天在TWT社區看到一個問題，在這裏分享一下
問題描述：
銀行業數據庫（以Oracle爲例）備份以及依賴備份的開發環境數據恢復架構應該如何建設？
目前我行現有的架構爲：
生產定時通過數據泵（EXPDP）備份出壓縮DUMP——放至多個FTP服務器（採用超大容量廉價硬盤PC，40T-120T）——開發環境從FTP服務器取DUMP——脫敏——使用。
但是現有架構，其實在現今銀行數據量越來越大的情況下早已捉襟見肘，主要問題反應在以下幾點：
（1）數據庫數據大後，expdp導出的時間較長，一些OLAP數據庫已經無法在非業務時間段完成備份。
（2）導出時對生產IO影響較大，會影響夜間一些批處理工作的。
（3）對於大庫的開發環境恢復，導入+脫敏的時間非常長，會造成開發人員的無意義等待。 請問，目前是否有哪家銀行有好一點的備份、利用備份開發環境恢復的方案？還望不吝賜教。
之前也有了解過一些解決方案，但是有以下幾點顧慮，也不知道諸位在實際使用中是否有遇到：
（1）如果使用專業備份設備、軟件，如NBU、EMC DD，即利用rman+archive log的方式備份，那麼歸檔的過大，是否會造成大量浪費？
（2）利用rman+archive log的備份片，如果想在開發環境恢復，應該較爲麻煩，如何解決？我行生產數據庫可能有近10個系統，如果僅僅想恢復一個系統數據到開發環境，如何實現？
（3）利用存儲快照進行備份，開發環境使用快照。這種情況我不清楚對於存儲的要求有多高，但假設要保留近3年的數據，我想這個成本應該是非常大吧？不知道有無銀行是這種架構，使用感如何。 感謝，感謝。
問題分析：
當前存在的問題有以下幾個：
1、備份時間長原因：一方面是由於數據量大；一方面是由於備份方式不得法！
2、備份方式問題：採用expdp方式，這個問題我覺得比較大，這麼大的數據量，備份頻率不可能太高，一旦出現問題丟失的數據量可能是不能承受的；
3、開發環境準備時間長，這個問題很明顯，數據量大，全部靠人工導入、導出，時效性肯定不行；另外這也造成開發測試環境數據的新鮮度不夠；
4、脫敏只是一個功能性的要求，這個沒什麼問題，所需要考慮的就是如何和所需的要求實現高度的集成，形成自動化操作；
解決辦法
分析問題，結合現在市面上在備份容災方面各種解決方案，竊以爲只有CDM是最爲合適的解決方案；
CMD的優勢如下：
1、能夠實現永久增量備份，每天只備份增量變化數據，能夠大大減少備份時間，減少對生產系統的資源佔用；數據庫越大越合適；
2、備份數據的保存是原始格式，備份數據可以從CDM直接掛載使用；
像搭建測試環境這種事情，能夠直接把備份數據掛載到測試服務器使用，不涉及數據的導入導出，不佔用額外的存儲空間；既能很快的搭建測試環境，又能保證測試數據的新鮮度；同時節省大量的存儲空間，性價比極高；
3、一份備份數據，可以虛擬掛載成多個出來，不佔用實際存儲空間；滿足搭建多測試環境的要求；
4、針對脫敏環境，可以直接將備份數據掛載至脫敏服務器進行脫敏，同時可以將脫敏後的數據再保護，受保護的脫敏數據可以再次的多次掛載給別的測試服務器使用；
解決方案拓撲
解決方案拓撲了解一下
————————————————
版權聲明：本文爲CSDN博主「soosec」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/soosec/article/details/104849442