forensic image capturing to RAID 1 (mirrored) hard disks

Hardware RAID is much faster and more reliable than software-based RAID. So an eSATA dual bay dock/enclosure with RAID 1 should fit the bill nicely, such as this item

http//bit.ly/OLUucQ

It's worth the $25.94 if you're willing to take a small gamble at this setup.

marcyu,

Many thanks! The one you've posted a link to is rather inexpensive, actually. I was looking at far more expensive options, based on your experience, perhaps I don't have to. I will always be using RAID 1 (mirrored mode) with just 2 drives, and I've read that this kind of RAID'ing does not necessarily place a significant burden on typical, average RAID controller.

I will post here with my finding upon purchasing and testing one of these things.

Thanks again

No problem, I'm using DAWICONTROL RAID modules as a multiplier for image deployment to up to five drives per channel
http//www.dawicontrol.com/index.php?cmd=proddet&id=stomo (unfortunately no English documentation)

For forensic purposes I'd recommend individual verification.

C.R.S.,

Thanks much for the link and for sharing your experience. It's good to know that others have tried doing this. I was reasonably confident it would work, but I thought it wise to look for other people's input prior to spending time and money.

Thanks

I would use the devices as target for the storage of images.

My goal would be to capture the forensic image to the RAID array of 2 drives configured in RAID 1 mirrored mode. The RAID array would appear to the capturing station as 1 drive. In the background, the RAID controller would simultaneously make an exact "mirrored" copy of the data. So, at the end of the imaging process, you would have two exact copies of the captured forensic image.

Please correct me if I'm wrong, but I think that this is possible, however it is not ideal. Granted it will be faster to make copies of the image taken from the source drive, but you will run into a few problems.

1) You will only see one copy of the image as it will be mirrored. So in order to verify the second image on the RAID, the hard drive will need to be removed and this can cause you problems. This is because the destination does not show the hard drives independently. You should always be verifying each image and not "assume" that because it verified on one disk, it will on the next, even if they are in RAID1 configuration.

2) Granted hard drives are getting larger as time goes by, but surely we now have ports like USB 3.0/ Thunderbolt and even SATA 6 that provide pretty fast transfer speeds, so I don't know why you wouldn't take the time to just copy the image across to another target drive and verify that once again. Surely it can't take that long to do this task, assuming you are working on a relatively fast system.

I would use the devices as target for the storage of images.

<snip>

Please correct me if I'm wrong, but I think that this is possible, however it is not ideal. Granted it will be faster to make copies of the image taken from the source drive, but you will run into a few problems.

1) You will only see one copy of the image as it will be mirrored. So in order to verify the second image on the RAID, the hard drive will need to be removed and this can cause you problems. This is because the destination does not show the hard drives independently. You should always be verifying each image and not "assume" that because it verified on one disk, it will on the next, even if they are in RAID1 configuration.

2) Granted hard drives are getting larger as time goes by, but surely we now have ports like USB 3.0/ Thunderbolt and even SATA 6 that provide pretty fast transfer speeds, so I don't know why you wouldn't take the time to just copy the image across to another target drive and verify that once again. Surely it can't take that long to do this task, assuming you are working on a relatively fast system.

In reply to your 1) -
Yes, I agree with everything you say here, and it actually is my exact plan to verify the second drive independently by taking it out of the enclosure. I was not planning to assume that it would be OK. What I meant to communicate is that upon successfully verifying the primary RAID 1 image, one should, under normal circumstances, be reasonbly confident that he/she will have an exact copy of that image on the second drive but that it will need to be verified independently, of course.

In reply to your 2) -
I understand. The reason I'm interested in this is because my company is doing this work for profit, and my goal is to improve upon the business process. If a technology or business workflow is faster or more efficient, that can translate into $$. So, yes, drives and data buses are getting faster every year, but making a copy of the image and then verifying will never be faster than essentially capturing two copies of the image at the same time, and then just verifying them independently. If you're looking at the business model on a very large scale, saving 1 or 2 or 3 or more hours per average forensic capture is a BIG deal. )

Thanks so much for your reply. I've ordered the RAID device and I will update with my findings.

Apologies if I have missed the point here but a software solution may be simpler and a bit more automated.

