Tuning DD for server image

Jeff Boyce jboyce at meridianenv.com
Mon Mar 30 16:22:42 CDT 2009

----- Original Message ----- 
From: "Flaherty, Patrick" <pflaherty at wsi.com>
To: "Jeff Boyce" <jboyce at meridianenv.com>; <linux-poweredge at dell.com>
Sent: Monday, March 30, 2009 2:11 PM
Subject: RE: Tuning DD for server image

> 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.


You're going to have a lot of trouble block copying a mounted drive. The
blocks will keep changing as your dd goes on, and the filesystem will
end up being corrupted. The only way you could do that easily would be
if your RHEL3 install was on a logical volume you could snapshot (see

If there aren't any other services on this machine, and if samaba is the
RHEL default, I'd just tar up the /etc directory, get the output of
ifconfig, route -n, dmesg, and rpm -qa. That would give you a chance to
reinstall quickly if there's an issue.

You're other option would be backing up the mbr with a dd, and dumping a
tar of each filesystem onto the usb drive or over the network.

Good Luck,

Patrick -
I did  not include all the details of what I am doing, but yes I am doing 
this using unmounted drives as I reboot the server using a Linux LiveCD.  My 
server disk arrangement was built without using LVM (not something I would 
do now), so snapshots are not an option.  There are other services and 
systems using this box (OpenVPN, APCUPSD, NTP, etc.) and that is why I do 
not want to go through the process of re-installing and reconfiguring 
everything.  Thanks.

More information about the Linux-PowerEdge mailing list