15 years of data go...
 
Notifications
Clear all

15 years of data gone? [48TB]

9 Posts
4 Users
0 Likes
768 Views
(@lowgen)
Posts: 4
New Member
Topic starter
 

Hi everyone,

I apologize in advance for the long post, I tried to include as much details as possible. I created the topic in the General Discussion subforum because it's also filled with questions. If it really goes to the point where I need to post it in Services Required, I'll do.

So I currently have 4x12TB Seagate Barracuda Pros. About 6 months ago I transferred everything I had, which was on 3 fully loaded 8TB Seagate Archives, onto these new drives. Now of course, if I'm here today it's because I don't have backups (more on that later). I still am cautious and try to minimize the chances of a disaster however I can by taking care of my drives, shutting them off correctly, not overusing them, not letting them run 24/7, replacing them completely every few years instead of leaving stuff on old drives, etc. I'm totally aware that all of this doesn't replace a good backup strategy, and that I'm walking on thin ice, but it's all I could do for all these years.

Last week I decided to repurpose the 8TBs, but I wanted to check and full format each one before using them. The 12TBs were running in an external Icy Dock enclosure over USB 3.0, and I plugged all three 8TB drives directly via SATA on the mobo. OS drive is a seperate SSD running Windows 10. [side note The Barracudas were initialized and quick formatted under Windows 8.1 as I received them, and then the data was moved from the 8's to the 12's]. So anyway, I boot up Seatools to check the 8's, all tests pass. In the program, the 12's were also shown in the list (forgot to turn off the enclosure). They were not being recognized as "genuine" Seagates with correct model numbers, but generic ones with all the same serial. But well, they were still recognized so I thought "why not? they're seagates after all". That was my first mistake… I ran all the same tests that I did on the 8's, and everything pass. SMART, Short DST, Short Generic, Fix All Fast. I exit Seatools, keep doing some more stuff on the PC, can still access all my drives, everything's fine. When I finally decide to shut the enclosure down using "safely remove", I get the "device still in use" prompt. I remember being surprised because it hadn't happened to me for a while since I've been on Windows 8 and 10, but whatever. Of course I don't force or abruptly unplug anything, and I shut down the PC to let the OS close whatever it's complaining about by itself. So far so good.

I reboot the next day, switch the enclosure on, get to the desktop, to be greeted with the "you need to format the drive" message. All drive icons are there in Explorer, without any size info below each one, and can't be accessed. I run chkdsk without switches on all four drives. [logs uploaded to my personal MEGA account]

As soon as I start googling, the one program that gets mentioned the most is TestDisk, so I give it a go. I proceed to remove the Barracudas from the enclosure, plug them one at a time on the mobo via SATA, and check the partitions, MBR and MFT for each drive. 2 out of 4 have correct MBR and MFT. They can't be accessed by Explorer, but I can browse the filesystem through TestDisk and I recognize my directory structure. Nice! I boot up Linux, and it mounts these 2 drives with seemingly no problems.

But something bothers me, and this is my first question… The majority of my folders (on these two drives only) were moved into "found.000" by chkdsk, HOWEVER, the full directory structure is intact, and files don't seem to be corrupted? I have not read a single instance online about files being moved there while not being corrupted. I guess I should be happy about that, but I find this too good to be true. Not a single FILE0001.CHK, FILE0002.CHK, etc. All files inside this folder seem fine, with correct extensions and all. Of course I didn't check every single one, but the ones I tried were correct. It's as if my whole directory structure had just been "moved" there for no reason. Also, why did they get there in the first place? I ran chkdsk in read-only mode specifically because I didn't want it to do anything. These two drives, let's call them Barracuda2 and Barracuda3, contain all my media files. CD/DVD/SACD/Bluray backups. If I can find out the reason they've been moved there and that it's safe to say they're fine, then I can likely just get the data back myself, but I can't seem to find an answer to this.

