阿里雲資料庫備份DBS商業化釋出，你想知道的都在這裡

一、產品概述

資料庫備份這款產品的英文名稱為Database Backup，簡稱DBS，它是為資料庫提供連續資料保護、低成本的備份服務。正如下圖中右側的DBS整體架構圖所示，大家可以看到使用者的資料庫無論是在企業的資料中心、其他雲廠商、還是公網上，都可以通過阿里雲DBS備份到阿里雲上的OSS物件儲存中；如果使用者的資料庫已經上雲了，比放在使用了阿里雲RDS或者在ECS上自建了資料庫，也可以藉助阿里雲的VPC或者經典網路，通過DBS也可以備份到使用者的OSS上面。總而言之，阿里雲DBS可以雲上、雲下或者其他雲環境中提供強有力的保護。在功能上面，大家可以看到資料庫備份提供了資料備份和操作恢復等整體的解決方案，實現了實時的增量備份，並且能夠實現秒級資料恢復的能力。

大家可以體會到阿里雲DBS的一些比較顯著的特點，一個是秒級RPO，當進行恢復的時候可以選擇任意的時間點進行，除此之外阿里雲DBS對接物件儲存的整體方案的成本也很低，並且阿里雲DBS還能夠支援多種環境。

二、產品優勢

接下來為大家分享阿里雲DBS資料庫備份產品的優勢。其實，阿里雲DBS資料庫備份產品的優勢主要有以下五個：靈活易用，無學習門檻；高效能，適應不同規模要求；低成本，降低整體TCO；零風險，海量使用者驗證；多環境，覆蓋阿里雲場景。

優勢1：靈活易用，無學習門檻

對於阿里雲DBS這款產品而言，使用者從購買到配置再到執行，基本上僅用5分鐘的時間就可以完成。正如下圖所示的就是DBS的整體使用過程。

首先，使用者需要購買一個DBS的例項，之後需要配置一下自己的備份源，所謂備份源也就是使用者想要通過DBS來備份哪個資料庫，只要將資料庫的連線串以及賬號密碼輸入進去，也就完成了備份源的配置。

第二步，客戶需要配置整個備份的目標，也就相當於要將資料庫通過DBS備份到OSS上去。

第三步，使用者需要配置資料庫所需要備份的是整個例項還是單個資料庫，備份的是單張表還是多張表。對於整個細粒度的備份，DBS都可以支援使用者進行自由選擇。

第四部分，使用者可以設定備份的時間，因為DBS會提供全量備份和增量備份兩種功能，只要使用者開啟了增量備份之後，系統就會實時地進行備份；而全量備份可以設定一週七天每天都備份或者每週只備份一次，備份的頻率和時間都可以根據使用者的需求靈活地進行設定。一般而言，資料備份往往會選擇在業務的低峰期，比如凌晨兩點鐘至凌晨五點鐘。

第五步就是在備份啟動之後，將備份的資料存放到使用者的OSS上，那麼使用者這些備份的資料需要存放多久，什麼時候進行清理以及什麼時候進行轉存，阿里雲DBS都提供了全域性的規則設定。

當使用者對於這些規則進行設定之後，後面的相關操作都會由DBS自動完成。在整個備份和恢復上面，阿里雲DBS都提供了一個統一的Web介面，那麼這樣一來，使用者無論是做資料備份還是資料恢復就不用來回切換工作介面了。這也就是DBS的第一個優勢，它可以讓使用者更加靈活易用，使用者只需要進行簡單的配置就可以執行起來，因此學習成本比較低。

優勢2：高效能，適應不同規模要求

當使用者在第一步配置完備份計劃之後，整個備份就開始處於執行狀態中了。阿里雲DBS提供了全量備份和增量備份兩種備份計劃如下圖左側所示，在全量備份中，DBS採用了無Agent的方式，也就是使用者只需要提供IP、域名、賬號和密碼配置一下就可以了。在整個全量的備份過程中，DBS提供了無鎖的備份，其含義相當於在備份的過程中不會影響到使用者資料庫上面線上的業務查詢，因為大家都知道資料庫除了備份之外還需要承載一些線上的業務的查詢，而DBS在整個備份過程中不會影響到線上查詢業務。此外，阿里雲DBS還提供了併發的備份，因為當資料庫的資料量比較大的時候，併發地進行備份可以大大地提升備份的速度。而在這個過程中包含了大量的創新點，比如阿里雲DBS會探測資料庫的繁忙程度，並且會調節全量備份在拉取資料的時候分片的大小、每次要拉取的資料量，以及併發的執行緒數等。

