Ucloud秒级存储恢复试用记

defunct9

　　本身公司是搞金融的，对数据的时间敏感性比较高，ucloud推出了秒级别的自动备份，自然是大大的利好，应该可以极大解放运维的工作，赶紧申请帐号测试一把，看看是否适合自己的场景。

　　Ucloud还是非常注重这次测试的，有专员联系了自己，给账户里充值了300元，足够租用一个月了。

　　创建虚拟主机的时候本来想选北美线路试试的，结果创建好了才知道北美不支持秒级备份，删除了主机，钱也没退回来，呵呵。这下惨了。没关系，创建个试用的，用5天测试即可。

　　创建的过程很简单明了，选线路、CPU、磁盘，带宽，很顺利的就创建成功了。

　　在创建的过程中打开登录，因为这是直接连接到虚机的serial串口的，所以创建的过程也一目了然：
　　

　　可以看出，创建虚机的脚本是/ucloud_boot/bootscrap.sh，随后调用了modules下的很多脚本模块来执行:
　　/ucloud_boot/bootstrap.sh
　　modules/100-interface.sh
　　modules/101-cleanup-ethX-bak.sh
　　modules/110=dns.sh
　　modules/120-hostname.sh
　　modules/150-fix-epel-key.sh
　　modules/200-password-root.sh
　　然后是mke2fs 建立磁盘
　　随后调用
　　modules/300-disk.sh
　　modules/400-remove-nginx-repo.sh
　　modules/700-add-rpmforge-repo.sh
　　modules/701-add-remi-repo.sh
　　modules/702-add-ucloud-repo.sh
　　modules/703-add-10gen-repo.sh
　　...
　　modules/800-skip-fstab-check.sh
　　modules/801-update-ntp-server.sh
　　modules/803-disable-service.sh
　　modules/850-optimize-sysctl.sh

　　从上面可以得出一些有效的信息，Ucloud创建主机的时候是调用了bootstrap.sh来总控，模块中100是跟网络有关的，200是修改密码，300是跟磁盘有关的，400是nginx，700是repo相关，800是善后工作.....

　　从chrome里选择登录窗口非常简洁，易用：

　　

　　这个登录方式非常喜欢啊，试一试能否则手机上使用，在手机上打开ucloud的网页：

　　

　　果然是可以打开登录的：

　　

　　可以进入，但是，没有输入区，无法输入字符，建议Ucloud能否调试一下，开通，那就方便了：

　　

　　不过即使web的登录方式在手机上不太能用，我们依然可以安装iphone的Serverauditor或者android下的JuichSSH，都能很方便的从手机上通过SSH管理服务器。


　　开始秒级备份的测试：

　　上传一个文件进行测试：

　　开始时间点是10:37:21
　　root@renhe-16-8-1:~/do# date
　　Fri Nov 20 10:37:21 CST 2015

　　-----------------------------
　　root@renhe-16-8-1:~/do# sftp 123.59.51.65
　　Connecting to 123.59.51.65...
　　The authenticity of host '123.59.51.65 (123.59.51.65)' can't be established.
　　RSA key fingerprint is c1:a1:8b:9f:30:dc:2b:6d:a7:75:e5:67:60:26:ff:d1.
　　Are you sure you want to continue connecting (yes/no)? yes
　　Warning: Permanently added '123.59.51.65' (RSA) to the list of known hosts.
　　root@123.59.51.65's password:
　　sftp> put dell-dset-lx32-3.7.0.219.bin
　　Uploading dell-dset-lx32-3.7.0.219.bin to /root/dell-dset-lx32-3.7.0.219.bin
　　dell-dset-lx32-3.7.0.219.bin                                                                                                                                 100%   

　　31MB   6.2MB/s   00:05   
　　sftp> quit

　　开的虚拟机是10兆的bgp线路，平均传输速度是6.2MB，sftp是数据压缩的，所以这个速度算是不错的了。

　　确认一下最后退出的时间，是10:37:56
　　-----------------------------
　　root@renhe-16-8-1:~/do# date
　　Fri Nov 20 10:37:56 CST 2015
　　-----------------------------

　　在ucloud上查看
　　[root@10-10-177-160 ~]# stat dell-dset-lx32-3.7.0.219.bin
　　  File: `dell-dset-lx32-3.7.0.219.bin'
　　  Size: 32524966          Blocks: 63528      IO Block: 4096   regular file
　　Device: fc01h/64513d        Inode: 786581      Links: 1
　　Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
　　Access: 2015-11-20 10:37:44.999456376 +0800
　　Modify: 2015-11-20 10:37:50.300439322 +0800
　　Change: 2015-11-20 10:37:50.300439322 +0800

　　看起来时间戳在10:37:51


　　删掉它：
　　[root@10-10-177-160 ~]# rm dell-dset-lx32-3.7.0.219.bin
　　rm: remove regular file `dell-dset-lx32-3.7.0.219.bin'? y