Now, on to the stressful part. My absolute most important drive is the one with my personal files that contain everything from the last 15 years of my digital life, and everything that's been digitized from years before. Let's call this one Barracuda1. Scanned pictures/letters/documents, digital camera photos and videos, iphone backups with, of course, more pictures, pictures of my bernese that's not getting any younger, chat logs and mails from 2006 onwards, important notes, long texts I've written, own musical compositions, transaction details for eBay/Amazon/Visa/bank/misc online accounts, various OS backups (win/mac/linux, lots of programs for each platform, source code and config files on there too). Pictures/documents that were scanned were discarded, digital camera files were dumped on the drive whenever the SD card was full, etc. I have a (bad, in this case) habit of trying to minimize the size of my physical belongings, so anything that can be digitized goes on there. I guess you could call it a disease at this point. It's even worst not backing up when the only copy of everything that you own is digital. So what's so stressful about this one? TestDisk can't access the filesystem. The MBR was bad but I was able to restore it from its backup. The MFT, however, is corrupted and can't be repaired with the mirror. There are millions (not an exaggeration) of files in there and the directory structure is nothing less than… surprising, to say the least. It already was a mess to navigate even in folders, I wouldn't want millions of unknown files in a single directory. So raw recovery is not on the horizon until I'm 100% sure what's corrupted from the MFT can't be patched from the mirror, or from parts of the old 8TB drive MFT, or repaired in any other way with some hex editing magic.

Even though I didn't really want to mess with these consumer oriented programs at first, I still had to try something to get some kind of reassurance that not *everything* was gone. I don't mean to say they're bad, but for a directory structure as complex as mine, I wouldn't let them have the last word. I trust much more the expertise of an actual human tech to know what's what and make thoughtful decisions. I've been having mixed results with these programs anyway. So far I've tried MiniTool, ZAR, R-Studio, GetDataBack and RestorerUltimate. I've been able to see some of my directories, but none seems to find the same files. Granted I was too afraid to let scans run for too long and I never let one finish completely so that probably explains it. That's all I did with those, just to see what they could find. Usually less than 10% scans. No kind of fixing or anything that would write to the disks or any other destructive actions. Also, the drives don't seem to present any physical damage symptoms. They spin normally with no unusual noises, but I'm still minimizing the time it's being plugged in, just in case.

I have dumped the root files ($AttrDef, $Bitmap, $Boot, $LogFile, $MFT, $MFTMirr, $UpCase, $TxfLog) if anyone wants to take a look, it would mean a lot to me. Just PM, or say it here and I'll send you the 22MB 7z file.

I'd really like to know if any kind of estimate of the corruption could me made by looking at the $MFT and $MFTMirr, and if any kind of readable list of the directory structure could be exported just so I know what I've lost exactly. Say I could get back 75% of the original structure, it would be less painful having only the remaining 25% as raw/unnamed files. Such a list could possibly help me get the raw files somewhat sorted back again. I've seen some great and open source tools to manipulate the MFT and other important FS files, mostly from the seemingly very talented jschicht, but analyzing these files is beyond my capabilities.

Here's a summary of what I could gather from TestDisk

Barracuda1 and 4
-Cannot access FS
-MBR good
-MFT corrupted cannot be repaired

Barracuda2 and 3
-Can access FS
-MBR and MFT good
-Most dirs moved to found.000

Something which *might* work out in my favor, is the fact that all the stuff was transferred in one go, onto brand new drives, not that long ago. Opposed to being created/modified/deleted randomly over time. Not many changes have happened since I transferred those files, so fragmentation is potentially not an issue in this case.

To answer "why didn't you have a backup if those files were that important to you?", here's why. I've been battling depression for the last 6 years, am currently unemployed because of it, and I barely had the money for the main drives to begin with, let alone twice the number of drives. These new Barracudas retail for $600 a pop before tax. That being said, a few days ago, I thought to myself "well I think I have enough data now to be completely devastated if anything was to happen to my stuff". It's not like I didn't care about backups or anything. I even arranged for a 3k loan with someone I know, in order to buy 4 other drives to mirror my stuff, and guess what? THE VERY SAME DAY, like 2 hours after talking about my backup intentions, I boot the PC and this happens.

