之所以写这篇文章是因为最近遇到了几个因为误操作导致虚拟机丢失的案例，虽然最后分析结果都和VMware的产品本身无关，但是作为一个IT从业者，只要听到“数据丢失”这几个字心里就会一紧。所以我决定整理下常见的由于“误操作”导致数据丢失的案例，希望能对各位有所帮助。
存储变更导致出现“快照卷”
危害指数：🌟
=====================
这里的快照卷（Snapshot Lun）与虚拟机的快照没有任何关系。是指ESXi主机在重新挂载或者扫描存储的时候，发现获取到的LUN的信息与之前获取到的不同。
The snapshot LUNs issue occurs when the ESXi/ESX host does not confirm the identity of the LUN with what it expects to see in the VMFS metadata. This issue occurs after replacing SAN hardware, firmware upgrades, SAN replication, DR tests, and some HBA firmware upgrades.
为了保证数据安全，ESXi会把这个LUN标记为“快照卷”，在得到进一步确认之前，ESXi不会对这个LUN的进行任何操作。如果用户遇到这个场景建议第一时间联系VMware的售后部门进行处理。
注意：“快照卷”不会导致数据丢失，“快照卷”是一种保护机制。
KB：vSphere handling of LUNs detected as snapshot LUNs (1011387)
粗心大意的存储策略
危害指数：🌟🌟
=====================
曾经处理过一个vSAN案例，用户手工创建的存储策略名称为：“双副本（FTT=1）”，但是实际上客户选择的是FTT=0（单副本）。因此所有使用这个存储策略的虚拟机实际上都只有单副本数据。这种场景下如果vSAN集群中一台主机故障则有可能导致虚拟机变成不可访问。幸好发现的及时，客户在第一时间修改存储策略，所有的虚拟机也变成了双副本。
不正确的维护操作
危害指数：🌟🌟🌟
=====================
之前的文章写过，vSAN环境下根据存储策略的设置可以保证数据有多个副本，最常见包括FTT=0 表示数据有一个副本，FTT=1表示数据有两个副本。遇到过一些客户在使用了FTT=0的存储策略前提下，删除磁盘/磁盘组时候仍没有按照vSAN要求的步骤进行数据迁移（为了节省时间，选择“不迁移数据”），导致只有单副本的数据没有迁移到其他节点/磁盘上，最终结果就是有些单副本的数据会变成不可访问。
ESXi主机和其他操作系统主机访问同一个LUN
危害指数：🌟🌟🌟🌟
=====================
这个问题发生在使用传统存储的场景下，ESXi在创建的Datastore后会创建VMFS分区表。如果这个时候把这个LUN映射给Windows服务器，则会导致LUN上的分区信息被Windows文件系统覆盖。更有严重情况，用户在不知情的情况下把这个LUN在Windows下继续使用，导致原来的数据被覆盖！
（LUN上已经被Windows信息覆盖）
mv命令与误操作
危害指数：🌟🌟🌟🌟
=====================
我对mv命令的态度一直是又爱又恨。爱的是确实方便快捷功能强大，恨的是我遇到过许多案例都是客户错误的使用mv命令导致数据丢失。下面是一个真实案例：
在非vSAN的环境下，一个虚拟机A的vmdk包含的两个文件：
描述文件：A.vmdk
数据文件：A-flat.vmdk
用户创建了一个临时的描述文件B.vmdk，并且想重命名为A.vmdk
但是不小心敲错了命令：
mv B.vmdk A-flat.vmdk
然后真实的数据文件A-flat.vmdk就没有了...
“艺高人胆大”的命令
危害指数：🌟🌟🌟🌟🌟
=====================
最近处理几个数据丢失案例都有一些共性：客户反馈虚拟磁盘莫名其妙就丢失，文件夹里也找不到对应的VMDK。我们的工程师检查了所有的日志发现虚拟机磁盘在某个时间点就莫名其妙的没有了，发生问题前没有任何异常，既不符合常理也不符合产品设计。
直到我们发现某台主机上的操作记录才真相大白：虚拟磁盘对应的对象被人工的删除掉了。通过记录我们可以看到操作者从登陆主机到尝试相关命令（尝试了这个命令所有参数，包括删除）到退出登录的全部过程，甚至可以感觉到操作者尝试命令时的“满满求知欲”和发现误删后的恐慌。针对这几个案例后续只能用户内部继续调查和追责了。
那么为了保证环境下的数据安全，我们应该做什么呢？
备份！备份！备份！
=====================
备份的重要性我这里就不说了。但是有几个细节需要再强调下：
需要定期做备份恢复检查，确保备份是可用的。
vSAN即使有数据副本也需要备份。因为数据副本只能保证物理设备损坏时有可用的数据文件，但是无法覆盖类似下面的场景：不小心从虚拟机里删除一个文件，通过数据副本是无法找回来的，只能通过之前的备份进行恢复。
快照不是备份！快照不是备份！快照只用于做变更后的回滚，但是快照并不是备份！
养好正确的操作习惯
=====================
在修改一个文件前对这个文件进行备份。例如对vmx文件操作前，先备份一个vmx.bak文件
使用恰当的命令进行操作。例如对虚拟机磁盘进行操作时我们推荐使用vmkfstools命令，而不是传统的mv，cp命令。
KB#Cloning and converting virtual machine disks with vmkfstools (1028042)
执行命令前确保知道你在做什么
=====================
涉及数据的命令没有“Re-try”一说，所以在执行一个命令前一定要自己问自己这些问题：
操作的目的是什么？
命令执行后预期的结果是什么？
命令的参数是否正确？
命令的对象是否写正确？
命令执行后是否可以回滚？
个人建议如果上述任何一条不清楚的话，那么最好暂时放弃这个操作。
专业的事情交给专业的人
=====================
ESXi有些命令/脚本是只针对经过培训的GSS工程师的。一些场景下用户学到了这些命令/脚本后就想在今后遇到类似的故障时照猫画虎的使用这些命令。实际上这样的操作非常有风险，因为用户不了解这些命令的背景和正确的使用场景和方法，更不了解回退的方法或是如何找到正确的资源来协助自己。所以这些专业的事情请交给专业的工程师来做吧。
最后再强调一下关于数据恢复的事情：
=====================
VMware不提供数据恢复的服务，但是VMware有官方认证的数据恢复公司可以提供给用户选择，具体请参考下面的KB：
Data recovery services for data not recoverable by VMware Technical Support (1015413)
据说这些公司的收费都不便宜，与其花一大笔钱恢复数据，不如从平时的一点一滴做起来保证数据安全吧。
联系客服