　　时间点是10:41:18：
　　[root@10-10-177-160 ~]# date
　　Fri Nov 20 10:41:18 CST 2015

　　按照10:37:51秒来回复，如果是秒级的话，按道理是应该完全恢复的，来试一把吧：

　　单点虚拟主机:

　　

　　右边会弹出主机的信息，下面一排有备份字样，点击之
　　

　　我们是在/root/下传输的文件，所以选择系统盘备份链即可

　　

　　因为这是第一次进入，所以只有一条时间线和最初的一个完全备份

　　

　　点击恢复会弹出一个对话框，必须先停止主机，才能恢复，这个是必须的：

　　

　　关掉主机：

　　

　　然后再进入恢复，就可以了，提示是持续10分钟：

　　

　　状态也变成回复中，指示非常明确：

　　

　　详细记录一下时间点，开始恢复的时间是10：46，把备份恢复到10:37:51

　　等待了大概5分钟......，速度还是蛮快的

　　10：50恢复完毕

　　OK，登录进去查看一下，哈哈
　　[root@10-10-177-160 ~]# ls -lha
　　total 48K
　　dr-xr-x---.  4 root root 4.0K Nov 20 10:37 .
　　dr-xr-xr-x. 24 root root 4.0K Nov 20 10:50 ..
　　-rw-------   1 root root 1005 Nov 20 09:55 .bash_history
　　-rw-r--r--.  1 root root   18 May 20  2009 .bash_logout
　　-rw-r--r--.  1 root root  176 May 20  2009 .bash_profile
　　-rw-r--r--.  1 root root  246 Jan  3  2014 .bashrc
　　-rw-r--r--.  1 root root  100 Sep 23  2004 .cshrc
　　-rwxr-xr-x   1 root root    0 Nov 20 10:37 dell-dset-lx32-3.7.0.219.bin
　　drwxr-----   3 root root 4.0K Nov 20 09:44 .pki
　　drwx------   2 root root 4.0K May 11  2015 .ssh
　　-rw-r--r--.  1 root root  129 Dec  4  2004 .tcshrc
　　-rw-------   1 root root 4.8K Jan 26  2015 .viminfo

　　上帝，字节为0，是空的？！文件名存在，但是内容为空！

　　没办法，按照上传文件的时间点，sftp完毕后的时间点是10:37:56秒，往后错后了6秒，看看。

　　还是空字节。

　　有些不对劲啊，看看log
　　Nov 20 10:37:37 10-10-186-56 sshd[2221]: pam_unix(sshd:session): session opened for user root by (uid=0)
　　Nov 20 10:37:37 10-10-186-56 sshd[2221]: subsystem request for sftp

　　第二次还是不行，看来秒级是夸大了，那么放大到10：38再试。

　　这回就ok了，文件内容无误了。

　　Ucloud的恢复还是非常人性化的，这回我们做了4次测试，所以恢复的时候就产生了4条不同的时间线和4个完整起点的Full Backup：

　　

　　选择恢复的时候也随时可以从4条时间线里选取，非常的方便：

　　

　　备份管理当中可以看到各条时间线，不知道为什么没有提供单独删除时间线的功能，希望以后加上。理由是很明显的，如果恢复的不对，就会产生错误的时间线，少了无所谓。多了就会把人搞糊涂。所以最好有删除错误时间线的功能。

　　Ucloud的备份策略也十分人性化，基本是可以满足大多数的场景的：
　　12小时秒级备份：12小时内最新的数据，可通过数据方舟恢复到任意1秒的数据状态；
　　24小时内每小时整点备份：12小时到24小时之间的数据，可按照整点进行小时级别的数据恢复；
　　3天内每天零点备份：24小时到3天之间的数据，可按照每天零点进行天级的数据恢复。

　　如果购买了服务，不知道每天的备份会保留多久，30天还是60天？

　　最后一个，就是每天的备份可能不是0点，我们可能不能在0点创建备份，也许是在业务空闲期的3点，这样就必须收工创建一个备份了。希望Ucloud能有开放的Api来做这件事情，否则每天晚上3点爬起来搞备份，实在是一件恐怖的事情。或者是Ucloud可以让选择每天full backup的时间点。

　　总体试用结果是满意的，秒级还有距离，至少分钟是可以的了。后续会考虑是否在正式业务上使用。