上面講解了全量備份，接下來為大家分享增量備份。當DBS做增量備份的時候，它會從資料庫記憶體中實時地捕獲日誌，每當產生一條日誌就會去捕獲這條日誌並被分到使用者的OSS上面，這樣就可以實現資料的實時增量備份，也會讓使用者的RPO能夠達到秒級甚至更低。

當有了備份之後，其實使用者還需要做恢復操作。對於資料恢復而言，阿里雲DBS提供了幾個有價值的功能。首先，阿里雲DBS能夠支援單表的恢復，當進行備份的時候一般會選擇整個例項或者單個資料庫，但是當進行備份的時候，一般情況下其實並不需要將整個例項的資料全部恢復出來，很有可能對於500G的資料而言，想要恢復的只有裡面的一張表幾百M或者一個G的資料而已，而阿里雲DBS恰恰就提供了表級別資料或者單表的資料恢復功能，使用者需要哪張表的資料，DBS就幫助使用者恢復哪一張，這個功能點在使用者資料出現問題需要緊急恢復的時候，可以大大地降低使用者恢復資料庫故障的所需時間。而資料庫恢復過程如果平時沒有經過演練，通過指令碼等方式臨時抱佛腳會遇到各種各樣的問題，DBS提供了這種Web介面，並且提供了引導式操作，這樣一來從選擇恢復的時間到選擇恢復的物件在Web介面上都有明確的引導，可以幫助使用者一步一步地進行恢復。DBS作為SaaS級別的雲產品，它天生就支援彈性擴充套件。除此之外，阿里雲DBS目前還提供了多種例項規格，可以支撐企業在不同階段對於效能的要求。上圖就主要介紹了DBS在高效能上面能夠適應不同規模企業的要求。

優勢3：低成本，降低整體TCO

在沒有DBS之前，使用者基本上會採用自建的資料庫備份系統，一般情況下，使用者可以採用指令碼、資料庫開源工具以及NAS和磁帶等構成的自建備份系統。指令碼以及開源工具等都是免費的，但是企業往往卻需要投入一定的人力成本對資料庫備份系統進行開發、維護以及後續升級，之後還需要採購NAS以及磁帶、磁碟等儲存裝置。因此，企業不可避免地需要一次性地投入大量的資產，而相比而言，如果使用者使用了阿里雲DBS，就可以實現按量付費，使用者可以先購買一個DBS例項，這樣也是比較划算的，使用者可以先做一些測試、試用和調研，然後根據所需要備份的資料規模不斷地選擇增加投入，因此使用阿里雲DBS在成本上具有較大的優勢。包括使用者在實際進行資料備份儲存的時候，阿里雲物件儲存OSS也為使用者提供了非常好的不同價效比的備份型別，包括標準儲存、低頻訪問以及歸檔儲存等，而這些在DBS上面可以幫助使用者進行自動的儲存分級，使用者可以通過設定相應的規則確定DBS在哪一天需要將標準儲存轉移到歸檔儲存上面，因此阿里雲DBS非常適合使用者需要對於長期儲存資料進行歸檔的場景。而且隨著使用者投入的使用量的不斷增多，使用者使用的單價也是越來越低的。

如上圖所示，這裡就是採用雲資料庫備份DBS的解決方案和傳統自建資料庫備份方案的對比情況。在正常情況下，使用者自建的資料庫備份系統需要指令碼、開源工具以及NAS等，此外還需要磁帶等儲存裝置，除了對於這些儲存硬體的投入之外，還有一些隱藏的成本，而隨著備份以及歸檔的時間增多，磁帶庫的硬體成本、管理成本以及多份資料的冗餘成本等很多隱藏成本會逐漸加大備份系統的整體成本，因此推薦使用者嘗試使用雲資料庫備份解決方案。因此，阿里雲資料庫備份DBS的第三點優勢就是可以幫助使用者整體地降低在資料庫備份的TCO。

優勢4：零風險，海量使用者驗證

其實大家能夠看到，在整個資料庫備份以及恢復過程之中，無論是在阿里雲上面還是使用者自建的機房中，使用者的資料庫都會有VPC、安全組策略或者本地網路上面的隔離策略。在備份的過程中，資料一旦離開了資料庫，DBS就會提供SSL這種傳輸的加密，將傳輸的資料拉取到DBS這邊。在控制檯上面大家就能看到，對於DBS本身而言，可以支援主子賬號，並且對於任務狀態以及效能等都有云監控，而DBS本身也有HA高可用這種保障。而DBS接下來會通過HTTPS將資料存到使用者的OSS上面，這個步驟的資料安全性也是沒有任何問題的。而儲存到物件儲存OSS上面的資料也是通過了AES256加密的，而且這些備份資料也做到了使用者的隔離，不同的使用者只能看到自己的資料。當整個資料備份過程結束之後，使用者可以隨時地驗證備份的有效性以及備份的正確性，並且可以隨時進行恢復驗證。因此，阿里雲資料庫備份DBS的第四大優勢就是零風險，而且已經經歷了海量的使用者充分的驗證，藉助於阿里雲DBS，使用者可以快速地發現問題並及時地進行修復，這樣的迭代速度是傳統自建資料庫儲存備份方式根本沒有辦法比擬的。

優勢5：多環境，覆蓋阿里雲場景

阿里雲資料庫備份DBS的第五個優勢就在於對多種環境的支援上面。在下圖中大家可以看到，DBS除了能夠支援整個阿里雲上面的RDS、ECS自建庫等，其實還支援在使用者自己本地的IDC資料中心上面建立的資料庫。這時候就會出現一種場景就是使用者希望先將自己本地的資料庫備份到雲上面，此時使用者可以通過DBS將資料庫備份到自己在阿里雲上的OSS上面，這時候就實現了整個上雲的備份。對於上雲備份而言，使用者可以選擇公網，通過阿里雲上面的高速通道、專線以及VPN閘道器將本地的資料庫備份到阿里雲上面。第二類場景就是如果使用者在其他的雲上面也有資料庫，使用者可能並不想將全部的資料都放在一個“籃子”裡面，因此在阿里雲上面也提供了跨雲的災備方案，使用者可以將其他雲上的資料庫通過阿里雲的DBS備份到阿里雲OSS上面。而在下圖的上半部分，大家可以看到如果使用者的資料庫已經在阿里雲的RDS或者ECS自建庫上面了，也可以通過DBS備份到OSS上面，這樣一來其實就實現了阿里雲的雲中資料備份。

而在企業中，往往會有一些行業合規以及資料安全性的要求，因此可能需要資料備份不僅僅只有一份，而會需要在不同的地方存在多份資料備份。針對這樣的需求，阿里雲DBS也提供了異地的災備。舉個例子，如果使用者的資料庫在杭州，那麼就可以將使用者的資料庫備份到杭州的OSS，同時將這份備份資料放到使用者位於深圳的以及北京的OSS上面，其實這樣就幫助使用者解決了異地災備的訴求。阿里雲OSS上面還提供了歸檔型別，這非常適合於使用者將出於審計合規的因素需要將一些資料必須存放2到3年甚至是5年的要求，而通過DBS將資料存放到歸檔OSS上面則可以實現使用者的資料歸檔需求。

三、產品架構

阿里雲DBS產品架構

以上就為大家介紹了阿里雲DBS的五個優勢，接下來進入本文的第三部分，為大家介紹DBS整個產品的架構。如下圖所示的阿里雲DBS產品的架構圖，DBS主要面向的客戶包括資料庫管理員也就是DBA、IT管理人員、架構師以及研發人員。DBS從功能上面提供了全量的備份，進一步細化則會包括備份預檢查、結構備份、資料備份以及備份校驗等子模組。此外，DBS還提供了增量備份，在備份結束之後還提供了資料的恢復功能。在下圖的右側展示了服務的場景，阿里雲DBS能夠支援ECS自建資料庫、公網資料庫、混合雲專線部署、阿里雲RDS、專有云以及內網資料庫等。目前，DBS在資料來源支援上面而言，可以支援四種資料來源：MySQL、SQL Server、MongoDB以及Oracle，未來也會進一步擴充套件。

阿里雲DBS的備份流程

接下來為大家介紹阿里雲DBS的備份流程。首先，一定要有一個源資料庫，其實也就是使用者需要備份的資料庫，當啟動備份的時候，DBS會首先做一個預檢查，在這裡就需要檢查使用者的資料庫是否符合備份的條件，比如資料庫的型別是否合適、版本是否支援、binlog是否已經開啟等，這些條件都需要提前進行檢查，而不是在備份時出現問題後再報錯。一旦預檢查通過之後，阿里雲DBS就會啟動結構的備份，此時會將資料庫上面的資料庫物件，比如表結構、儲存過程以及索引等都幫助使用者備份下來放到OSS上面，之後DBS就會啟動全量的備份，此時就會通過SQL查詢併發地讀取全量的資料，而也會在讀取速度和資料庫的影響上面找到一個平衡點，也就是在不影響到線上業務查詢請求的前提之下，儘快地完成資料備份。在全量備份的過程中，也會同時啟動增量的備份去實時地從資料記憶體中捕獲日誌並且放到使用者的OSS上面。那麼預檢查、結構備份、全量備份以及增量備份就構成了整個DBS備份的流程。

阿里雲DBS的恢復流程

當資料備份成功之後，如果使用者想要做資料恢復的時候，阿里雲DBS所提供的恢復流程是什麼樣的呢？因為資料是備份到OSS儲存上面的，那麼當進行恢復的時候，使用者需要提供一個資料庫來做恢復，那麼這個時候阿里雲DBS首先會檢查使用者選擇時間的資料是否存在，還要檢查所需要恢復資料庫的版本等問題是否匹配。而在自建的系統上面經常會遇到所選擇的備份資料不存在的問題，因為當資料備份上去之後，經過了半年或者一年的時間，很有可能在使用者不知道的情況下資料就已經被刪除掉了，而當真正進行資料恢復的時候才會發現這個問題，而這往往會造成很大的風險，阿里雲DBS將會提前做好預檢查。而當預檢查恢復之後就需要啟動結構恢復的第二部分，DBS會從OSS上面將之前備份好的表結構恢復過來，這樣當第二步完成之後，在恢復的資料庫上面就已經有了表結構。之後就會進行第三步，從OSS上面讀取全量的資料並進行恢復。第四步還是進行結構的恢復，它會將相關的索引、外來鍵這些資料庫的物件恢復上來。緊接著的最後一步就是根據使用者選擇的時間點進行日誌解析，當使用者選擇的恢復時間點是全量備份的時間點，就不需要增量恢復了。而大多數情況下，使用者所選擇的時間點都是在全量備份之間的某個時間點，因為DBS支援任意時間點的資料恢復。在全量恢復之後，DBS會啟動增量日誌的恢復，恢復到使用者指定的時間點，將增量的日誌應用到這些資料上面。當增量日誌恢復完成之後，大家就可以看到恢復的資料庫上面就已經有了使用者想要的資料了。

阿里雲DBS秒級RPO實現原理

所謂RPO的意思通俗理解來說其實就是當資料庫發生了故障將會允許丟失多久的資料。這對於使用者而言也是很好判斷的，當然是希望儘量不丟失資料，或者讓丟失的資料儘量少。舉個例子而言，如果選擇一週做一次全量備份，當資料庫出現問題的時候丟失資料在極限情況下可能就是一週的業務資料；而如果選擇一天做一次全量備份，那麼RPO就是一天，也就是當資料庫出現故障或者問題的時候，最多隻能丟失一天的業務資料。如果使用者選擇了阿里雲DBS並開啟了增量備份，那麼就能實現秒級RPO，也就是說當使用者資料庫出現故障的時候，可以幫助其將資料恢復到任意的時間點，可以精確到秒級別。

如上圖所示，如果使用者在1點鐘做了操作，向資料庫中插入了一條資料“a=1”，當在1點半的時候使用者又做了update“a=2”，而在2點鐘又update“a=3”，在2點半又update“a=4”，在使用者操作過程中，如果開啟了DBS，那麼增量會持續地備份和保護資料庫。當我們想要將資料恢復到2點15分的時候，因為全量備份能夠恢復到1點15分，然後應用binlog一直到2點15分，那麼此時a的資料就能夠恢復到2點15分了，這樣也就實現了秒級RPO和任意時間點的資料恢復。