Using dd to backup entire raid

Good morning all!
I am looking for some assistance in backing up a set of drives that I can’t take down. I have a HP Proliant DL380 Gen7 running SUSE linux Ent Server 10 “Linux version 2.6.16.60-0.21-bigsmp”. It has 4 146 GB drives configured in some raid configuration, but I do not know what level of raid. I found instructions to copy the drive using the dd tool, but when I go to find the drive to copy, it is giving me a bunch of what I think are raid partitions instead of a drive name.

user@system:/media/$ cat /proc/partitions
major minor #blocks name
104 0 143305920 cciss/c0d0
104 1 106064 cciss/c0d0p1
104 2 2105280 cciss/c0d0p2
104 3 120115200 cciss/c0d0p3
104 4 1 cciss/c0d0p4
104 5 110144 cciss/c0d0p5
104 6 150944 cciss/c0d0p6 …etc

Is it possible to copy an entire raid to another drive using the dd tool? If not, is there another option? I’m really out of my depth here, so if there is additional information to clarify my post, please let me know.

On 06.03.2019 18:04, kobiro wrote:[color=blue]

Good morning all!
I am looking for some assistance in backing up a set of drives that I
can’t take down. I have a HP Proliant DL380 Gen7 running SUSE linux Ent
Server 10 “Linux version 2.6.16.60-0.21-bigsmp”. It has 4 146 GB drives
configured in some raid configuration, but I do not know what level of
raid. I found instructions to copy the drive using the dd tool, but
when I go to find the drive to copy, it is giving me a bunch of what I
think are raid partitions instead of a drive name.

user@system:/media/$ cat /proc/partitions
major minor #blocks name
104 0 143305920 cciss/c0d0
104 1 106064 cciss/c0d0p1
104 2 2105280 cciss/c0d0p2
104 3 120115200 cciss/c0d0p3
104 4 1 cciss/c0d0p4
104 5 110144 cciss/c0d0p5
104 6 150944 cciss/c0d0p6 …etc[/color]

That’s normal HP drive names, no (software) raid.

CU,

Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de

Hi kobiro & welcome to the forums.

I am looking for some assistance in backing up a set of drives that I can’t take down.
[…]
it is giving me a bunch of what I think are raid partitions instead of a drive name

three different issues here:

a - do you really want to backup the individual drives? Or rather the content of the RAID, which would be more usual?

By the names of the block devices, it looks like you’re running this on a hardware RAID controller, which likely won’t let you access the individual drives of that RAID set. And except for some data recovery situations, there should be no need for that, anyhow.

b - looking at your /proc/partitions, I see both, the “whole device” and the individual partitions. “c0d0” is “controller 0, raid drive 0”, with “c0d0p1”, “c0d0p2” and so on being “partition 1”, “partition 2” of that drive.

c - when it comes to backing up that data, a very important thing to consider are “caches” (application level and file system level) and consistency: When you’re using “dd” on a live block device, you do get the latest “blocks” from your device, but a file system cache (or application) may already have new content, which is just not yet written to disk. And additionally, while you’re reading your block device sequentially, new content may be written to the device not only in areas yet to be read by dd, but those you have already backed up. IOW, you end up with an inconsistent backup. Like adding new files to a directory (for example’s sake: file content written at the end of the block device, while the directory information is written in the already backed up part)

Is it possible to copy an entire raid to another drive using the dd tool?

Yes, since “a RAID” is nothing more than an ordinary block device, from the operating system’s point of view. But it may not be the most useful approach, depending on the type of data on the disk.

is there another option?

Backup up the content of a file system using i.e. “tar” would give easier access to individual files and won’t depend on a properly sized target device (think of a 400 GB block device with only a single 100 kB file on it… backup up the whole “disk” would be pretty ineffective).

And in case of a live system, you really need to pay attention to consistency issues, as described above.

Regards,
J