有关extdelete恢复测试

客户意外rm掉了数据文件,导致数据库无法打开,由于没有完整的备份和归档,需要使用别的方法,而客户又关闭了数据库,导致无法使用文件描述符恢复,就要使用linux上别的方法了,现记录使用extundelete来恢复丢失的文件

[[email protected] ~]# cd
/db

[[email protected] db]# ll

总计 32

drwxrwxr-x 2 oracle
oinstall 16384 2011-05-06 lost+found

-rwxr-xr-x 3 oracle
oinstall  21096 08-02 18:05 odu

drwxrwxr-x 7 oracle
oinstall  4096 2011-05-06 oracle10g

[[email protected] db]# rm
-rf odu

[[email protected] db]# df
-h

文件系统             
容量  已用 可用 已用% 挂载点

/dev/sda3             
39G   26G   12G  70% /

/dev/sda10           
331G  312G  2.3G 100% /opt

/dev/sda9             
20G  175M   19G   1% /tmp

/dev/sda8             
20G  439M   18G   3% /var

/dev/sda7             
20G   11G  8.3G  56% /home

/dev/sda6             
20G  1.7G   17G   9% /vol

/dev/sda2            
331G  310G  4.1G  99% /db

/dev/sda1            
2.0G   42M  1.8G   3% /boot

tmpfs                 
16G     0   16G   0% /dev/shm

/dev/sdb1            
929G  709G  173G  81% /db2

/dev/sdb2            
905G  622G  238G  73% /opt2

192.168.0.121:/nfs7  
1.1T  621G  391G  62% /dbbak2

[[email protected]
extundelete-0.2.0]# mount -n -r -o remount /db

最好尽快将所在分区修改为只读方式,防止数据被覆盖使用。

[[email protected] /]# cd
root

[[email protected] ~]# ll

-rw-r–r– 1
root   root   97851 08-31 12:10 extundelete-0.2.0.tar.bz2

这里上传一个工具主要用于ext3文件系统,ext4没有测试过。

[[email protected] ~]# tar
xjvf extundelete-0.2.0.tar.bz2

extundelete-0.2.0/

extundelete-0.2.0/README

extundelete-0.2.0/acinclude.m4

extundelete-0.2.0/configure.ac

extundelete-0.2.0/aclocal.m4

……

安装extundelete工具

[email protected] ~]# cd
extundelete-0.2.0

[[email protected]
extundelete-0.2.0]# ls

acinclude.m4 
autogen.sh  config.h.in  configure.ac  install-sh 
Makefile.am  missing  src

aclocal.m4   
compile     configure   
depcomp       LICENSE    
Makefile.in  README

[[email protected]
extundelete-0.2.0]# ./configure

Configuring extundelete
0.2.0

Writing generated files
to disk

[[email protected]
extundelete-0.2.0]# make

make -s all-recursive

Making all in src

[[email protected]
extundelete-0.2.0]# make install

Making install in src

/usr/bin/install
-c ‘extundelete’ ‘/usr/local/bin/extundelete’

使用extundelete进行rm文件或者文件夹的恢复

[[email protected]
extundelete-0.2.0]# extundelete /dev/sda2 –restore-all

Loading filesystem
metadata … 2236 groups loaded.

Loading journal
descriptors … 30441 descriptors loaded.

Writing output to
directory RECOVERED_FILES/

此时可以将、dev/sda2分区的被删除但是还没有被重用的block恢复,而如果block已经被重用了,此种方法不行了,而后会在当前目录下创建一个RECOVERD_FILES的目录,目录下就是extundelete恢复的文件或者文件夹(个人尝试恢复文件夹,发现恢复的文件夹存在部分文件丢失,无法恢复,可能是block被重用导致)。

[[email protected]
extundelete-0.2.0]# ll RECOVERED_FILES/

总计 16

-rwxr-xr-x 2 root root
21096 08-31 14:53 odu

已经成功恢复

来自 <http://blog.163.com/scott_guo/blog/static/1810260832012913113728302/>

以上方式,仅适用于超级快没有损坏的情况,在suer-block损坏后,用fsck修复会擦掉记录的信息,这会导致extundelete无法扫出任何可恢复的文件,也就是说,如果你恢复时报super-block的错误的话,基本上是找不回来了

时间: 2024-10-07 05:25:33

有关extdelete恢复测试的相关文章

RMAN恢复测试

