I see. Well in our instance, the most likely scenario is that they would want to send us the individual disks. So we would not have the RAID controller. In this example, what tool(s) could be used to rebuild?
A few
X-ways
Runtime RAID Reconstructor
Dmde
see also here
http//www.forensicfocus.com/Forums/viewtopic/t=10741/
https://www.forensicfocus.com/Forums/viewtopic/t=13990/
https://www.forensicfocus.com/Forums/viewtopic/t=16705/
The more info you get about the current configuration of the array, the easier will be to re-build it, there are usually no particular problems in "guessing" (actually discovering) the parameters, but directly providing the correct settings is obviously easier/faster.
As well, marking/numbering the disks i.e. disk 1, 2, 3, 4 as they are physically in the current server/case - say - from top to bottom will help.
jaclaz
Also potentially relevant
https://
As well, marking/numbering the disks i.e. disk 1, 2, 3, 4 as they are physically in the current server/case - say - from top to bottom will help.
If no information from a HW RAID controller is available, that may not matter very much.
However, if the HW configuration is available, and needs to be relied on (for instance if a similar controller will be used for imaging), the connection between what the controller calls the disks, and the actual disks themselves should be documented.
Documenting rack order assumes that that order corresponds to disk ports. If the person who installed the stuff is reasonably experienced, it usually does. But it some case, he wasn't and it doesn't, and in those cases the risk for confusion is fairly high.
(imaging a RAID should really be a kind of follow-up class to basic imaging, particularly for people who never have installed or worked with HW RAID units.)
Confusion may enter normal cases as well if BIOS/EFI boots from disk port instead of disk ID, it may become important to document what HDD was connected to what port. At the very least, it becomes important if and when the disks are restored to the rack.
As well, marking/numbering the disks i.e. disk 1, 2, 3, 4 as they are physically in the current server/case - say - from top to bottom will help.
If no information from a HW RAID controller is available, that may not matter very much.
However, if the HW configuration is available, and needs to be relied on (for instance if a similar controller will be used for imaging), the connection between what the controller calls the disks, and the actual disks themselves should be documented.
Documenting rack order assumes that that order corresponds to disk ports. If the person who installed the stuff is reasonably experienced, it usually does. But it some case, he wasn't and it doesn't, and in those cases the risk for confusion is fairly high.
(imaging a RAID should really be a kind of follow-up class to basic imaging, particularly for people who never have installed or worked with HW RAID units.)
Confusion may enter normal cases as well if BIOS/EFI boots from disk port instead of disk ID, it may become important to document what HDD was connected to what port. At the very least, it becomes important if and when the disks are restored to the rack.
Sure, everything is possible, but most of the time the disks are on trays with the top one being #1 and in order, they are assembled in factory like that.
And this same rule of the thumb is normally used when putting together a RAID DIY.
Of course if an incompetent (or crazy, or both) engineer has assembled himself/herself the server or has modified its internal connections, everything is possible.
And in any case, I would prefer to have a clear indication marked on the devices of which disk was which on the original hardware over a bunch of unmarked disks.
This said, we are talking of a RAID 5 made with 4 disks, it is not brain surgery or rocket science, you can blindy try all the remaining possible 23 combinations for drive order if "plain" 1-2-3-4 is doesn't work
https://www.forensicfocus.com/Forums/viewtopic/p=6594761/#6594761
Assuming that the RAID parameters are correct, that will take no more than 3 or 4 minutes each, or a couple of hours in the worst possible case.
(and they are really-really NOT 24 possibilities as the first disk can be identified by the presence of the MBR or of the GPT protective one+GPT partition tables), so there remains 6 of them
1234
1243
1324
1342
1423
1432
jaclaz
When I've had disks with no information of order etc., after imaging them, I've used
I'd then rebuild the RAID using X-Ways or Encase. To determine Stripe size you need to find a picture of 2MB or so and see if it displays correctly. If not, change the stripe size and check again.
Sure, everything is possible, but most of the time the disks are on trays with the top one being #1 and in order, they are assembled in factory like that.
Forensic collection and analysis should be done regardless of if a system has been built to some preconceived standard or not. It should be done for the system at hand. Saying that it's probably standard, so we skip point 18, 19 and 20 in our SOPs for imaging raid without even verifying that we can, is … well, like basing expert evidence in a murder case based on presumptive blood testing, but skipping confirmatory testing. (That is, you have not ensured that the risk for false positives are at an acceptable level. Yes, there are such cases out there.)
I've seen a factory delivered system get raid installation totally 'wrong'. That caused a big headache, as we were responsible for it being right … and we assumed the factory would get it right. But when they didn't – and they didn't even install the switch-over power supply and protection that we had ordered – (again, we assumed we got a correct delivery) and bad things happened to the power, and indirectly took down a disk or two … we were in the hot seat.
Forensic analysis should not begin with the assumption that everything is according to the book. The job is to get it done, no matter how non-sane or nondefault the setup is, and to do it in a way that is forensically sound. If it's not done correctly, there is damage done to the case by the investigation itself. That damage has to be documented. Basically, you have to say 'we skipped a few steps in best practice acquiry, because we really couldn't be bothered' in the report.
That's not acceptable, in my opinion. It may be acceptable in DFIR case. I no longer think of DFIR as any kind of 'forensic analysis'.
This said, we are talking of a RAID 5 made with 4 disks, it is not brain surgery or rocket science, you can blindy try all the remaining possible 23 combinations for drive order if "plain" 1-2-3-4 is doesn't work
Provided that … well, you should be able to fill in the blanks. You have to ensure two, perhaps three things, before you 'blindly try' anything at all in this situation with any hope of being able to interpret the results.
Or … you document that 'we just blindly tried everything, until it worked, and continued from there'.
I've seen a factory delivered system get raid installation totally 'wrong'. That caused a big headache, as we were responsible for it being right … and we assumed the factory would get it right. But when they didn't – and they didn't even install the switch-over power supply and protection that we had ordered – (again, we assumed we got a correct delivery) and bad things happened to the power, and indirectly took down a disk or two … we were in the hot seat.
Yes, anecdotally they once delivered a server to a data center that was cabled in factory for 110 V AC instead of 220/240, the switching power supply took fire, the fire alarm was down for maintenance, the fire blew off a window left open and went out setting of fire the tarpaulin of a passing by truck, which set on fire all the trees along the road for 1 km, and of course it extended to the bush and woods nearby …
Come on ) , we are talking of a set of 4 (read only) images, everything becomes "virtual" once the images are acquired, you can juggle them every which way you can without making any damage until you find the right settings to mount them as the RAID 5 array they once were.
jaclaz
Personally, I hate rebuilding RAIDs
You can always outsource this part to a data recovery pro to handle remotely. I love rebuilding RAIDs, it's one of my favorite tasks in data recovery. But, maybe I just enjoy the challenge.
Come on ) , we are talking of a set of 4 (read only) images, everything becomes "virtual" once the images are acquired, you can juggle them every which way you can without making any damage until you find the right settings to mount them as the RAID 5 array they once were.
No, we're talking of HDDs (or images), without any information about the RAID controller and configuration, and where assumptions about what port they were connected to are incorrect. (That's what my previous example ended up in we had a huge problem matching disks because were assumed that the ports were sequential, and in an 'obvious' order. But the RAID insisted on 'right-disk-on-right port' and refused to work if it didn't. Consider the problems that would lead to if you or a forensich tech had to restore the RAID to working condition if you assume that you know what you're doing.)
We're talking HDDs that aren't verified to belong to the same setup. (Unless you're have the same soft RAID implementation, that performs this check, and screams if it fails. If so, exit here. Congratulations you're doing the right thing.) Shouldn't happen, yet it does. Any half-decent forensic analyst should be able to detect the fact, and stop racking up analysis hours for something that probably is going to be useless. ]
We're talking 'blind' rebuild of HDD's that may have not been verified to be one RAID.
We're talking about a RAID whose health is unknown is it 'OK', that is, is it known that there are no internal inconsistencies. Or is it a RAID, when HDDs are connected to its 'home controller' (hard or soft), screams 'RED state inconsistent'. If you don't check it … you are obliged to document that you didn't check.
And we're very probably also talking rebuild without validation of behaviour with foreign disks. What does the tool do with an assumed 5-disk RAID, where disk 5 doesn't belong at all? And how does that affect work? (In particular, does anything from the foreign disk risk ending up in the result? )
It's not a question of muddling through, thinking that 'oh, well, it works in 95% of the cases'. It's a matter of being able to identify if the setup at hand is one of those 95% cases, where your testimony cannot be shown to be correct due to all unsubstantiated assumptions you've been working from.
Remember, everything should be possible to repeat.
RAID is a chapter of its own.
o+o/
No, we're talking of HDDs (or images), without any information about the RAID controller and configuration, and where assumptions about what port they were connected to are incorrect.
Well, then we are talking of different things.
I was talking of hard disk images ONLY and how to virtually rebuild an array out of them.
Numbering the physical disk drives from #0 or #1 from top to bottom and numbering the images in the same way helps (and no it is not the ONLY solution for EVERY issue that can be imagined when working with RAID disks and their images , but it helps).
Please re-read what I actually originally wrote
The more info you get about the current configuration of the array, the easier will be to re-build it, there are usually no particular problems in "guessing" (actually discovering) the parameters, but directly providing the correct settings is obviously easier/faster.
As well, marking/numbering the disks i.e. disk 1, 2, 3, 4 as they are physically in the current server/case - say - from top to bottom will help.
before you started with the "If no information …", and now we are into "HDDs that aren't verified to belong to the same setup" …
And still you can make ANY kind of experiment with (mounted read only) images, without any "damage" to the case, basically when (IF) you will have them mounted in the right order and with the right parameters you will be able to read the contents, otherwise you won't, so you could even use a brute force (or infinite monkeys) approach.
jaclaz