随着业务的增长，需要存储的业务数据会越来越多，这时候就需要为 EC2 调整存储大小或者挂载额外的存储。对于挂载额外的存储来说，我们希望其可以在开机的时候自动被挂载上。当然这也不是什么难事儿，简单修改下 /etc/fstab 文件就能搞定。但是，经常会有用户由于疏忽或修改不当，导致机器在关机或重启后无法成功启动。
那么，如何才能做到安全挂载磁盘？本文给出了几种常见的操作系统的操作方法，以及如何解决误操作导致的无法开机。
00
Fstab是什么
Fstab(file systems table) 文件是 Unix 及类 Unix 的系统配置文件，通常位于 /etc/fstab 。在开机的时候 mount 命令会自动从中读取配置来查看需要挂载的文件系统。
以下是只有一个根卷的 Amazon Linux 2 系统下的 fstab 文件内容示例：
表示会在开机的时候，自动挂载 UUID 为 55da5202-8008-43e8-8ade-2572319d9185 的设备到挂载点/，文件系统类型为 xfs ，采用默认挂载选项 (defaults) 但不记录文件的访问时间 (noatime) ，开启 dump 选项，文件系统的检查顺序为 1 。
01
实现安全的自动挂载
1.1 使用UUID
Device spec 支持设备名称(如 /dev/xvdf )、UUID 等多种形式，我们建议您使用设备的 128 位通用唯一标识符 (UUID)。因为设备名称可能会发生更改，但 UUID 会在整个分区的使用期间保持不变，因此，可以降低系统在硬件重新配置后无法启动的可能。
那我们应该如何查看设备的 UUID 呢？
1) 使用 blkid 命令查找设备的 UUID
2) 若 1 行不通，请尝试使用 lsblk 命令
1.2 跳过挂载失败的设备
接下来，我们列出针对不同的操作系统，实现自动跳过挂载失败的项目，而不是阻止系统的启动。
1) 在 Debian 衍生版及早于 Ubuntu 16.04 的系统中，需要指定 nobootwait 选项以跳过失败的挂载项。
2) 在 Ubuntu 16.04 及之后的版本，及 RHEL/CentOS 7 系统中，需要指定 nofail 选项以跳过失败的挂载项。
配置参数 nobootwait 或 nofail，同样适用于 NFS 文件系统的挂载，NFS 文件系统的自动挂载配置方式请参考[2]。
02
EC2无法启动是因为设备挂载失败吗？
以 Amazon Linux 2 为例，如果配置了错误的 fstab 导致机器无法启动的时候，可以在 EC2 的控制台，查看机器的系统启动日志。日志查看路径: Instance Settings / Get System Log，如下图所示：
在日志查看页面，可以看到最底部的日志状态为 Press Enter to continue.，进一步搜索挂载点(如/mnt)，则可以发现更详细的日志信息：
则表示，系统挂载设备失败，导致系统无法正常启动，此时，只能采取拯救 EC2 行动。
03
如何拯救EC2
3.1 恢复受损的fstab文件
由于当前 EC2 已经无法用常规的方案进行控制，我们可以考虑将根卷卸载下来，然后挂载到别的 EC2 主机上，并修改 fstab 文件，之后，再挂载回原主机。
⚠️ 需要注意的是，因为卸载磁盘的时候需要停止(Stop)实例，若实例包含实例存储，会导致实例存储的数据丢失，若需要保留实例存储数据，请尝试寻求 Support 的帮助。
具体步骤如下：
1) 停止该无法启动的实例。在 EC2 控制台查询并记录下当前根卷的挂载位置(如 /dev/xvda )，查看方式如下图：
2) 卸载根卷。在 EC2 控制台的磁盘列表中找到实例的根卷，并执行卸载操作。
3) 挂载根卷到一个正常实例。这里要求实例与根卷同处一个可用区。
4) 在正常实例中挂载根卷。
a) 查看当前系统中磁盘列表
这里我们可以看到这个 8G 大小的分区就是故障实例的根卷，记录其分区名称 nvme1n1p1。
b) 挂载磁盘
将分区 nvme1n1p1 挂载到 /mount_dir 路径下，命令如下：
若您执行上述命令时遇到错误(如bad option, bad superblock)，可以尝试如下挂载命令：
c) 修正 fstab 配置文件
使用文本编辑工具，注释掉有问题的挂载项，或者根据 1.2 章节来调整挂载选项。
3.2 恢复磁盘挂载
在之前的步骤中，我们完成了对 fstab 文件的修正，此时，我们需要将旧实例的根卷重新挂载回去。
具体操作步骤可以参考 3.1 章节中的步骤 2 和步骤 3 ，将磁盘从当前实例卸载下来，然后挂载回旧实例，挂载路径同步骤 1 所示。
3.3 启动旧实例
至此，我们已经完成所有修复工作，接下来可以正常启动旧实例了。
