您的位置:首页 > 其它

recover deleted file on ext4

2013-12-31 16:25 295 查看
if the filesystem is ext4 ,the ext3grep tool can't recover the deleted files,

but we can use other tool to recover that.

for example:

SQL> select name from v$datafile;

NAME

--------------------------------------------------------------------------------

/opt/app/oracle/oradata/goolen/system01.dbf

/opt/app/oracle/oradata/goolen/sysaux01.dbf

/opt/app/oracle/oradata/goolen/undotbs01.dbf

/opt/app/oracle/oradata/goolen/goolen01.dbf

+++delete one of datafile

SQL> ! rm -rf /opt/app/oracle/oradata/goolen/goolen01.dbf

+++once the database is closed,the handle of the file was disappears

SQL> shut abort

ORACLE instance shut down.

[root@localhost ~]# df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/cciss/c0d0p2      49G   17G   29G  38% /

tmpfs                 2.9G  895M  2.0G  31% /dev/shm

/dev/cciss/c0d0p1      97M   34M   59M  36% /boot

/dev/cciss/c0d1p1     135G   69G   59G  54% /tol

+++restore deleted file

[root@localhost ~]# extundelete /dev/cciss/c0d0p2 --restore-file '/opt/app/oracle/oradata/goolen/goolen01.dbf'

WARNING: Extended attributes are not restored.

WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set.

The partition should be unmounted to undelete any files without further data loss.

If the partition is not currently mounted, this message indicates 

it was improperly unmounted, and you should run fsck before continuing.

If you decide to continue, extundelete may overwrite some of the deleted

files and make recovering those files impossible.  You should unmount the

file system and check it with fsck before using extundelete.

Would you like to continue? (y/n) 

y

Loading filesystem metadata ... 391 groups loaded.

Loading journal descriptors ... 25090 descriptors loaded.

Writing output to directory RECOVERED_FILES/

Restored inode 1065596 to file RECOVERED_FILES/opt/app/oracle/oradata/goolen/goolen01.dbf

+++recovered data is saved in RECOVERED_FILES

[root@localhost ~]# cd RECOVERED_FILES/

[root@localhost RECOVERED_FILES]# ls

opt

[root@localhost RECOVERED_FILES]# cd opt/

[root@localhost opt]# ls

app

[root@localhost opt]# cd app/

[root@localhost app]# ls

oracle

[root@localhost app]# cd oracle/

[root@localhost oracle]# ls

oradata

[root@localhost oracle]# cd oradata/

[root@localhost oradata]# ls

goolen

[root@localhost oradata]# cd goolen/

[root@localhost goolen]# ls

goolen01.dbf

[root@localhost goolen]# cp goolen01.dbf /opt/app/oracle/oradata/goolen/

[root@localhost goolen]# chown oracle:oinstall /opt/app/oracle/oradata/goolen/goolen01.dbf 

+++recover database:

SQL> startup

ORACLE instance started.

Total System Global Area 1570009088 bytes

Fixed Size                  2213696 bytes

Variable Size            1040189632 bytes

Database Buffers          520093696 bytes

Redo Buffers                7512064 bytes

Database mounted.

ORA-01157: cannot identify/lock data file 6 - see DBWR trace file

ORA-01110: data file 6: '/opt/app/oracle/oradata/goolen/goolen01.dbf'

SQL> recover datafile 6;

Media recovery complete.

SQL> alter database open;

Database altered.
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: