前两天曾发帖说因为我的一台Amazon EC2底层硬件问题，并且自己没有及时看邮件处理，导致Amazon停掉我的EC2实例，存储在本地存储的一些重要数据通通消失啦。
(图源 ：pixabay)
尽管我觉得Amazon应该为此担负一定的责任（毕竟是他们停掉的实例而不是我主动停掉），但是有理未必说得清，只能打落牙齿吞肚子里，忍着呗。
然后我需要处理的事情就是重建数据，重写脚本啦，但是这之前，我得把这个EC2实例重新启动起来，毕竟除了本地存储，网络存储（根目录对应存储）还有不少更加重要得数据呢。
虽然启动实例之前，我就预料到会不太顺利，但是当真的发现实例启动后自己无法连接，还是有些沮丧的，莫非这个实例根目录下的数据也要丢失啦？
仔细想想应该不至于，毕竟存储卷还在，实在不行，我可以重建一个实例，将这个存储卷挂载上去，然后把数据复制出来。嗯，这大概确实是个可行的方法。
不过这样的话，我又要一步步重新创建实例，又要挂载，又要复制数据——嗯，数据复制到哪里去也是问题！难道说就没有办法可以正确地启动并连接之前的实例嘛？
经过我一番探索，惊奇地发现，Amazon EC2竟然可以通过串口连接，然后通过串行控制台（serial console）来管理。
操作路径如下:
进入AWS控制台，选择对应的区域，选择Instances:
选中对应的实例，在Actions中，选择Connect：
我们有很多方式连接到实例，但是遗憾的是，其它方式都不可用，好在有EC2 serial console
点击这个Connect，我们就会通过EC2 serial console连接到EC2实例啦。开机阶段会自动登录到root用户，这时候我是可以正常以root身份查看根目录下各种信息的。
我发现除了IP变化了，似乎和被停用之前没什么区别，但是通过Putty连接就是被拒绝链接。
于是我通过串行控制台重启sshd服务，发现还是没用。又通过AWS控制台重启了一下EC2实例，发现有了一些变化，这次通过putty连接可以出现登录信息，但是登录后就中断。
从串行控制台观察，每次我一登录自己的用户，实例就被重启，搞不懂是为啥。
明明成功就在眼前，但是putty就是无法登录，你说气人不气人？于是我冥思苦想，到底该差些啥呢？还别说，真让我想起来，问题还是出在本地存储上。
之前实例上为了使用本地存储，我将其分区、格式化后挂载到系统上，也就是在fstab中添加相应分区的对应记录。
莫非是此处的问题？不管怎么说，死马当活马医吧，于是通过串行控制台将fstab中对应的条目删除，然后通过AWS控制台重启实例。
再次通过Putty连接实例，一切正常！（当然，本地存储上的数据是再也找不回啦，容我继续去哭一会吧）
题外话，说到串口连接，以前玩树莓派、香蕉派，又不想接键盘、鼠标、显示器，我经常使用串口线连接这些设备，然后对其进行各种初始设置，设置好了以后就不用管啦。
再后来，树莓派之类的可以实现Headless（无头模式）进行各种初始化设置，终于可以不再使用串口线连接啦。
没想到的是，这次虽然没用自己亲自连接串口线，但是竟然又体验了一把通过串口管理设备，恍然如梦啊。
还有就是，虽然依旧对Amazon弄丢我的数据感到不爽，但是不得不承认，真强大呀！
(图源 ：pixabay)
好了，感慨完毕，我要继续为重建重要数据而奋战了，还是意难平呀，呜呜呜。
