這篇博文寫得比較簡短，主要是分享一個實測的數據：同樣的備份文件，在阿里雲雲服務器上恢復需要1小時16分鍾，而在阿里雲RDS中只需10分鍾。
下面是將數據庫從雲服務器向RDS遷移的操作步驟：
測試用的是5型RDS（8G內存，400G存儲，800個最大連接）
1. 在雲服務器上對遷移的數據庫CNBlogsText進行完全備份，備份前該數據庫的恢復模式要是Full。
測試中雲服務器上60G數據庫的帶壓縮的完全備份耗時37分鍾。
2. 進入阿里雲網站上的RD管理控制台，打開“實例應用管理”，切換至“數據庫管理”，點擊“增加數據庫”按鈕。
a. 填入將遷移過來的數據庫名稱
數據庫名稱竟然不允許大寫字母，不知設計者出於什么樣的考慮。幸好SQL Server不區分大小寫，這里填入小寫字母也不影響使用。
b. 然后填入訪問這個數據庫的用戶名與密碼。用戶名不允許大寫字母就算了，連密碼也不允許大寫，密碼不是越復雜越好嗎？這里更搞不懂設計者的意圖。
c. 填好之后，點擊“提交”，然后RDS開始創建數據庫。。。
3. 等數據庫創建好之后，點擊“數據遷入”，獲取FTP信息與備份文件需要更改的文件名（比如這里是cnblogstext_1365466291652.bak）。
4. 回到源數據庫服務器所在的雲服務器，將之前的完全備份文件重命名為cnblogstext_1365466291652.bak。
5. 添加一條路由信息，讓FTP走內網（上傳速度快）
route -p add RDS_FTP_IP 內網網關
6. 用FTP客戶端連接RDS的FTP服務，需要注意的是FTP的加密類型要選擇“要求隱式的 FTP over TLS”。
7. 通過FTP上傳備份文件，在測試中14G文件不到10分鍾完成上傳。
8. 上傳成功后，在RDS的實例應用管理中會看到上傳的文件，如下圖：
9. 然后點擊“數據導入”，通過手機驗證之后，就開始進行導入（實際就是對剛才上傳的備份文件進行恢復操作）。
10. 在測試中，在RDS中恢復只需10分鍾左右，而之前在雲服務器上同樣的備份文件恢復耗時1小時16分鍾。
真是天壤之別！根據阿里雲提供的數據，5型RDS能支撐4000IOPS，而昨天我們的數據庫達到600IOPS，雲服務器就支撐不住，造成數據庫寫入超時。
都是服務器，為什么差距這么大呢？RDS沒有使用阿里雲的虛擬化技術，如果拋開硬件本身的性能差別，RDS與雲服務器之間的差距越大，越說明阿里雲的虛擬化技術任重而道遠。