Recently I received a set of drives that were originally in a RAID 5 (stripe set) configuration. These drives were old Seagate forty gigabyte Parallel ATA (PATA) drives. The client explained that they had rebooted the server and when it came up again the file system had been corrupted and the operating system would not load. After some data massaging, and an operating system install on another partition, the system was revived enough so they could pull data from the drives. However the data was corrupt and unusable. That is where DTI comes in.
After speaking to the client and interrogating the technician that worked on the RAID I realized that a great deal had been done to the RAID but it sounded like I might be able to retrieve some of the data through the too-set that I have here at DTI. I gave the client a quote, and asked them to ship the drives to me.
First things first, I cloned all the drives to images and found that the first drive in the array had about twenty bad sectors but the rest were completely clean. Next, I used our internal RAID tools to see if the RAID had a stale drive. It looked like it did. I then mounted the file system and copied off the files the client wanted. These files were from an application called Micro Key Millennium Software and were created by Sybase which was used as the backend for the application. I had no way of finding out if the database was corrupt so I tested a lot of the other data from the file system and a great deal of it looked good. I still had a problem though in that I was not sure if the database for the client’s application was usable. I decided to set up an FTP account and placed the database files the client needed on the server. They then downloaded the files and put them on their server to load. Sad to say, the files did not load and threw an error, a Sybase error.
After several hours of going back and forth trying to figure out what was going on I did some research and found that the database error had to do with inconsistent page numbers. In other words, the application was loading page number ‘X’ and getting page ‘Y’. This meant to me that each of the pages within the Sybase database file was numbered on disk and Sybase used that as a consistency check when loading information from the database. With that being said it was now my task to find out where the page number was stored on-disk within the page.
I have worked with several file formats that use a page numbering system, and found that the page number is either stored at the beginning of the end of the page. With Sybase it happened to be at the end, an ‘unsigned int’ that was six bytes from the end of the file. Knowing this I wrote an application that pulled the page up, checked the page number against one that I using in the software, to see if they match. If they don’t I increment a counter and display it in the dialog box of the software. The software let me know that this particular file had over 173000 pages and over 7500 invalid page number errors. With that may errors it was clear to me that the database file had been overwritten with garbage or corrupt data and was unrecoverable by me. Sybase is currently looking at the file trying to pull the raw data so it can be re-indexed.
The software tool that I wrote for me I now give to you. There is really no documentation as there are only two functions, ‘Load the File’ and ‘Scan the File’. Both of these functions are on the menu bar under file. One fact to note however is that in my research I found that the page size for the database file is dynamic so I put a drop down combo box in so you could the update which page size to use.
**Note there is no cost for the software once you add to the cart the price will be $0. Thank you **
See below for a quick walk-thru on how to run the software.
Here is the main screen, as you can see it is a very simple utility. We are not going to damage the Sybase database in anyway, as we are only scanning the file not writing anything to it.
First thing you need to do is go to file and choose the Sybase data base you want to scan.
You will be looking for a .db file and depending on whether you have copied the file off or it is still in the data storage directory a file browser will come up in order for you to find the file.
As you can see the file list is not populated with the data base file. The next step you want to take is select the page size. This is an important step because if you are incorrect then you will get a false read and the software will report many bad pages that may or may not be bad.
Now that we have the data base selected and the page size chosen it is time to actually scan the file. Go to file and chose check page numbers. The scan will start and you will see a progress bar moving along the bottom. The page scanned should also be counting up at a rapid pace and hopefully the total bad page numbers is not counting up.
Once the scan is complete you will have the results, the total bad page numbers is a tell tale sign of how corrupt your database is.
If you have any questions please feel free to call DTI Data Recovery at 727.345.9665
