我不小心使用rm删除了一个数据文件，怎么恢复呢？

美文

我不小心使用rm删除了一个数据文件，怎么恢复呢？我的操作系统是AIX5。1

orian

基本上没办法恢复。如果没有专门备份，就不用想了

弱智

嗬嗬，如果能够轻易恢复，那么就不是“安全性能很高”的Unix了。

RS9000

rm慎用，并尽量不要使用通配符

弱智

养成一个习惯:
alias rm='rm -i'

这就是为什么用BSD的哥们很不习惯用linux的在rm时还要'-f'
因为现在linux发行版的rm 实际上都是别名了。就是提醒悮删除

西诺

在你玩死机器的同时 机器也把你玩死了。rm  作ibm工程师都是瞪大眼睛看看美女那样盯着啊 敲回车键盘的时候 手都发抖的。现在一个rm，就是上百gb。你就是有备份还能恢复，但你有时间吗？客户的唾沫在敲键盘的时候就把你淹没了。处长欲哭无泪 行长穿着睡衣，“md，你要是在明天早上8点恢复不了，我tmd就得写辞职报告了”

zzzyx

恢复不了了。

DB2_AIX

拿出平时看美眉眉的注意力去敲键盘，按回车键，肯定不会犯这种错误！

li

　
　　　　RS/6000 & AIX.数据急救


(1) 如何恢复误删除的文件？
(2) 举例说明(红色为我们应输入的)
(3) 相关知识介绍

数据急救(1): 如何恢复误删除的文件？
当我们在目录中为了方便使用#rm -rf *　删除文件时,有时会发现自己今天真是倒霉，在执行后发现#pwd竟然不是自己想要
删除文件的目录,这时才发现备份是多么重要啊。(可惜呀，没做,), (这就是系统超级管理员常犯的错误，手太快)，没办法，
以头戕地吧。但你在遭遇了巨痛后，如果还没有完全丧失斗志，那么下面这篇文章也许能帮你找会你的文件和自信。希望和
成功往往也只是一念之间*_*\
和DOS,winX,以及众多unix系统一样，当文件被删除时，其所占据的物理空间并没有真正从系统中移除，但他们的状态确是未
分配空间，所以这时只要没有新的文件产生或者文件变化发生在同一个文件系统中，那么我们完全有可能用系统提供的fsdb
(filesystem debugger)来恢复我们的数据
特别感谢此文的英文原文作者，他们还有收费的恢复工具，需要时请访问<http://www.compunix.com/>;
MAKE A BACKUP OF THE ENTIRE FILESYSTEM BEFORE PERFORMING THESE STEPS!!!
ELSE ( BANG !!!!! ).
Steps to recover a deleted file
-------------------------------
1) "ls -id {dir}"
(where dir is directory where file resided)
Record INODE number for next step.
36872
2) Unmount the filesystem.
3) "fsdb /{Mountpoint}" or "fsdb /dev/{LVname}"
(where Mountpoint is the filesystem mount point, and LVname is
the logical volume name of the filesystem)
4) "{INODE}i"
(where INODE is the inode number recorded in step 1)
This will display the inode information for the directory. The
field a0 contains the block number of the directory.
The following steps assume only field a0 is used. If a value
appears in a1, etc, it may be necessary to repeat steps #5 and
#6 for each block until the file to be recovered is found.
5) "a0b"
(moves to block pointed to by field "a0" of this inode)
6) "p128c"
(prints 128 bytes of directory in character format)
Look for missing filename. If not seen, repeat this step until
filename is found. Record address where filename begins. Also
record address where PRIOR filename begins. If filename does
not appear, return to step #5, and selecting a1b, a2b, etc.
Note that the address of the first field is shown to the far left.
Increment the address by one for each position to the right,
counting in octal.
7) "a0b"
(moves to block pointed to by field "a0" of this inode)
If the filename was found in block 1, use a1b instead, etc.
"p128e"
(prints first 128 bytes in decimal word format)
Find the address of the file to recover (as recorded in step 6)
in the far left column. If address is not shown, repeat until found.
9) Record the address of the file which appeared immediately PRIOR to
the file you want to recover.
10) Find the ADDRESS of the record LENGTH field for the file in step
#9 assuming the following format:
{ADDRESS}: x x x x x x x x x x ...
| | | | |-------- filename ------|
inode # --+----+ | |
| +-- filename length
record LENGTH --+
Note that the inode number may begin at any position on the line.
Note also that each number represents two bytes, so the address
of the LENGTH field will be `{ADDRESS} + (#hops * 2) + 1'
11) Starting with the first word of the inode number, count in OCTAL
until you reach the inode number of the file to be restored,
assuming each word is 2 bytes.
12) "0{ADDRESS}B={BYTES}"
(where ADDRESS is the address of the record LENGTH field found
in step #10, and BYTES is the number of bytes [octal] counted
in step #11)
13) If the value found in the LENGTH field in step #10 is greater than
255, also type the following:
"0{ADDRESS-1}B=0"
(where ADDRESS-1 is one less than the ADDRESS recorded in step #10)
This is necessary to clear out the first byte of the word.
14) "q"
(quit fsdb)
15) "fsck {Mountpoint}" or "fsck /dev/{LVname}"
This command will return errors for each recovered file asking if
you wish to REMOVE the file. Answer "n" to all questions.
For each file that is listed, record the associated INODE number.
16) "fsdb /{Mountpoint}" or "fsdb /dev/{LVname}"
17) {BLOCK}i.ln=1
(where BLOCK is the block number recoded in step #15)
This will change the link count for the inode associated with
the recovered file. Repeat this step for each file listed in
step #15.
1 "q"
(quit fsdb)
19) "fsck {Mountpoint}" or "fsck /dev/{LVname}"
The REMOVE prompts should no longer appear. Answer "y" to
all questions pertaining to fixing the block map, inode map,
and/or superblock.
20) If the desired directory or file returns, send money to the author
of this document.
《返回》


数据急救(2): 举例说明(红色为我们应输入的)

首先建立一个临时文件系统/test,然后拷贝/smit.log到/test下做测试。
　 #ls -al
drwxr-sr-x 3 sys sys 512 Feb 26 15:08 .
drwxr-xr-x 37 bin bin 1536 Feb 26 15:03 ..
drwxrwx--- 2 root system 512 Feb 26 15:03 lost+found
----r--r-x 1 root sys 865429 Feb 26 15:05 smit.log
　＃rm -rf　smit.log
　＃ls -al
drwxr-sr-x 3 sys sys 512 Feb 26 16:00 .
drwxr-xr-x 37 bin bin 1536 Feb 26 15:03 ..
drwxrwx--- 2 root system 512 Feb 26 15:59 lost+found

　＃ls -id
2 .
　＃umount /test
　＃fsdb /test
File System: /test
File System Size: 16384 (512 byte blocks)
Disk Map Size: 2 (4K blocks)
Inode Map Size: 2 (4K blocks)
Fragment Size: 4096 (bytes)
Allocation Group Size: 2048 (fragments)
Inodes per Allocation Group: 2048
Total Inodes: 2048
Total Fragments: 2048
2i
i#: 2 md: d-g-rwxr-xr-x ln: 3 uid: 3 gid: 3
szh: 0 szl: 512 (actual size: 512)
a0: 0x09 a1: 0x00 a2: 0x00 a3: 0x00
a4: 0x00 a5: 0x00 a6: 0x00 a7: 0x00
at: Tue Feb 26 15:13:43 2002
mt: Tue Feb 26 15:13:11 2002
ct: Tue Feb 26 15:13:11 2002

a0b
0x0000009000 : 0x00000000 (0)

p128c


a0b
0x0000009000 : 0x00000000 (0)
p128e

最重要的一步，计算偏移量，从lost+found的"inode" 16到smit.log的"inode" 17中间共有
10个间隔，每个间隔代表2个, 那么其值应为20,即16后的值应该改为20,这样才能恢复被删除
文件smit.log的inode.如果要更改16后面的值，要对地址 0x000000901c 赋值,由于是双字
节操作，其值应为　20*65536+10，这样就能实现(488,10-》20,10)。
0x901c=1310730 (1310730=20*65535+10)
0x000000901c.D: 0x0014000a (1310730)
查看更改效果
a0b
0x0000009000 : 0x00000000 (0)
p128e

q
＃fsck /test
** Checking /dev/rlv04 (/test)
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
Unallocated I=17 owner=root mode=100045
size=868373 mtime=Feb 26 15:23 2002
file=/smit.log; REMOVE? n
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Inode Map
** Phase 6 - Check Block Map
Filesystem integrity is not guaranteed
8 files 600 blocks 15784 free

#fsdb /test
File System: /test
File System Size: 16384 (512 byte blocks)
Disk Map Size: 2 (4K blocks)
Inode Map Size: 2 (4K blocks)
Fragment Size: 4096 (bytes)
Allocation Group Size: 2048 (fragments)
Inodes per Allocation Group: 2048
Total Inodes: 2048
Total Fragments:

17i.ln=1
0x0000020888 : 0x00000001 (1)
q
#fsck /test
** Checking /dev/rlv04 (/test)
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Inode Map
Bad Inode Map; SALVAGE? y
** Phase 5b - Salvage Inode Map
** Phase 6 - Check Block Map
Bad Block Map; SALVAGE? y
** Phase 6b - Salvage Block Map
9 files 600 blocks 15784 free
***** Filesystem was modified *****
　#mount /test
　#ls -al
drwxr-sr-x 3 sys sys 512 Feb 26 16:00 .
drwxr-xr-x 37 bin bin 1536 Feb 26 15:03 ..
drwxrwx--- 2 root system 512 Feb 26 15:59 lost+found
----r--r-x 1 root sys 865429 Feb 26 15:59 smit.log

以上例子只是最简单情况，至于实际应用中的各种复杂环境问题，就需要各位朋友们多思考，多实践，勇于创新。
其实在给地址赋值时还有两种方法，大家可以考虑一下其他方式来实现 （488，10-》20,10)
祝朋友们恢复数据成功，一身轻松。
《返回》

数据急救(3):    相关知识介绍
我们进行数据恢复，就要熟悉我们操作系统的文件系统存储原理和结构。
JFS 布局 日志文件系统如何处理磁盘布局
JFS 概述 日志文件系统如何缩短系统重启时间
《返回》

　

nimysun

用finaldata for aix可以恢复。主要安装的时候选择路径的时候，避开datafile所在的分区。

不过这得看你有没有钱买的起这个软件了。