服务器磁盘只读修复过程

简介:

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

一、处理过程

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,如需转载请自行联系原作者


相关文章
|
1月前
|
Oracle 关系型数据库 数据挖掘
服务器数据恢复—服务器RAID5磁盘阵列数据恢复案例
服务器数据恢复环境: 一台服务器上有一组由5块硬盘(4块数据盘+1块热备盘)组建的raid5阵列。服务器安装Linux Redhat操作系统,运行一套基于oracle数据库的OA系统。 服务器故障: 这组raid5阵列中一块磁盘离线,但是热备盘并没有自动激活rebuild,当另外一块数据盘发生故障离线后,raid崩溃。 用户方要求恢复raid数据,同时要求还原操作系统。经过初步观察,raid中的这些硬盘没有表现出存在明显的物理故障的特征,也没有明显的同步表现,数据恢复的可能性很大。
|
3月前
|
存储 Linux
服务器数据恢复—服务器raid5磁盘阵列数据恢复案例
服务器数据恢复环境: 某品牌2850服务器上有一组由6块SCSI硬盘组建的raid5磁盘阵列,上层操作系统为Redhat linux+ext3文件系统。 服务器故障&初检: 服务器在运行过程中突然瘫痪,管理员对服务器中的raid进行检查后发现有两块硬盘离线。管理员对其中一块离线硬盘进行强制上线操作,但是强制上线操作完成后操作系统启动异常。管理员马上将服务器关机,联系我们数据恢复中心寻求帮助。
|
22天前
|
存储 关系型数据库 MySQL
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
195 2
|
2月前
|
存储 数据挖掘 数据库
服务器数据恢复—raid磁盘故障导致数据库数据损坏的数据恢复案例
存储中有一组由3块SAS硬盘组建的raid。上层win server操作系统层面划分了3个分区,数据库存放在D分区,备份存放在E分区。 RAID中一块硬盘的指示灯亮红色,D分区无法识别;E分区可识别,但是拷贝文件报错。管理员重启服务器,导致离线的硬盘上线开始同步数据,同步还没有完成就直接强制关机了,之后就没有动过服务器。
|
2月前
|
存储 关系型数据库 MySQL
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
131 5
|
1月前
|
存储 监控 Linux
充分利用服务器的磁盘资源,提高系统的稳定性和可维护性
充分利用服务器的磁盘资源,提高系统的稳定性和可维护性
36 0
|
2月前
|
存储 安全 算法
服务器数据恢复—Raid磁盘阵列的安全性分析及常见故障
出于尽可能避免数据灾难的设计初衷,RAID解决了3个问题:容量问题、IO性能问题、存储安全(冗余)问题。从数据恢复的角度讨论RAID的存储安全问题。 常见的起到存储安全作用的RAID方案有RAID1、RAID5及其变形。基本设计思路是相似的:当部分数据异常时,可通过特定算法将数据还原出来。以RAID5为例:如果要记录两个数字,可以通过再多记录这两个数字的和来达到记录冗余性的目的。例如记录3和5,同时再记录这2个数字的和8。在不记得到底是几和5的情况下,只需要用8-5就可以算出这个丢失的数字了,其余情况依此类推。
|
3月前
|
存储 内存技术
【RAID磁盘阵列服务器数据恢复】华为OceanStor Dorado存储系统RAID-TP数据丢失数据恢复案例
客户报告其华为OceanStor Dorado存储系统的RAID-TP出现故障,导致数据丢失。RAID-TP是一种增强型RAID级别,包含数据磁盘、校验磁盘和转换磁盘,可在两个磁盘故障时仍保护数据。通过分析RAID结构与工作原理,我们制定了恢复方案:首先从校验磁盘读取信息并计算出丢失的数据块,接着将恢复的数据写入新磁盘。由于缺乏现成工具,需定制RAID重组程序以恢复数据。华为的动态RAID重构技术保证了重构过程中冗余级别的稳定。
55 1
|
3月前
|
弹性计算 Windows
震惊!ECS Windows 系统磁盘竟“撒谎”,空间去哪儿了?别急,这里有终极破解法!
【8月更文挑战第15天】在使用ECS Windows系统时,可能会遇到磁盘显示占用的空间远超实际文件大小的情况,导致空间不足。原因包括系统还原点、卷影副本累积及回收站文件未彻底删除等。解决方法有:清除系统还原点(`vssadmin delete shadows /all`),清空回收站,删除临时文件夹中的文件,以及检查并修复磁盘错误。这些步骤能有效释放空间,保证系统稳定运行。
76 4
|
3月前
|
存储 运维 数据挖掘
服务器数据恢复—修复xfs文件系统导致数据丢失的数据恢复案例
某公司一台服务器,连接了一台存储。该服务器安装linux操作系统,文件系统为xfs。 在运行过程中该服务器出现故障,管理员使用xfs_repair工具试图对xfs文件系统进行修复但失败,服务器中所有数据丢失。
下一篇
无影云桌面