Can an open but "deleted" file be recovered under HP-UX

[Nick Wickens]

Ok heres a question for you - I have a client who due to finger trouble has deleted one of the main database files. However other users have the database open still and the disk space is still showing as active under a bdf so in a way the file must still exist at lease until everyone logs out.

Whilst the file is in limbo is there anything that can "undelete" the file before the users log out and the file is released - Inodes ??

[RAC_1 · Accepted solution]

This is uni world and you should know what are you doing. That said, you can recover it from backups.
Also the following method may be used, beware this is not supported.

## Just verify the file here, its inode and size ##

# bdf|grep fs
/dev/vg01/lvol1 20480 17371 2938 86% /fs
# ll -i /fs/james/itrc/map/myfile
412 -rw-r--r-- 1 root sys 1988 Dec 18 11:48 /fs/james/itrc/map/myfile
# cat /fs/james/itrc/map/myfile
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
0000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000 This is an itrc fsdb test!! 000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111

## unmount filesystem and use ncheck to confirm inode (as if crashed) ##

# umount /fs
# ncheck -F vxfs /dev/vg01/rlvol1|grep 412
412 /james/itrc/map/myfile

## Use fsdb... we want to go into the 999 (user) fileset then go to ##
## the inode in question. Here we can see block allocation which we ##
## can use to dd it off. If there are indirect blocks I have no idea #

# fsdb -F vxfs /dev/vg01/rlvol1
> 999fset
fset header structure at 0x0000000a.0000
fsh_fsindex 999 fsh_fsetname "UNNAMED"
fsh_version 4 fsh_checksum 0xbfb7af5c
fsh_time 1071747956 420001 (Thu Dec 18 11:45:56 2003 BST)
fsh_ninode 544 fsh_nau 1 fsh_old_ilesize 0 fsh_eopdata 0
fsh_fsextop 0x0 fsh_dflags 0x11 fsh_quota 0 fsh_maxinode 4294967295
fsh_ilistino[65 97] fsh_iauino 64 fsh_lctino 0 fsh_uquotino 69
fsh_attr_ninode 0 fsh_attr_nau 0 fsh_attr_eopdata 0
fsh_attr_ilistino[67 99] fsh_attr_iauino 66 fsh_attr_lctino 68
fsh_features 0x0
fsh_previx 0 fsh_nextix 0
fsh_ctime 1071747083 401017 (Thu Dec 18 11:31:23 2003 BST)
fsh_mtime 1071747956 420000 (Thu Dec 18 11:45:56 2003 BST)
> 412i
inode structure at 0x0000219f.0000
type IFREG mode 100644 nlink 1 uid 0 gid 3 size 1988
atime 1071748117 310011 (Thu Dec 18 11:48:37 2003 BST)
mtime 1071748082 190000 (Thu Dec 18 11:48:02 2003 BST)
ctime 1071748082 190000 (Thu Dec 18 11:48:02 2003 BST)
aflags 0 orgtype 1 eopflags 0 eopdata 0
fixextsize/fsindex 0 rdev/reserve/dotdot/matchino 0
blocks 2 gen 0 version 0 17 iattrino 0
de: 14014 0 0 0 0 0 0 0 0 0
des: 2 0 0 0 0 0 0 0 0 0
ie: 0 0
ies: 0

## The de number is the block ##
## the des number is the count from that location, directly below ##
## now find the block size ##

# fstyp -v /dev/vg01/rlvol1
vxfs
version: 4
f_bsize: 8192
f_frsize: 1024 <---- here
f_blocks: 20480
f_bfree: 3109
f_bavail: 2915
f_files: 1320
f_ffree: 776
f_favail: 776
f_fsid: 1073807361
f_basetype: vxfs
f_namemax: 254
f_magic: a501fcf5
f_featurebits: 0
f_flag: 0
f_fsindex: 5
f_size: 20480

## Now the dd - skip to our "de" and pull "des" off. ##

# dd if=/dev/vg01/rlvol1 of=/tmp/hope bs=1024 skip=14014 count=2
2+0 records in
2+0 records out

## verify file ##

# cat /tmp/hope
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
0000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000 This is an itrc fsdb test!! 000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111

## bingo! :-) But note the extra bytes :-( ##

# ll /tmp/hope
-rw-r--r-- 1 root sys 2048 Dec 18 11:53 /tmp/hope

[A. Clay Stephenson]

The size could be corrected as well; after all, it's in the inode. You would dd as many whole blocks as possible then a final dd with od bs=1 count=n to read in the last partial block. Another approach is to use Perl's truncate function to chop the file off to exactly n bytes. I doubt this will really be a problem since almost ceratinly a database file is going to be an integral number of blocks long.

However, you run the risk using fsdb of corrupting other data although this method of capturing the file in another filesystem should be safe. It is imperative that you get non-database users off this filesystem quickly and then shutdown and do nothing else. That may prevent the contents from being overwritten?

How in the world did a user have permissions to remove a database file? If this was a DBA, I would treat this as a DBA problem. Your real answer to this, is recover from backup.

[Nick Wickens]

Thanks for replies - The deleted database file is 7Gb so I think I will give this a miss for now but its handy knowledge for future.

The DBA's are hoping to write the data out elsewhere but if all else fails then its restore from backup time.

As to how it happened .... don't ask. I only came on the scene a few months back and "inherited" this server and yes I had already made recommendations to drop ftp (which is how it was done) and get permissions reset. Hopefully this will allow some action now.

[A. Clay Stephenson]

It's time for a "Come to Jesus" meeting as we say in my part of the country. If you allowed an FTP user to do this then you haven't done your job of screaming sufficently at the Powers that Be. This is a huge security risk --- and what's to prevent this happening tomorrow?