Skip to content

When you have lost your data…..

March 7, 2006

Today was not the first time, and won’t be the last time that someone contacted me after loosing a load of data. Previous incidents have included when my partner was writing a letter on my Ultra1 at home and my daughter decided that the system would run much better without power.

On rebooting the file was zero length. This letter had taken days to craft so simply starting again was really low on the list of priorities. The file system on which it had lived was UFS and I could access the system over the network (I was on a business trip at the time), there were no backups…

The first thing about any situation like this is not to panic. You need to get the partition that used to contain the data quiesed so that no further damage is done. Unmount it if you can. Then take a backup of it using dd:

dd if=/dev/rdsk/c0t0d0s4 of=copy_of_slice bs=128k 

Now you use the copy_of _slice to go looking for the blocks. If the file is a text file then you can use strings and grep to search for blocks that may contain your data. Specifically:


strings -a -t d < copy_of_slice | grep “text in document”  

This outputs the strings that contain “text in document” and their byte offsets you use these offsets to read the blocks.


73152472 moz-abmdbdirectory://abook.mab 136142157 fc9roaming.default.files.abook.mab 136151743 7moz-abmdbdirectory://abook.mab 136151779 !6fb-moz-abmdbdirectory://abook.mab


I use a shell function like this for a file system with an 8K block size:


function readblock {         dd bs=8k count=1 iseek=$(($1/ 8192)) < slice7 }


Since the file in this case was called slice7 to get the blocks.


$ readblock 73152472


then you have to use your imagination and skill to put the blocks back together. In my case the letter was recovered, sent and had the disired outcome.


Todays example is not looking so good. Firstly the victim had actually run suninstall over the drive and had no backup (stop giggling at the back) which had relabled the drive and then run newfs on the partition. Then when the dd was run the output file was wirtten onto the same disk so if the label did not match more damage was done. I might suggest that he run over the drive and then throw it into the pond just to make live interesting. It’s a pity as since only the super blocks would have been written the chances of recovery where not that bad.


So to recap. Don’t get in this situation. Backup everything. Use ZFS, use snapshots, lots of them.


However if you have lost your data and want to stand any chance of getting it back:

  1. Don’t Panic.

  2. Quiese the file system. Powering off the system may well be your best option.

  3. Get a bit for bit copy of the disk that had the data. All slices. Do this while booted of release media.

  4. Hope you are lucky.


Tags: topic:[data loss] topic:[UFS] topic:[solaris]

Advertisements

From → Solaris

When you have lost your data…..

March 7, 2006

Today was not the first time, and won’t be the last time that someone contacted me after loosing a load of data. Previous incidents have included when my partner was writing a letter on my Ultra1 at home and my daughter decided that the system would run much better without power.

On rebooting the file was zero length. This letter had taken days to craft so simply starting again was really low on the list of priorities. The file system on which it had lived was UFS and I could access the system over the network (I was on a business trip at the time), there were no backups…

The first thing about any situation like this is not to panic. You need to get the partition that used to contain the data quiesed so that no further damage is done. Unmount it if you can. Then take a backup of it using dd:

dd if=/dev/rdsk/c0t0d0s4 of=copy_of_slice bs=128k 

Now you use the copy_of _slice to go looking for the blocks. If the file is a text file then you can use strings and grep to search for blocks that may contain your data. Specifically:


strings -a -t d < copy_of_slice | grep “text in document”  

This outputs the strings that contain “text in document” and their byte offsets you use these offsets to read the blocks.


73152472 moz-abmdbdirectory://abook.mab 136142157 fc9roaming.default.files.abook.mab 136151743 7moz-abmdbdirectory://abook.mab 136151779 !6fb-moz-abmdbdirectory://abook.mab


I use a shell function like this for a file system with an 8K block size:


function readblock {         dd bs=8k count=1 iseek=$(($1/ 8192)) < slice7 }


Since the file in this case was called slice7 to get the blocks.


$ readblock 73152472


then you have to use your imagination and skill to put the blocks back together. In my case the letter was recovered, sent and had the disired outcome.


Todays example is not looking so good. Firstly the victim had actually run suninstall over the drive and had no backup (stop giggling at the back) which had relabled the drive and then run newfs on the partition. Then when the dd was run the output file was wirtten onto the same disk so if the label did not match more damage was done. I might suggest that he run over the drive and then throw it into the pond just to make live interesting. It’s a pity as since only the super blocks would have been written the chances of recovery where not that bad.


So to recap. Don’t get in this situation. Backup everything. Use ZFS, use snapshots, lots of them.


However if you have lost your data and want to stand any chance of getting it back:

  1. Don’t Panic.

  2. Quiese the file system. Powering off the system may well be your best option.

  3. Get a bit for bit copy of the disk that had the data. All slices. Do this while booted of release media.

  4. Hope you are lucky.


Tags: topic:[data loss] topic:[UFS] topic:[solaris]

From → Solaris

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: