Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have some servers that run in very harsh environments (research vessel) that need to have high-availability.

We have software RAID 1 for some measure of resiliency, along with proper data backups (tapes etc), however we would like to be able to break out a new server and re-image it (including RAID setup) from a known good copy if the hardware completely fails on the production box. Simplicity of the process is a big plus.

I am interested in any advice on the best way to approach this. My current approach (relatively new to Linux administration, totally new to MDADM) is to use DD to take a complete gzipped copy of one of the RAID'ed devices (from a live CD): dd if=/dev/sda bs=4096 | gzip -c > /mnt/external/image/test.img then reverse the process on the new PC, finally using mdadm --assemble to re-create and re-build the array.

I'm not sure that this is the best approach, or if it will even work. Any advice would be great.

share|improve this question
add comment

3 Answers

up vote 2 down vote accepted

Your dd-based (block level) copy will include all the free space on the disk, won't take advantage of larger disks down the road, and won't fit onto smaller disks (in a pinch).

Rather than doing the cloning at the block level I'd do it at the filesystem level.

I'd boot the new server from the live CD, partition the disks, create the new MD array(s), format the arrays, run mkswap on any swap volumes, then untar (or un-cpio, if you prefer) file-level copies of each of the source server's volumes into each of the new arrays. Finally I'd install the boot-loader. Then you're golden.

All of that could be scripted and rolled onto a live CD/DVD image along with the filesystem archive(s) to untar.

share|improve this answer
    
Because you're running gzip that should take care of the empty space, but along the same lines you'll also pick up any non-zero blocks that are on the disk but not part of your current filesystem (deleted files, remnants of previous filesystems etc). +1 for a comprehensive answer. –  Frenchie Oct 28 '10 at 0:50
    
@Frenchie: Yep. dd isn't aware of the filesystem (and it doesn't know what's free and what isn't) and will happily return whatever is there (old file fragments, etc). Unless you specifically zero-out the free space there are almost assuredly not zeros in the free space. –  Evan Anderson Oct 28 '10 at 0:52
    
Thanks for the answers. I'm running <code> dd if=/dev/zero of=/mnt/sda6/tmp/delete.me </code> to zero the free space which hopefully, combined with gzip, will result in manageable image files. @Evan - thanks for pointing out the limitations of dd. If I did end up using dd to re-image a drive in the recovery PC, would something like <code>mdadm --assemble --scan</code> be enough to rebuild the array and get a runnable system? –  Caligari Oct 28 '10 at 1:13
    
Also, a smarter tool will only read the portions of the drive you use. If your drives are reasonably empty (30-60% full), you could cut the time required to read the original by a significant fraction over dd, which has to read the entire original (disk bandwidth is not limitless) –  Slartibartfast Oct 28 '10 at 6:08
add comment

Traditionally, dump and restore are programs that intimately know the filesystem structure and can efficiently write out and load the minimal needed to save and restore the filesystem.

On Linux, the commands dump and restore (sometimes named e2dump and e2restore) work for ext2/3/4. xfsdump and xfsrestore are the analogues for XFS.

Of course, you can use filesystem-independent tools such as tar or cpio or rsync. Your dd method wins on simplicity of use, since you don't have to set up the partitions or filesystems or bootloader at all, but may cause problems if your disks are not all identical.

share|improve this answer
add comment

In line with Evan's answer, if you want a more traditional image that you can mount and use as a read only reference filesystem, I would suggest you have a look into taking a SquashFS image of your source volume.

For deployment, you mount your image and then use the your file level copy of choice (rsync, tar/untar or cpio are all reasonable). Using your current method is also fine for a quick and dirty image, but as Evan has pointed out takes a way quite a bit of your flexibility.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.