I'm trying to be positive, even though I'm completely devastated. It did come to tears, I'm not ashamed of saying it. 15 years of communication logs, pictures of past and present girlfriends, lost family members, my dog, which has an estimated 8 years life expectancy and for which I've documented every step of his growth. I just can't believe it. I would be less torn apart if I actually never cared about backing up, but I was THIS close…

 
Posted : 28/08/2018 7:01 am
(@soft512byte)
Posts: 16
Active Member
 

Write to recovery@512byte.ua. I can look at your disks

 
Posted : 28/08/2018 8:29 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Only a few points of general advice/considerations.

1) the $MFTmirror is not (exactly) what you believe, the $MFTMirror should be called $MFT_incipit_mirror as it consists of a copy of only a few initial records of the $MFT, it is pretty much unuseful, as it is relevant only if by accident the first few entries of the original $MFT are overwritten/corrupted

2) you are correct, since you have "transferred" your files to the new drives "in bulk" relatively recently there are good chances that a large part of them are contiguous (good news as they can be recovered by parsing them), the real issue with data (hopefully) recovered by direct carving is that filenames (and filesystem metadata) will be not recovered, thus you will have (in your case a very large amount of) nameless files.
A bonus would be anyway if the actual files are "common" file formats, many of them may include internally metadata good to rebuild the filename and/or give them back a "sensible" time/date

3) you can try also analyzing the disk(s) with dmde
https://dmde.com/
which is a program that is not a "push button" one, but that can still - within limits - be used by a "final user" and that has some very good capabilities in recovering on NTFS, by the way it is the program I would suggest you to use to dump the $MFT. Since it has some non-conventional ways to both locate an interpret the $MFT it is anyway worth a shot trying reading the disk(s) with it, though, given the importance of the data you have lost, I wouldn't suggest you to attempt the recovery of the file with it unless at first run it can identify the files, it won't alter any data on the disk, so it is safe to try it and see what it can find.

4) a very interesting option would be to see what can be salvaged from the old 8 Tb disks, if you only "quick formatted" them the data (though not - or only partially - the $MFT) are still there.

5) a non trifling issue in this case is the sheer amount of data, the "right" procedure would be to NOT modify anymore in any way the original disks, and do the recovery tests on images or clones, this implies two new sets of disks, one to make the clones and one to store the (hopefully) recovered data. In this case that would mean 2*4=8x12 TB disks + 2*3=6x8 TB disks which I understand amount to thousands of US$ just for the media. The theoretical amount of new disks can be reduced a little bit because some of the "now corrupted" disks can probably be re-used adopting some smart planning of the recovery, still you will need at the very least 1 set of new disks.

6) on the other hand, given the importance of the data, I am reluctant in suggesting you any further DIY (as said unless a quick scan with dmde looks promising) and using a professional service for the recovery will be very costly.

jaclaz

 
Posted : 28/08/2018 9:53 am
(@mscotgrove)
Posts: 938
Prominent Member
 

The disks are NTFS, are they a single partition.

If so finding the $MFT should be straight forward data recovery.

You mention JBOD - were you using this feature, or is it just standalone 12TB drives?

I am worried about running chkdsk, it can help, but it does make changes to the drives. Recovery is always safest when you ensure the drives are read only, ie with a write blocker

 
Posted : 28/08/2018 12:02 pm
(@lowgen)
Posts: 4
New Member
Topic starter
 

Thanks for your input, jaclaz.

Regarding the $MFTMirr, you're right. I have seen this mentioned a few times already. My post has been written over the course of 4-5 days and I haven't thought about changing this part. Now that I think about it, I'm not sure anymore if it said they were both corrupted or just the main one. At any rate, if TestDisk said it wasn't able to repair the MFT, then most likely more than the first few entries must be corrupted. Unless there's something unusual with the MFT and that TestDisk just didn't know the exact position or something.