今天做RMAN恢复的测试,做恢复测试,必须在数据库有备份的前提下进行,样例中采用的是完全备份,模拟以下几种情况下的恢复: 1)数据库运行过程中数据文件全部丢失: 2)数据库运行过程中非关键数据文件丢失: 3)数据库运行过程中关键数据文件丢失: 4)联机重做日志文件/归档重做日志文件丢失(未测试): 5)增量备份下归档日志文件丢失(未测试): 在每个模拟中,都要做一次完全备份,上一个的完全备份可以给下一个模拟使用. 一.测试环境描述 系统版本:Red Hat Enterprise Linux Se

pg_rman备份恢复测试

环境描述 1.OS CentOS Linux release 7.2.1511 (Core) X64 2.PostgreSQL PostgreSQL 9.6.1 3.pg_rman pg_rman-1.3.3-pg96.tar.gz v1.3.3 注意:请下载版本对应的源码包. https://github.com/ossc-db/pg_rman/releases/download/v1.3.3/pg_rman-1.3.3-pg96.tar.gz pg_rman-1.3.3.tar.gz(此源码

RMAN 0级恢复测试---RAC+ASM恢复到单机

最近做了一次RMAN 0 级恢复测试,测试模拟了生产数据库发生灾难性故障,只剩下rman全备份的备份片,利用备份的spfile.控制文件.数据文件.归档日志恢复数据的过程. 首先说一下环境,网上很多文章都是互相粘贴,并不一定适用于你的测试环境.我这次测试的生产环境是2个节点的RAC,存储使用了ASM去管理,操作系统为RHEL6.4,Oracle11.2.0.4,rman每日全备份,使用全备份去恢复数据.恢复的机器选择了1台PC机,安装RHEL6.4,操作系统.Oracle版本均和服务器一致,区别

ORACLE数据库文件丢失后的恢复测试

一.测试环境 数据库版本是11GR2,在做完一份完全备份之后,关机,做一份快照,每一次开机之后都执行数次alter system switch logfile以产生归档日志. 之后的测试都是基于这么一个完全备份来恢复. CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/%F'; backup incremental level 0 format '/backup/%T_%f' database; 二.

xtrabackup备份恢复测试 -转

Chinaunix首页 | 论坛 | 认证专区 | 博客 登录 | 注册 博文      博主 王恒-Henryhengwang.blog.chinaunix.net 我的项目:https://github.com/HengWang/ ChinaUnix博客技术文章推荐标准和规范 有奖征集:文集--博客系列博文管理 CU博客频道6月技术图书有奖试读活动 首页 | 博文目录 | 关于我 king_wangheng 博客访问: 486455 博文数量: 117 博客积分: 1715 博客等级: 上尉

一个简单的binlog恢复测试

日常的数据备份及恢复测试,是DBA工作重中之重的事情,所以要做好备份及测试,日常的备份常见有mysqldump+binlog备份.xtrabackup+binlog备份,无论那一种,几乎都少不了对binlog的备份,说明了binlog在数据恢复中的重要性,下面做个小测试,是工作中不少运维或者新人DBA容易犯的错. 创建一个测试表tb1: <test>([email protected]) [xuanzhi]> show create table tb1\G ***************

sqlplus 组件意外被破坏恢复测试

sqlplus 组件意外被破坏恢复 在执行 sqlplus / as sysdba 命令后没啥反应,有点奇诡... [[email protected] bin]#sqlplus / as sysdba [[email protected] bin]# ls -trl ... -rwxr-x--x 1 oracle oinstall         0 Dec  9 15:52 sqlplus  -------这个文件居然被写空了 ... 恢复测试: 从oracle 11201拷贝一个sqlpl

xtrabackup 备份mysql数据库三: innobackupex 测试一个全量和两个增量的备份恢复测试

## 查看当前库中表的数据 ([email protected]) [test]>select count(*) from t_innodb; +----------+ | count(*) | +----------+ |        0 | +----------+ 1 row in set (0.00 sec) ## 执行插入数据操作,该操作在全备之后执行完成 ([email protected]) [test]>call addTest(100000,0); ## 执行全库备份 #

MySQL Drop Database之后的恢复测试

工具介绍 工具的名字叫做:  undrop-for-innodb 代码地址: https://github.com/twindb/undrop-for-innodb 官方文档: https://recovery.twindb.com/ 介绍工具的一篇ppt  http://www.slideshare.net/akuzminsky/undrop-for-innodb 当MySQL 执行 Drop Table或者 Drop Database 的时候,InnoDB并没有删除数据,数据的Page还在磁