服务器磁盘只读修复过程

简介:

  服务器的磁盘也没有做监控,其实我也不知道如何对磁盘的状态做监控,突然查看不到新数据,上去看了一下磁盘的情况,发现磁盘出现只读的情况,无法写入数据,要是大家谁知道怎么可以监控磁盘只读的方法,可以告诉我下,来个高达上一些的。

一、处理过程

1、磁盘坏道检查

    出现问题之后,首先把业务停掉了,然后把磁盘卸载掉来进行修复,出现这种问题有可能是磁盘的磁道有坏区,我首先检查了一下磁盘坏道的情况。

1
badblocks -sv  /dev/sdb

    差不多检查了一些时间,发现并没有坏道。

2、修复磁盘文件系统

    在修复文件系统的时候发现无法修复,提示Superblock invalid。

1
2
3
4
5
6
7
8
9
10
[root@ad4 ~] # fsck -t ext4 /dev/sdb
fsck  from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
fsck .ext4: Superblock invalid, trying backup blocks...
fsck .ext4: Bad magic number  in  super-block  while  trying to  open  /dev/sdb
The superblock could not be  read  or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something  else ),  then  the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
     e2fsck -b 8193 <device>

3、查看文件系统备份Superblock

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
[root@ad4 ~] # mke2fs -n /dev/sdb         
mke2fs 1.41.12 (17-May-2010)
/dev/sdb  is entire device, not just one partition!
Proceed anyway? (y,n) y
Filesystem label=
OS  type : Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=1 blocks, Stripe width=0 blocks
122093568 inodes, 488364854 blocks
24418242 blocks (5.00%) reserved  for  the super user
First data block=0
Maximum filesystem blocks=4294967296
14904 block  groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
         32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
         4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
         102400000, 214990848

4、修复文件系统

1
e2fsck -b 214990848 -y  /dev/sdb

     出现了很多修复的东西,修复了一会

wKiom1apjujAPrm0AAFZSUwUmjk850.png 

    修复好之后,挂载进去目录查看如下

wKioL1apj3SS_9GTAAFsBQmz7nU638.png

    好歹只是丢失了文件夹的名称,剩下的回复交由DBA来进行操作。







     本文转自 wzlinux 51CTO博客,原文链接:http://blog.51cto.com/wzlinux/1739473,如需转载请自行联系原作者


目录
打赏
0
0
0
0
348
分享
相关文章
服务器数据恢复—服务器raid磁盘出现故障的数据恢复案例
一台服务器中有一组由三块SAS硬盘组建的raid阵列。服务器上部署的数据库存储在D分区,数据库备份存储在E分区。 服务器上一块硬盘指示灯显示红色。D分区不可识别。E分区虽然可以识别,但是E分区拷贝文件报错。 管理员重启服务器,先离线的硬盘上线开始同步数据,同步没有完成的情况下管理员将服务器强制关机,之后没有动过服务器。
ECS磁盘使用率异常升高,BPS,IOPS飙升
我刚开了一个2C4G的ECS,运行Ubuntu 20.04,常出现无响应、SSH断开等问题。原因是未配置swap,导致内存过高时磁盘写入频繁。解决办法在文章里。
188 72
阿里云操作系统控制台——解决服务器磁盘I/O故障
阿里云操作系统控制台——解决服务器磁盘I/O故障
74 12
服务器数据恢复—服务器RAID5磁盘阵列数据恢复案例
服务器数据恢复环境: 一台服务器上有一组由5块硬盘(4块数据盘+1块热备盘)组建的raid5阵列。服务器安装Linux Redhat操作系统,运行一套基于oracle数据库的OA系统。 服务器故障: 这组raid5阵列中一块磁盘离线,但是热备盘并没有自动激活rebuild,当另外一块数据盘发生故障离线后,raid崩溃。 用户方要求恢复raid数据,同时要求还原操作系统。经过初步观察,raid中的这些硬盘没有表现出存在明显的物理故障的特征,也没有明显的同步表现,数据恢复的可能性很大。
服务器数据恢复—Raid5磁盘阵列数据恢复案例
服务器数据恢复环境: 某公司一台存储上有一组由15块硬盘组建的raid5阵列。raid5阵列上层是一个xfs裸分区,起始位置是0扇区。 服务器故障: raid5阵列中有一块硬盘出现故障掉线,热备盘自动上线同步数据,数据同步还没有完成的情况下磁盘阵列中又有一块硬盘掉线,数据同步过程中断,阵列崩溃。
课时4:第4天:云服务器磁盘管理
欢迎收看玩转云服务器ECS系列课程,今天我们来学习第四课:云服务器磁盘的管理。这课有三个小节。 1. 磁盘有什么用 2. 磁盘分区与挂载 3. 扩容磁盘
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
2085 2
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
430 5
服务器数据恢复—raid磁盘故障导致数据库数据损坏的数据恢复案例
存储中有一组由3块SAS硬盘组建的raid。上层win server操作系统层面划分了3个分区,数据库存放在D分区,备份存放在E分区。 RAID中一块硬盘的指示灯亮红色,D分区无法识别;E分区可识别,但是拷贝文件报错。管理员重启服务器,导致离线的硬盘上线开始同步数据,同步还没有完成就直接强制关机了,之后就没有动过服务器。
充分利用服务器的磁盘资源,提高系统的稳定性和可维护性
充分利用服务器的磁盘资源,提高系统的稳定性和可维护性
78 0

热门文章

最新文章

下一篇
oss创建bucket