I'll give DMDE a shot to see what it can find, and dump the $MFT. I'll also try to see if it can find anything on the 8TBs. Although I just recalled that while I haven't fully formatted the drives, I did put them in RAID0 and used them for a short time, filling them with at least 8-10TBs of more data before undoing the RAID and putting them as single drives again… So they likely won't be as useful as I initially thought.

Do you have any idea about what could have happened with the "found.000" situation? I know you can't see my particular drive, but I'd like to know if chkdsk is known to sometimes move data there even if it's not corrupted? That's intriguing to say the least, because as I said, the whole directory structure seems to be intact. That would be half of my stuff recovered right there.

Recovery services. I think it's one of the hardest parts for me right now. Of course, they're all the best on the market and they all have 100% satisfied customers. For someone that's not in the field like me, they kinda all look the same. That's why I turned to forensics rather than "regular" recovery services. I know that the tiniest single bit of metadata could potentially change everything for you, and that you'll do whatever it takes to get it. That's what I need, and I'm here to find out if it's possible to know who's the absolute best at doing it. The goal is first and foremost to try and repair the MFT to get the most stuff possible in their original form. Raw recovery should be done as an absolute last resort, only for the MFT entries that 100% can't be repaired or patched by any other means. I'm not exactly sure how MFTs are constructed, but if for example, a file could be recovered to its original directory, although missing its filename or timestamps, I would still prefer having the file in this condition rather than in raw form.

So any suggestions for the best firms, or individuals who happen to specialize in MFTs would certainly be preferable.

 
Posted : 28/08/2018 12:08 pm
(@mscotgrove)
Posts: 938
Prominent Member
 

The disks are NTFS, are they a single partition.

If so finding the $MFT should be straight forward data recovery.

You mention JBOD - were you using this feature, or is it just standalone 12TB drives?

I am worried about running chkdsk, it can help, but it does make changes to the drives. Recovery is always safest when you ensure the drives are read only, ie with a write blocker

 
Posted : 28/08/2018 12:23 pm
(@lowgen)
Posts: 4
New Member
Topic starter
 

Michael,

Yes, the disks all contain just one standard NTFS partition, plus the system reserved one.

I'm not really sure if it's a true JBOD enclosure, or they just called it like that to sound fancy. After googling JBOD I now realize it can act kind of like RAID0 when configured to do so, although mine definitely has no such options, other than just being a plug-and-play ventilated case to put 4 drives in it, which then outputs a single eSATA/USB 3.0 connection. All drives were seen as individual entities by whatever OS I was on at the time. Only thing on my enclosure is the on/off switch and fan speed. https://www.icydock.com/goods.php?id=218

I won't run chkdsk again, I promise. It was the first thing I did when it happened but seeing it still moved some files even running in read-only mode, I won't touch it ever again.

 
Posted : 28/08/2018 12:26 pm
(@mscotgrove)
Posts: 938
Prominent Member
 

The disks are NTFS, are they a single partition.

If so finding the $MFT should be straight forward data recovery.

You mention JBOD - were you using this feature, or is it just standalone 12TB drives?

I am worried about running chkdsk, it can help, but it does make changes to the drives. Recovery is always safest when you ensure the drives are read only, ie with a write blocker

 
Posted : 28/08/2018 2:29 pm
(@lowgen)
Posts: 4
New Member
Topic starter
 

I have dumped the following root files ($AttrDef, $Bitmap, $Boot, $LogFile, $MFT, $MFTMirr, $UpCase, $TxfLog) if anyone wants to take a look, it would mean a lot to me.

Just PM me, or say it here and I'll send you the 22MB 7z file.

Thanks!

 
Posted : 28/08/2018 11:47 pm
Share: