有句俗语叫：If it ain't broke, don't fix it. 今天真是见识到了。
0x0000 起因
在昨天(2月8日) 17时，本人收到了Cloudcone发来的春节优惠邮件。
在一番激烈的思想斗争下，下单了一个看上去更便宜的套餐。打算把服务器迁移过去。
0x0001 噩梦
几分钟后，服务器创建完毕。
发现控制面板居然没有像搬瓦工那样方便的服务器迁移菜单，自己又懒得手动迁移，于是就发了份工单给客服询问有没有什么办法。
17:30
技术人员小哥开始帮我迁移数据。
他的操作非常简单粗暴，直接把旧服务器的硬盘挂载到新服务器上，再把新服务器的硬盘挂载到旧服务器上。
听起来是没什么问题，那位小哥也没继续回复我。
然而他没有料到，两台服务器的IP地址是静态设置的，写死在`/etc/networks/interfaces`里，这位小哥没有给我改过来，这导致两台服务器都不能访问网络。
无奈之下，我只好回复他，请他帮忙修改地址，顺便帮我调整好硬盘大小。
次日0:00
距离我的回复已经过去3个小时，
那位技术人员小哥没有回复。
见鬼了，怎么办？！
我打开面板，看见有一个开启IPv6的选项。 开启IPv6应该会重新配置网络，说不定能把IP问题修好呢？
抱着侥幸的心理，我点了。服务器重新启动。
几分钟后，成功了。服务器可以上网了！
然而，咱又遇到了新的问题。这个服务器的IP地址比较特殊，它在国内访问会显示连接超时，而在其他地方却没有问题。很明显，这个服务器的IP被[数据删除]了。
0:30
我还没有睡。在百度上稍微搜索了一下，得到两种解决方法：
- 删除服务器，重新购买。
- 发工单申请更换IP,但需要$2。
由于之前的技术小哥帮我把硬盘挂载在了新服务器上，如果直接删除，那么数据也肯定跟着一起没掉了，所以排除方法1。
我创建了一个Urgent工单，申请更换IP，。
几分钟后
很快，就有一个工程师回复我了。他是这样说的：Your request is sent to our network team, please allow some time while they get it processed for you.
我的内心：诶，不错啊这服务态度。
抱着侥幸的心理，我在这个工单里问能不能帮我把硬盘大小的问题也给处理了。
我刚刚回复完。刷新了一下浏览器，就看见另外一个工程师回复我：Your request is sent to our dev-ops team, please allow some time while they get it processed for you.
我：？？？
完了。这俩人是机器人没跑了。
看自己的账户，$2也没有扣掉。先睡觉吧，说不定明天早上就好了呢。
睡之前回复了一句：Thank you, please be quick. My service have been shutdown for over 8 hours, my users are complaining, please understand.
10:00
我大概是这个时候醒的。登录网站看看情况解决了没有。
最早帮我迁移的小哥还是没有回复我。第二个工单在我回复没多久之后就回复了一句：你可以在我们dev-ops回复之前照常使用你的服务器。
照常个鬼啊，根本用不了啊。这都什么鬼回复模板。
11:00
不等了，估计他们是打算直接把我凉着了。
现在我有两台服务器：
- 本来就有的一台 chocolate，挂载硬盘30GB，无法访问网络。
- 前面下单的一台 darksky，挂载硬盘25GB，可以访问网络。
想了一个简单的思路:
- 重新安装chocolate上的系统，腾出空间。
- 使用 ssh 和 dd 把 darksky上的硬盘复制到 chocolate 上。
- 删除 darksky。
- 重新下单一台服务器。
- 把在chocolate上的数据迁移到新下单的服务器上。
看上去挺简单的，就像写程序的时候交换两个变量一样。
11:18
下单了新的服务器，系统安装好之后惊呆了，IP地址和之前的居然是一样的。
删除，重新下单。
又是一样的。
看来他们还是按顺序提供分配IP的，也就是说，必须要有一个倒霉鬼下单得到那个IP之后，我下单才会得到新的IP。
这大中午的，谁会买啊。
11:22
我想到了一个绝妙的好主意。
先下单一个价格最低的服务器，它会分配到那个不能用的IP。再下单我想要的服务器，这样就可以啦！
0x0002 第二个噩梦
复制数据很简单是吧？我一开始也是这样想的。
在百度上搜索了一下，原来有种东西叫 SSHFS。 它可以通过SSH协议把远程的服务器挂载到本地上。
于是我的做法是：把硬盘镜像mount到chocolate的 /mnt上，再通过SSHFS把chocolate的 /mnt 挂载到新服务器的 /mnt上。
11:52
重启新服务器，发现使用旧的用户名和密码可以登陆。
太棒了！
诡异的事情来了，登陆成功之后，还没有看见bash，就重新退回到登陆界面了。现在想想，应该是某个支持库没有复制过来，导致bash无法启动。
看来SSHFS这条道不行，重新安装。 对了，新的服务器叫vanilla。
很久以前曾经用tar配合netcat迁移过数据。通过管道，分别在发送端和接收端执行：
# 接收端
netcat -l -p 7000 | tar x
# 发送端
tar cf - * | netcat 接收服务器 7000
试试吧。
14:46
我把MobaXterm自带的小游戏玩了个遍。终于知道为什么一个好好的终端软件带这么多游戏干什么了。
我重试了好几次，每次都是执行到一半，ssh断开连接，Vanilla整个系统无法响应。
看来这个方法也是不行了。应该是因为在覆盖的某个重要lib文件的时候整个系统崩溃。
这个服务商提供的服务器都是KVM，可以访问Recovery模式，看来只能用这种方法了。
Recovery模式和Windows的PE系统差不多，是挂载到内存上的系统。因此我们怎么修改硬盘都和它没有关系。
16:00
Recovery的系统可真是简洁。没有apt，也没有gcc。这意味着我用不了SSHFS这种方法了。
不过ssh和scp倒是能用。我挂载了本地硬盘，使用scp把远程上的服务器复制到本地。
问题#1
SCP复制的时候进度一直是0%,而且最后的文件大小居然超过了25GB!
一看才发现，整个程序卡在复制虚拟设备 /dev/core 上。
问题#2
历尽千辛万苦终于复制完数据，回到面板把Recovery模式关闭。这个按钮点了半天没有反应。他们面板的开发人员怕不是写了个假的按钮吧。
好在本人对Html和JavaScript也略知一二，打开F12看了一下，是一个表单。手动执行一下submit();完事。
16:15
成功进入系统了，但是发现好像少了很多东西，和没有复制几乎没区别。
什么玩意啊。
无奈，还是只能走SSHFS的方法。
0x0003 重新上线
功夫不负有心人，在走了N次弯路之后，服务器终于恢复正常了。
16:25
在复制lib文件夹的时候。第一次把文件复制错了位置。从 /mnt/usr/lib 复制到了 /usr/lib/里。第二次执行到一半，发现在覆盖 libglib的时候，SSHFS废了。
庆幸自己第一次复制错了没有删除，为了安全起见我在VNC下完成了覆盖。
18:09
MySQL不知道因为什么原因无法启动，日志报错Could notcreate unix socket lock file /var/run/mysqld/mysql.sock.lock。
在尝试了各种方法之后，发现把socket的路径指向 /tmp 里面就可以了。
/tmp 和 /var/run 都挂载在tmpfs下。我在复制的时候没有注意，覆盖了 /var/run。
也就是说，重启可以解决问题。
18:11
网站成功上线！
截止至网站上线，两个工单还是没有人回复，之前换IP的申请也没有扣款。
虽然网上很多人表示Cloudcone的工单都是秒回，但这次的事件真的让我担心日后的使用。
就这样吧。
2019-2-9 20:34:19
