Very Computer

> Is there a method of doing this?  The drive is not mountable (fsck did not
> work).  Using fsdb, I can follow the directory tree to the file I want.  I
> have the file's inode number along with its size, date of creation, etc.  It
> seems, at least, the inode tables are still there.  My guess is there's a
> way to do this with dd.  I could dd the entire volume (if=/dev/userlv) out
> to a file but the thing would be around 40 GB and space right now is slim.
> Any ideas?

> Is there a method of doing this?  The drive is not mountable (fsck did not
> work).  Using fsdb, I can follow the directory tree to the file I want.  I
> have the file's inode number along with its size, date of creation, etc.
It
> seems, at least, the inode tables are still there.  My guess is there's a
> way to do this with dd.  I could dd the entire volume (if=/dev/userlv) out
> to a file but the thing would be around 40 GB and space right now is slim.
> Any ideas?

> Thanks to all who responded...

> I was able to mount the file system in read only mode.  I think a few inodes
> were lost but I've recovered all the high dollar data that had been
> generated since the last backup. Whew!

> The filesystem type was jfs.  fsdb did give plenty of info regarding inode
> and address location.  It may not be that hard to extract a file from an
> unmounted /dev/xxxlv device given the info obtained from dd but I'm not sure
> what the exact steps would be.

> This experience has inspired me to do three things...

> 1.  Verify that the backups being made are actually what you think they are.
> The previous sys admin had a cron job that ran backups every night around
> midnight.  I had no idea he had done this.  On odd days, it would backup our
> /projects directory.  On even days it would do the /users directory.  After
> I manually backed up the /users drive on Monday, cron came in on Tuesday
> (without my knowledge) and overwrote my /users backup with the /projects
> backup:-(  Wednesday morning one of the users complained he couldn't get to
> his /users account.  That's when the /users array went south.  I thought no
> big deal, I've got a backup of /users.  I did a tar -tv on the tape and was
> horrified to find only the /projects drive.  My .sh_history confirmed I did
> indeed do a tar -cv /users on Monday but the crontab kicked in on Tuesday
> overwriting the tape.

> 2.  Do backups regularly.  I'm not by profession a  sys admin.  I'm an
> aerospace engineer who knows more than others in his department about Unix
> workstations.  I do the admin work on kind of a pro bono basis.  This,
> however, does not absolve me of my sin.  Regardless of how active our server
> has been,  from now on I'll be sure the backup are done regularly.

> 3.  Finally, I want to know more about data recovery.  In the past few days,
> I've read some fascinating techniques for recovering deleted
> files/directories and repairing broken file systems.  I'll be doing some
> experiments with dummy file systems to see if I can really use dd to extract
> files from an unmounted fs given the inode number and block address info.
> Wish me luck!

> Thanks again,
> Chris,

> > Thanks to all who responded...

> > I was able to mount the file system in read only mode.  I think a few inodes
> > were lost but I've recovered all the high dollar data that had been
> > generated since the last backup. Whew!

> > The filesystem type was jfs.  fsdb did give plenty of info regarding inode
> > and address location.  It may not be that hard to extract a file from an
> > unmounted /dev/xxxlv device given the info obtained from dd but I'm not sure
> > what the exact steps would be.

> > This experience has inspired me to do three things...

> > 1.  Verify that the backups being made are actually what you think they are.
> > The previous sys admin had a cron job that ran backups every night around
> > midnight.  I had no idea he had done this.  On odd days, it would backup our
> > /projects directory.  On even days it would do the /users directory.  After
> > I manually backed up the /users drive on Monday, cron came in on Tuesday
> > (without my knowledge) and overwrote my /users backup with the /projects
> > backup:-(  Wednesday morning one of the users complained he couldn't get to
> > his /users account.  That's when the /users array went south.  I thought no
> > big deal, I've got a backup of /users.  I did a tar -tv on the tape and was
> > horrified to find only the /projects drive.  My .sh_history confirmed I did
> > indeed do a tar -cv /users on Monday but the crontab kicked in on Tuesday
> > overwriting the tape.

> > 2.  Do backups regularly.  I'm not by profession a  sys admin.  I'm an
> > aerospace engineer who knows more than others in his department about Unix
> > workstations.  I do the admin work on kind of a pro bono basis.  This,
> > however, does not absolve me of my sin.  Regardless of how active our server
> > has been,  from now on I'll be sure the backup are done regularly.

> > 3.  Finally, I want to know more about data recovery.  In the past few days,
> > I've read some fascinating techniques for recovering deleted
> > files/directories and repairing broken file systems.  I'll be doing some
> > experiments with dummy file systems to see if I can really use dd to extract
> > files from an unmounted fs given the inode number and block address info.
> > Wish me luck!

> > Thanks again,
> > Chris,

> Can you share what you have been reading about data recovery tips
> and techniques?