Tuning DD for server image

J. Epperson Dell at epperson.homelinux.net
Mon Mar 30 18:35:09 CDT 2009


On Mon, March 30, 2009 12:34, Jeff Boyce wrote:
> Greetings -
>
> I have been testing methods for making a backup image of the server for
> my small company.  I am limited to using the equipment that I have at
> hand, which consists of a single server (Dell PE 2600, RHEL3 setup as
> Samba file server with a raid5), a desktop connected to the network, and
> a portable USB hard drive.  My objective is to have a complete image of
> the entire server onto the portable USB drive (not just Samba shares)
> that can be restored onto the server with minimum additional tweaking; if
> a restoration were required.  I am preparing to complete some firmware
> upgrades soon, and would like a good image of server just in case (I have
> tape backups of data directories).  I have tried G4L and it has not been
> successful, and I am aware of Mondo, but I don't have equipment to test
> it with.  I have settled on using dd and sending it across the network to
> the portable USB hard drive mounted on the desktop.  The server has an
> old usb connection so it would take about 30 plus hours to transfer an
> image if the portable USB drive is directly connected to it.
>
> My basic usage of dd for this is  dd if=/dev/sda of=/dev/sdb bs=xxxx
> conv=noerror,sync
>
> I have tried a bs=8192 and piping it using netcat to the portable USB
> drive without success (could not see all the partitions when viewing the
> drive in GParted, nor mount anything.  Is it an inappropriate block size
> that messed up this transfer?).  I have tried not specifying a bs=xxxx
> and sent it through ssh with limited success (could see all the
> partitions, however GParted identified bad superblock errors).  I tried
> specifying a bs=512 and sending it through ssh, and this eliminated the
> superblock errors, however subsequently booting from the USB would hang
> with a kernel panic.
>
> All of these block size parameters have been suggested to me by others,
> and I am not sure how I would determine what would be the best for me in
> this situation.  I did a lot of reading on the net this weekend about
> this and could not come to any good understanding (other than it is a
> speed vs. accuracy trade off).  I am not that concerned about minor
> variations in potential speed across the network because I know that
> sending it across our network to the USB is going to be far faster than
> directly connecting the USB to the server (my estimates this weekend show
> about 6MB/sec vs. direct connection of 1MB/sec).  Can someone explain to
> me what would be a good block size parameter for me in this situation; or
> better yet, explain to me how I could understand and determine what is
> best for my situation? Thanks for any and all suggestions.

I've used g4l for several years, on 2500s through 2800s, and the only
problems I've ever had were that sometimes I've needed to try several of
the kernels to get one that supported the PERC on a given generation.  I
believe .17 through about .20 will work on a 2600, perhaps later ones as
well. It's my production imaging solution for a full stable of Poweredges.
 Whenever we go to a new RHEL/platform combination, I do a base RHEL
install on one machine, work out the driver and multipath issues and image
the others from it.

What problems did you have?  Mike Setzer, the maintainer, is _very_
responsive.  BTW, I've imaged machines that won't boot g4l, like my wife's
old Mac Powerbook, by booting a processor specific live cd (Knoppic
Powerpc in that instance), NFS mounting the filesystem I want to write to,
and doing a straight
dd if=/dev/sda|lzop > /mnt/image.lzo
But you can't readily mount the compressed disk image if that's a
requirement.




More information about the Linux-PowerEdge mailing list