You could always use FTK Imager (free from AccessData). It can be set to image once but copy to multiple locations simultaneously (and even in different formats if you wish - E01, dd, SMART, AFF). This could be one locally to work on, one to a backup folder and even one to a file server / NAS for image storage / archiving. The software then verifies each copy independently and stores a verification text file with each image. It also displays a summary window on the screen after each verification so you don't have to go looking at / for each of the verification text files.

By its very nature this must be slower than reading once and just writing one copy but this avoids the need to break apart a mirrored drive pair and place each drive into another machine for independent verification.

Additionally you can set different E01 metadata for each image so you could actually "brand" a copy as a backup or even mark each copy with a different "reference number" in the notes. That may be useful if you routinely supply copies to others and want to know who a copy came from if it was ever distributed without consent.

Apologies if I have missed the point here but a software solution may be simpler and a bit more automated.

You could always use FTK Imager (free from AccessData). It can be set to image once but copy to multiple locations simultaneously (and even in different formats if you wish - E01, dd, SMART, AFF). This could be one locally to work on, one to a backup folder and even one to a file server / NAS for image storage / archiving. The software then verifies each copy independently and stores a verification text file with each image. It also displays a summary window on the screen after each verification so you don't have to go looking at / for each of the verification text files.

By its very nature this must be slower than reading once and just writing one copy but this avoids the need to break apart a mirrored drive pair and place each drive into another machine for independent verification.

Additionally you can set different E01 metadata for each image so you could actually "brand" a copy as a backup or even mark each copy with a different "reference number" in the notes. That may be useful if you routinely supply copies to others and want to know who a copy came from if it was ever distributed without consent.

Apologies for my tardy note as I thought I had followed up.

Thank you for the suggestion. I think it is a good one. So, essentially I would just point FTK Imager at two targets for the same image output.

I suppose my only thought is that I might need to be cognisant of the target buses I'm using to ensure I don't introduce a non-disk bottleneck into the picture by pushing two images concurrently.

Cheers

Thank you for the suggestion. I think it is a good one. So, essentially I would just point FTK Imager at two targets for the same image output.

I had an experience not long ago where I did exactly this – had FTK Imager create both an E01 and an 001 (raw) image of an HFS+ drive at the same time, and had an unexpected result. I thought this would save time, since FTK Imager would only be reading the source once but writing twice. However, not only did the process take longer than doing two separate operations sequentially, but the CSV file lists produced as a byproduct were funky. When I realized they were quite different, I imaged the drive yet again, this time getting yet another CSV. (I realize these file lists aren't particularly important, if the drive image hashes matched, which they did. Nevertheless, it raised questions and I was curious.)

After much work, here's what I discovered. The first two lists were mutually exclusive! And the union of them was the same as the final list. In other words, it seems as though, when creating two images simultaneously, it only wrote the MACE metadata to one list or the other, not both.

Consider this anecdotal evidence, since I didn't run example scenarios multiple times to track down exactly what circumstances were needed to reproduce (and report) the bug, but I did experience it as described.

Thank you for the suggestion. I think it is a good one. So, essentially I would just point FTK Imager at two targets for the same image output.

I had an experience not long ago where I did exactly this – had FTK Imager create both an E01 and an 001 (raw) image of an HFS+ drive at the same time, and had an unexpected result. I thought this would save time, since FTK Imager would only be reading the source once but writing twice. However, not only did the process take longer than doing two separate operations sequentially, but the CSV file lists produced as a byproduct were funky. When I realized they were quite different, I imaged the drive yet again, this time getting yet another CSV. (I realize these file lists aren't particularly important, if the drive image hashes matched, which they did. Nevertheless, it raised questions and I was curious.)

After much work, here's what I discovered. The first two lists were mutually exclusive! And the union of them was the same as the final list. In other words, it seems as though, when creating two images simultaneously, it only wrote the MACE metadata to one list or the other, not both.

Consider this anecdotal evidence, since I didn't run example scenarios multiple times to track down exactly what circumstances were needed to reproduce (and report) the bug, but I did experience it as described.

Interesting, indeed. Thanks for the heads up! I imagine something I will do good to test somewhat. Will update if I encounter any similar or other issues. I plan to test in the coming weeks.

Cheers