Notifications
Clear all

RAID 5  

Page 1 / 2
  RSS
ClarkK
(@clarkk)
New Member

What is the best way to image a server with RAID 5 config? Or if best way is not possible, other options?

Quote
Posted : 11/04/2019 6:14 pm
mcman
(@mcman)
Active Member

Personally, I hate rebuilding RAIDs so I always vote for logical acquisitions while it's mounted but that would depend on your case and the amount of data you need to grab.

Grabbing each drive and rebuilding back in the lab is fine, I just prefer the logical if/when possible.

ReplyQuote
Posted : 11/04/2019 6:20 pm
ClarkK
(@clarkk)
New Member

I guess that's sort of my question…how do you rebuild a RAID 5 from outside of the server? Never have had to in the past. Obviously a logical would seem to be much easier. What tool(s) do you use to rebuild, how long does it take, etc?

ReplyQuote
Posted : 11/04/2019 7:36 pm
minime2k9
(@minime2k9)
Active Member

X-Ways Forensics does a good job of rebuilding RAID systems and then lets you create an image file of the rebuilt RAID to stop you having to rebuild it in the future.

ReplyQuote
Posted : 11/04/2019 8:34 pm
athulin
(@athulin)
Community Legend

What is the best way to image a server with RAID 5 config? Or if best way is not possible, other options?

Define 'best'. What attributes are you hoping to maximize?

In general you have no choice the server is usually business critical, and taking it off line for more that the bare minimum of time is going to lead to economic damage.

If you don't have that problem

I would start with an image of the data stream produced by the RAID device. Not the individual disks, but the 'emulated' disk, as far as one is present. This is, usually, the image the RAID unit exhibits to its host system or any surrounding system, and that should be the starting point. (Just as the 'disk' an ATA device exhibits to its host usually is less than what it keeps 'inside', so to speak.)

If you image indvidual disks, you are faced with the technical possibility that your rebuild may not be the same as the RAID's rebuild, so to speak. If you have the time, by all means … but one of the things you do in this situation probably have to be to compare the 'logical image' (I don't like that term) with an image rebuilt from the individual drive images. If there are discrepancies anywhere, you have to evaluate them.

That is, basically, you have to validate that your rebuild methodology actually does produce the same result as the RAID system itself.
If you know the RAID well (as is often the case for standard soft RAID systems), you can reduce the need for this – and if the RAID implementation is the same, possibly eliminate it altogether.

But in the general case, where you may have a proprietary, HW-based RAID that you don't know a thing about, it seems foolish to go directly for the more difficult option, as this will – in all situations I can think of – be on the critical path of the job, and so add delays.

ReplyQuote
Posted : 12/04/2019 6:24 am
Bunnysniper
(@bunnysniper)
Active Member

What is the best way to image a server with RAID 5 config?

The "best" way….? Hmmm. Rebuilding a RAID5 from physical discs can be a real pain, so I prefer taking images of the running operating system with FTK Imager. Assuming it is a hardware RAID, the 2nd possibility is to boot from USB/ DVD and start the copy from there.

regards,
Robin

ReplyQuote
Posted : 12/04/2019 12:11 pm
ClarkK
(@clarkk)
New Member

Well, I suppose best in the case would be defined as least messiest. Sounds like imaging online would be just that. If a rebuild of individual drives has to occur then it would seem to me that you don't know if you did in fact get everything. Our scenario would be that the servers reside somewhere else and the drives are shipped in to us. That seems to make things a little trickier.

ReplyQuote
Posted : 12/04/2019 12:16 pm
jaclaz
(@jaclaz)
Community Legend

If a rebuild of individual drives has to occur then it would seem to me that you don't know if you did in fact get everything.

No, it is slightly different.

If you have the images of all the (single) physical disk drives you have *everything* and you can always re-build the whole array as it was (but this rebuild may take some time/effort).

If you image the disk array (as "exposed" by the RAID hardware/software) you have the thing as the server/os/whatever could see it, but not necessarily *everything* (it may depend also on the specific RAID hardware/software).

The note by athulin is more about the possibility (IMHO rare but not impossible in theory) that when you rebuild the array what is exposed is not exactly the same as what was exposed on the original machine.

Not necessarily the fastest/easiest but imaging BOTH the array as exposed AND the single drives would allow you to have the "as exposed" image to analyze and - in case of need - the possibility to rebuild from the single disks, and surely complies with *evrything* saving you from any possible critics.

It really depends on the nature of investigation and other "external" factors (that only you can know), as an example you (your organization) may have a policy that imposes 11 forensic copies of disks without exception for RAID arrays.

jaclaz

I

ReplyQuote
Posted : 12/04/2019 1:10 pm
ClarkK
(@clarkk)
New Member

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?

ReplyQuote
Posted : 12/04/2019 2:10 pm
DCS1094
(@dcs1094)
Active Member

You could do a live boot with WinFE boot disk and image via FTK Imager or X-Ways. Alternatively, you could use X-Ways to reconstruct the image files, if you have just been given the physical disks. I've also used UFS Explorer RAID Recovery in the past to assist with the identification/structure of the RAID and also reconstruction of the emulated drive. I had to do this when I was just given the physical HDD's with little to no information. They were stacked together and had been in storage.

ReplyQuote
Posted : 12/04/2019 5:17 pm
jaclaz
(@jaclaz)
Community Legend

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

ReplyQuote
Posted : 12/04/2019 7:33 pm
UnallocatedClusters
(@unallocatedclusters)
Senior Member

Also potentially relevant

https://www.osforensics.com/rebuild-raid.html

ReplyQuote
Posted : 12/04/2019 10:32 pm
athulin
(@athulin)
Community Legend

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.

ReplyQuote
Posted : 13/04/2019 6:22 am
jaclaz
(@jaclaz)
Community Legend

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

ReplyQuote
Posted : 13/04/2019 12:10 pm
PensiveHike
(@pensivehike)
New Member

When I've had disks with no information of order etc., after imaging them, I've used this software to determine disk order and block size.

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.

ReplyQuote
Posted : 13/04/2019 1:55 pm
Page 1 / 2
Share: