rm -rf误删Oracle数据库恢复---惜分飞

有客户把虚拟化环境中装有oracle数据库的linux操作系统,由于操作失误在/下面执行了rm -rf *,导致所有文件被删除,系统无法启动.客户希望要求恢复出其中的Oracle数据库.由于是虚拟化环境,然后客户直接从虚拟化平台下载下来磁盘文件,通过工具加载和分析确认是一个xfs的文件系统
 

20240516190746


使用工具进一步扫描分析,找到部分数据文件
 

20240516190505


这里可以获取到两个信息:
1. 尝试恢复oracle的control01.ctl文件,然后通过该文件尝试分析其他数据文件位置,运气不错该文件恢复出来是好的,直接加载到新库查询v$datafile,分析出来所有数据文件信息
2. 这里有一个非常不幸的信息,oracle最核心的system01.dbf文件大小明显异常,进一步分析该文件信息,结论是该文件无法通过反删除方式进行恢复
 

20240515223607


先把可以os层面可以恢复的数据恢复出来,并且检查坏块情况
 

20240516191836


对于异常的system文件,有两个处理方法:
1. 通过阅览被删除的文件,发现客户有5月14日1点左右的rman备份,通过恢复软件中完整度提示,大概率应该没有什么问题,但是分析发现部分归档日志损坏无法完整恢复
2. 通过对磁盘做碎片,恢复出来该数据文件,参考以往文章:
dbca删除库和rm删库恢复
Oracle 数据文件大小为0kb或者文件丢失恢复
通过这个方法运气不错,恢复出来该库的system01.dbf文件非常完整0丢失

[oracle@localhost oradata]$ dbv file=system01.dbf

DBVERIFY: Release 19.0.0.0.0 - Production on Thu May 15 23:26:57 2024

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

DBVERIFY - Verification starting : FILE = /u01/oradata/system01.dbf

DBVERIFY - Verification complete

Total Pages Examined 

### 如何恢复Linux中使用 `rm -rf` 误删的文件 在 Linux 中,当文件被 `rm -rf` 命令删除时,实际上只是解除了文件名与其 inode 的链接关系。如果没有任何进程继续访问该文件,则数据可能会逐渐被新写入的数据覆盖而永久丢失。因此,在尝试恢复之前,应立即停止对存储设备的所有写操作以防止数据进一步损失。 #### 使用工具进行恢复 以下是几种常见的恢复方法及其适用场景: 1. **利用 `/proc` 文件系统恢复仍在运行进程中打开的文件** 如果目标文件仍然被某些进程占用(即这些进程仍持有对该文件的有效句柄),则可以通过读取 `/proc/[pid]/fd/` 下对应的文件描述符来获取原始内容[^4]。 2. **采用 extundelete 工具恢复已删除文件** 对于基于 Ext3 或 Ext4 文件系统的磁盘分区来说,可以安装并配置 extundelete 软件来进行更深层次的数据检索工作。此过程通常涉及以下几个步骤: - 安装必要的依赖项以及编译环境; - 解压源码包并通过标准 GNU 构建流程完成程序部署; - 执行具体命令扫描指定目录下的历史记录以便定位所需资源[^3]。 ```bash sudo apt-get update && sudo apt-get install bzip2 e2fslibs-dev e2fsprogs gcc g++ wget http://zy-res.oss-cn-hangzhou.aliyuncs.com/server/extundelete-0.2.4.tar.bz2 tar -xvjf extundelete-0.2.4.tar.bz2 cd extundelete-0.2.4/ ./configure && make && sudo make install sudo umount /dev/sdXN # 替换 sdXN 为目标分区名称 sudo extundelete --restore-directory path/to/deleted/files /dev/sdXN ``` 3. **借助 debugfs 实现基础级别的修复尝试** 当其他高级解决方案不可行时,还可以考虑运用内置实用程序如 debugfs 来手动探索超级块中的未分配空间区域寻找残留痕迹[^2]。不过需要注意的是这种方法成功率较低且风险较大,建议仅作为最后手段试用。 4. **针对特定应用层对象实施定制化策略** 特定类型的数据库实例遭遇此类事故后可能需要专门设计应对措施。例如 Oracle 数据库可通过 RMAN 备份机制结合物理镜像重建技术实现最大程度上的业务连续保障;而对于 MySQL 则可依靠 binlog 日志回滚至事故发生前一刻状态等[^5]。 --- ### 注意事项 无论采取哪种方式都需要提前做好充分准备,并严格遵循以下原则以免造成二次损害: - 将受影响卷迅速卸载隔离保护起来; - 遵循只读模式操作所有相关介质直至确认无误为止; - 根据实际情况灵活调整选用方案组合达到最佳效果。 ```python import os os.system('sudo yum -y install bzip2 e2fsprogs-devel e2fsprogs gcc-c++ make') ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值