The newly initialized RAID
Mark B., 2018-10-09 15:30
Last week we got a RAID-Disk from a company. The administrator changed a broken disk and accidently reinitialize the RAID instad of rebuilding the array.
That causes all data to be lost. As handy IT-guy the administrator tryed to get the data back with some recovery tools but only a RAW-recovery was possible with the overwritten filesystem-cataloge. So this try ended with tousends of files named only after the position on the disk without any folders, senceful filenames or other metadata which would help to reassamble the Foxpro-Database with all the client- and bookkeeping-data of the last 3,5 years. That would also mean that tousends of Word- and Excel-file has to be opend, checked, renamed and sorted by hand.
After we got the disk we used a individually written Python script to RAW-recover all Inodes. After filtering out the ones which was not overwritten or nulled out we could start to reassamle the filsystem-catalogue partially with spezialized software. That allowed us to restore some of the filenames and folder-structure. So we ended up with some files and a not functional / complete database.
A full RAW-recovery of all known filetypes give us some missing files and a huge ammount of dublicate files. So we used another Python script to compare the RAW recovered files with the ones from the step before and we could eleiminate almost all dublicates. That leave only a few houndred office-files for the client to check by hand.
So far so good but we had still no intact database and that was the mission critical data we must restore. So we started to extract all backup ZIP-arcives from the database into individual folders and we saw there are just incremential backups and the only full backup was quite old. Without the right filenames and folderstructure would the automatic restore tool from the FoxPro database not work.
So we had to find a way to do this by hand and wrote again some scripts fo find the newest version of the missing files within the backups and we restored the missing parts of the database from the backups by hand. That should theoretically work but when we try to start the database programm it crashed with a error-message that don't really tell us a lot except some of the over 100 files is corrupted. So we backuped the restored not functional database and create a new empty database in the FoxPro programm. By replacing each database-table individual we could identify two corrupted tables which cause the crash and replace them also with functional versions from the backup. Then we could finally start the application and access the database.
Finally the client only lost a few enties in some of the tables and get the most data back as in the day of the dissaster. After the client filled in the missing entries we migrated the database to a new one to prevent further troubles caused by the hand reassembly.
