Professional Web Applications Themes

Recovering a deleted open file with fsdb. - Sun Solaris

Lost some data last night. Always aggravating. Solaris 8, ufs. What made this specifically aggravating was that it was "so close". What happened was a DB file was rm(1)'d, but the database was still running, and still had the file open. I could see the file plain as day in /proc/1234/fd. In fact, I copied the file from there to a safer place. Of course, that was an inconsistent file as it was a snapshot of a file in use. Better than nothing, but I was hoping to get something cleaner Just In Case. Using ls -d on the /proc/1234/fd, ...

  1. #1

    Default Recovering a deleted open file with fsdb.

    Lost some data last night. Always aggravating. Solaris 8, ufs.

    What made this specifically aggravating was that it was "so close".

    What happened was a DB file was rm(1)'d, but the database was still running,
    and still had the file open.

    I could see the file plain as day in /proc/1234/fd. In fact, I copied the
    file from there to a safer place.

    Of course, that was an inconsistent file as it was a snapshot of a file in
    use. Better than nothing, but I was hoping to get something cleaner Just In
    Case.

    Using ls -d on the /proc/1234/fd, I was able to determine the inode.

    I was hoping to be able to use fsdb to change the link count on the file
    from 0 to 1, shut down the DB, let it flush the file, then fsck the
    filesystem so it would show up in lost+found.

    But, fsdb simply wouldn't work. I was able to located the inode, print the
    inode, and it all looked good. But when I tried to use the :ln command, I
    would get an error that it couldn't read a block.

    *sigh*

    Here's what I was trying. fsdb is dangerous, and I'm inenxperienced in it.
    And it was late at night, all prime ingredients for utter disaster...but I
    pushed on anyway.

    $ fsdb -F ufs -o w /dev/rdsk/c1d2t3

    (I forget the actual device, and I used rdsk because the fsdb_ufs man page
    said I should do that for volumes larger than 2GB.

    /dev/rdsk/c1d2t3 > :base=0t10

    (set the base to decimal)

    /dev/rdsk/c1d2t3 > 123456:inode?i

    Prints out the inode. It's also supposed to set the current inode in fsdb.
    Now, in my explorations, I found that the i# display is NOT the inode
    number, but after looking at some .h files and other inodes, I think this is
    normal.

    /dev/rdsk/c1d2t3 > :ln=1

    According to the man page, this should set my link count to 1, but I'd get a
    block read error (using some block number that I don't know how is derived).

    I tried various permutations (like 123456:inode:ln=1) to no avail.

    Now, further web crawling suggests that this was simply folly anyway, but
    I'm curious if fsdb was having problems because I was using it wrong, or
    because the file was deleted and in a transitionary state.

    Every article I could find on "recovering deleted files" were all based on
    the file being completely gone, where in my case the file wasn't quite gone
    ("I'm not dead yet!"). I wasn't interested in the "dredge through the
    directory" solutions, linking to gether blocks, etc. The file was whole,
    complete, and consistent because it was still open.

    I eventually gave up, and was able to recover the inconsistent file from
    /proc, but I'm curious for the future if there was something else I could
    have done.

    Thanx!

    Regards,

    Will Hartung
    (com)


    Will Guest

  2. #2

    Default Re: Recovering a deleted open file with fsdb.

    In article <bm1cpq$hjkeb$news.uni-berlin.de>,
    "Will Hartung" <com> writes: 
     

    Not being familiar with fsdb, I wouldn't have looked there.
    What I might have done is hold it open in another process, e.g.

    sleep 10000000 < /proc/1234/fd/1234 &
    SLEEPID=$!

    Shutdown the database.

    cp /proc/$SLEEPID/fd/0 /save/database

    kill $SLEEPID

    However, I haven't actually tried this, so I make no guarantees
    about it working.

    --
    Andrew Gabriel
    Andrew Guest

  3. #3

    Default Re: Recovering a deleted open file with fsdb.


    "Andrew Gabriel" <demon.co.uk> wrote in message
    news:bm1hm8$2mu$uk.sun.com... [/ref]
    running, [/ref]
    the [/ref]
    in [/ref]
    In 
    >
    > Not being familiar with fsdb, I wouldn't have looked there.
    > What I might have done is hold it open in another process, e.g.
    >
    > sleep 10000000 < /proc/1234/fd/1234 &
    > SLEEPID=$!
    >
    > Shutdown the database.
    >
    > cp /proc/$SLEEPID/fd/0 /save/database
    >
    > kill $SLEEPID[/ref]

    No, I'll bet that it would work. Very subtle, very clever. Can't imagine why
    it didn't occur to me at 1AM last night. :-)

    Thanx a lot!

    Regards,

    Will Hartung
    (com)


    Will Guest

  4. #4

    Default Re: Recovering a deleted open file with fsdb.

    "Will Hartung" <com> wrote in message news:<bm1cpq$hjkeb$news.uni-berlin.de>... 

    You picked one inode within that dir (ls -id /proc/1234/fd/*)?
    Not the inode of that dir itself, right?

    Anyway I don't know what those fd/* inodes represent. They are
    separate and unique (from what I can tell) from the true inode of
    the real files in question, so perhaps too special or artificial
    for fsdb.

    Whereas inodes given by "pfiles 1234" (proper ones from what I
    can tell) might have worked fine.
     
    reb@cypress.com Guest

Similar Threads

  1. recovering deleted pages
    By tdeaguero in forum Macromedia Contribute General Discussion
    Replies: 0
    Last Post: August 10th, 12:13 AM
  2. recovering deleted files from a cf or sm card
    By h wong in forum Adobe Photoshop Elements
    Replies: 7
    Last Post: September 4th, 10:55 PM
  3. Recovering deleted files from CF & SM cards
    By h wong in forum Adobe Photoshop 7, CS, CS2 & CS3
    Replies: 1
    Last Post: September 2nd, 07:27 AM
  4. Help with fsdb restoring a file
    By Anne Tuchscherer in forum AIX
    Replies: 0
    Last Post: July 11th, 04:45 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139