恢复误删除的ESXi服务器存储VMFS卷
如果不小心误删除了VMFS卷,使用partedUtil命令恢复即可。partedUtil是VMware ESXi的命令行实用程序,可以在ESXi上直接操作本地和远程 SAN 磁盘的分区表。
【说明】只有 ESXi 5.x 上的磁盘分区才支持使用 partedUtil 命令行。命令行实用程序 fdisk 不能用于采用 VMFS5 格式的 LUN。本文用于VMware ESXi 5.x、VMware ESXi 6.0格式化为VMFS 5的卷。
当前有一台DELLR 730XD的服务器,其中10块硬盘使用RAID-50划分为2个卷,第1个卷30GB,安装ESXi 6.5.0系统,第2个卷使用剩余空间,大小29.08TB,如图1-1所示。
图1-1 VMFS卷
从图1-1中可以看到,这个29.08TB的设备名称为naa.61866da07cda6500209430db1f953ce5;30GB的设备名称是61866da07cda650020942f720a174f8c。
下面我们模拟这个操作(当前是测试机器,请勿在生产机器、有重要数据机器实验,否则由此造成的损失,本文概不负责!)
(1)在“存储设备”中右击29.08TB的存储,右击选择“删除数据存储”,如图1-2所示。
图1-2 删除数据存储
(2)在弹出的“确认删除数据存储”对话框中,单击“是”按钮,如图1-3所示。
图1-3 确认删除数据存储
(3)此时在“数据存储”列表中已经没有该存储,如图1-4所示。
图1-4 无29TB存储
(4)但在“存储设备”列表中仍然可以看到该存储容量及设备名称,如图1-5所示。
图1-5 存储设备查看名称
使用SSH登录到ESXi主机,通过命令查看磁盘列表、查看分区信息然、创建分区表。下面一一介绍。
(1)查看磁盘列表,在命令提示符中执行:
ls /vmfs/devices/disks
命令结果如图1-6所示。
图1-6 查看磁盘列表
此时可以看到设备名为“naa.61866da07cda6500209430db1f953ce5”已经无分区表,如果有分区表,例如设备名“naa.61866da07cda650020942f720a174f8c”(这是ESXi系统卷,该卷有多个分区),后面会有:1的分区数目及vlm的名称。如果我们要恢复分区表,只要为这个29TB创建分区表即可恢复。
【说明】在图1-6中看到的“naa.500080dc004ff330”是图1-1中的大小为447GB的SSD磁盘,而“naa.500080dc004ff330:1”表示这个磁盘的第1个分区,对应图1-4中的data-ssd01卷。图1-6中的磁盘列表、分区列表与图1-1、图1-4的对应关系如表1-1所示。
表1-1 设备标识符、设备名称、数据存储名称说明
ESXi中设备标识符 | 图1-1中的“设备”名称 | 图1-4中的数据存储名称 | 说明 |
naa.500080dc004ff330 | SSD、447GB | 一个500GB的固态硬盘 | |
naa.500080dc004ff330:1 | data-ssd01 | ||
naa.50014ee0042fd6fd | 非SSD、4TB | ||
naa.50014ee0042fd6fd:1 | VMFS-Backup-4TB | 1个4TB的Non-RAID磁盘 | |
naa.61866da07cda650020942f720a174f8c | 非SSD、30GB | RAID卡划分的第1个卷,安装ESXi系统 | |
naa.61866da07cda650020942f720a174f8c:1 | systemPartition,系统分区 | ||
naa.61866da07cda650020942f720a174f8c:2 | 旧版MBR,linuxNative | ||
naa.61866da07cda650020942f720a174f8c:3 | os-esx01 | vmfs | |
naa.61866da07cda650020942f720a174f8c:5 | 旧版MBR,linuxNative | ||
naa.61866da07cda650020942f720a174f8c:6 | 旧版MBR,linuxNative | ||
naa.61866da07cda650020942f720a174f8c:7 | VMware诊断,vmkDiagnostic | ||
naa.61866da07cda650020942f720a174f8c:8 | 旧版MBR,linuxNative | ||
naa.61866da07cda650020942f720a174f8c:9 | VMware诊断,vmkDiagnostic | ||
naa.61866da07cda6500209430db1f953ce5 | 非SSD、29TB | RAID卡划分的第2个卷,用于保存虚拟机 | |
【说明】设备名为naa.61866da07cda650020942f720a174f8c的30GB的卷一共划分了8个分区(没有:4的分区),这是安装ESXi 的过程中创建的多个分区,有Linux引导分区、VMware 诊断分区,这些大约占用7556MB,而剩余的空间则划分为VMFS文件系统卷,剩余的卷在第3个分区,剩余容量大约22.5GB。
(2)使用partedUtil getptbl分别查看447GB、4TB、29TB磁盘的分区信息,对比差别。命令分别如下
partedUtil getptbl /vmfs/devices/disks/naa.500080dc004ff330
partedUtil getptbl /vmfs/devices/disks/naa.50014ee0042fd6fd
partedUtil getptbl /vmfs/devices/disks/naa.61866da07cda6500209430db1f953ce5
查看分区信息,如图1-7、图1-8所示。
图1-7 有分区表的两个卷
图1-8 29TB卷已经无分区表
对比图1-7、图1-8可以看出,“naa.61866da07cda6500209430db1f953ce5”(29TB卷)已无分区表。
(3)为29TB的卷创建分区表,命令及参数如下
partedUtil setptbl "/vmfs/devices/disks/ naa.61866da07cda6500209430db1f953ce5" gpt "1 2048 62440603614 AA31E02A400F11DB9590000C2911D1B8 0"
上述命令中的1 表示第一个分区,是主分区。2048表示vmfs-5分区开始扇区 。AA31E02A400F11DB9590000C2911D1B8 是VMFS GUID ,而62440603648是29.08TB卷的扇区数即图1-8中的62440603648再减去34得到。
命令及命令执行结果如图1-9所示。
图1-9 创建分区
【说明】在本示例中,VMware ESXi卷被格式化为VMFS-5。对于VMFS6的卷,其扇区差异可能不全是34,也可能是1713,这些需要进一步查参数。
(4)然后在vSphere Client中重新扫描存储,可以看到原来被删除的存储已经出现,只是显示为“灰色”,右击该存储选择“挂载”,如图1-10所示。
图1-10 挂载非活动存储
(5)之后存储挂载完成,并且可以看到存储的信息,如图1-11所示。
图1-11 被删除的VMFS卷恢复
(6)浏览存储,可以看到数据仍然存在,如图1-12所示。至此存储恢复完成。
图1-12 存储恢复成功
总结:vSphere的用户,在管理ESXi与vCenter Server服务器的时候,在对虚拟机、存储进行操作,例如扩容、删除这些有一定“危险性”的操作时,一定要多次确认,只有确认虚拟机不再使用时,才可以删除。只有确认存储上的数据已经迁移完成并且没有有用数据时,才能删除。但如果误操作删除了存储或虚拟机,第一时间用正确的方法恢复,数据一般不会丢失。
更多虚拟化课程及视频,请单击“VMware系统集成工程师”专题,2017年12月31日前8折,仅1600元。
http://edu.51cto.com/topic/1308.html

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
在编程中为所欲为[圣诞版]
众所周知,在Java中final String中的值是一成不变的。大家都知道String的+(拼接)运算会丢弃内存引用并在内存中重新开拓地址,事实上也确实如此。但final的变量真的是一成不变的吗?谨以此文打开程序员思路,跳出定式思维,希望本文会给你的程序员生涯带来新的思考。 一个简单的例子 这个例子很久远,早有前辈做过,但并不是所有的程序员都接触过。通常喜欢“猎奇”的程序员对此不会陌生。 import java.lang.reflect.Field; public class ChangeFinalString { public static void main(String[] args) throws Exception { final String s = "12345: caiyongji"; System.out.println(s); System.out.println("hashcode: " + s.hashCode()); Field f = String.class.getDeclaredField("value"); f.setAccessible(true)...
- 下一篇
如何确定线程池大小
背景 在我们日常业务开发过程中,或多或少都会用到并发的功能。那么在用到并发功能的过程中,就肯定会碰到下面这个问题 并发线程池到底设置多大呢? 通常有点年纪的程序员或许都听说这样一个说法 (其中 N 代表 CPU 的个数) CPU 密集型应用,线程池大小设置为 N + 1 IO 密集型应用,线程池大小设置为 2N 这个说法到底是不是正确的呢? 其实这是极不正确的。那为什么呢? 首先我们从反面来看,假设这个说法是成立的,那我们在一台服务器上部署多少个服务都无所谓了。因为线程池的大小只能服务器的核数有关,所以这个说法是不正确的。那具体应该怎么设置大小呢? 假设这个应用是两者混合型的,其中任务即有 CPU 密集,也有 IO 密集型的,那么我们改怎么设置呢?是不是只能抛硬盘来决定呢? 那么我们到底该怎么设置线程池大小呢?有没有一些具体实践方法来指导大家落地呢?让我们来深入地了解一下。 Little's Law(利特尔法则) 一个系统请求数等于请求的到达率与平均每个单独请求花费的时间之乘积 假设服务器单核的,对应业务需要保证请求量(QPS):10 ,真正处理一个请求需要 1 秒,那么服务器每个时刻...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Linux系统CentOS6、CentOS7手动修改IP地址
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- CentOS8编译安装MySQL8.0.19
- CentOS关闭SELinux安全模块
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8