Imaging a Server

[agent007]

Guys,

I need to create an image of a server running RedHat 7.2. There are 3 ext3 partitions & 1 FAT32 partition. The destination will be a HDD (slave). I plan to use Knoppix 3.3

Q1) What would be the best way to image the server?

Q2) Should the destination HDD be formatted/partitioned inorder to match the partitions on the server?


TIA

[Void Main]

I have always just used "dd" in the past but I believe Knoppix has a nice utility specifically for that and works similar to ghost. I'll have to do some searching but if both drives are in the same machine then "dd" works very well. I just create the partitions on the new drive as big or bigger than on the old drive and do a "dd if=/dev/hda1 of=/dev/hdb1" to make an exact duplicate of the file system on hda1 on hdb1. Optionally replace "of=/dev/hdb1" with "of=/somedir/somefile.img" to dump the file system to an image.

Having said that I don't find it necessary to "image" a Linux server, unlike Windows machines. I much prefer to back up my Linux servers and if I want to build on a new machine I do a fresh install since it only takes like 30 minutes on a fast server. Most all configuration is under /etc and user data is usually no more than /home, and you might also want something like /var/www. Of course I also do regular database dumps so they can be restored from backup. But having said that I can think of some occasions where someone might prefer doing an image. I just don't personally run into them.

[agent007]

Void Main,

Yes, the 2nd HDD will be on the same system. So what ur saying is, I have to create 3 ext3 partitions + 1 FAT 32 partition on the destination HDD correct? Also, do they need to be formatted? What would happen if they are not formatted?

thanks..

PS: will explain later, the reason for the imaging...

I have always just used "dd" in the past but I believe Knoppix has a nice utility specifically for that and works similar to ghost. I'll have to do some searching but if both drives are in the same machine then "dd" works very well. I just create the partitions on the new drive as big or bigger than on the old drive and do a "dd if=/dev/hda1 of=/dev/hdb1" to make an exact duplicate of the file system on hda1 on hdb1. Optionally replace "of=/dev/hdb1" with "of=/somedir/somefile.img" to dump the file system to an image.

[Void Main]

No, they do not need to be formated, you will be placing the formatted file system with data on the partition you create. The dd command does a sector by sector copy of the entire file system whether there is anything on it or not, but the format itself is within the file system as when you do a format all you are doing is creating a blank file system. Just be very positive that you have created the new empty partition large enough to hold the file system you are copying over with dd (this includes the free space on the source file system). That is look at the size of your original partition and make the new one at least that big.

EDIT: The image utility I was referring to is called GNU PartImage and I believe it's included with Knoppix:

http://www.partimage.org/screenshots.en.html

I'm sure it doesn't really do much more than a "dd if=/dev/hda1 | gzip > /somewhere/image.gz" though. But it does have a nice menuing system if you feel more comfortable with that. It will also save an MBR (you can also do that with dd).

[agent007]

So, what I'll do is create the partitions on the empty disk. Use dd to copy the
partitions since partimage compresses it into an image which I dont need. The imaged HDD needs to be used immdediately after the process.

Btw, how do I copy the MBR using dd? Its located at hda...

thanks..

[Void Main]

For the MBR copy here is a link. Note that when backing up the MBR you can back up all 512 bytes but when you want to install a backed up MBR you do not want to write all 512 bytes. This is very important. Use "bs=446 count=1" when writing the MBR from a backup MBR file. There is also a Linux utility that will save/restore the MBR (again, don't remember that off the top of my head but a search should find it) but dd does the same thing.

Also, if the drives are identical (must be identical in every way in my experiece, make/model/cylinders, etc) you should be able to duplicate the entire drive including MBR by "dd if=/dev/hda of=/dev/hdb". On unlike drives I have good success doing it partition by partition.

I aslo assume this drive will be taken to another machine and used as a primary. If it's not, and will be used as a secondary drive and booted from you'll need to mount the root partition from your second drive and change the "fstab" to reflect the new device names (hdax->hdbx).

[agent007]

Well, I just tried out a small experiment...

Source Disk

/dev/hda1
Size: 5.9G
Used: 122MB

I created a partition on the destination having the same size and did a dd

/dev/hdc1
Size: 5.9G

dd if=/dev/hda1 of=/dev/hdc1

dd: writing to /dev/hdc1: No space left on device
1751085+0 records in
1751084+0 records out

896555008 bytes transferred in 404.931318 sec

Does this mean that the image was copied correctly? There is still a lot of free space on the hdc1...so why did it say 'no space'?

TIA
~

[Void Main]

That means you did not create the destination partition large enough. The amount of free space has nothing to do with anything on the source file system. It's the "total" size of the file system that you need to be concerned with. The free space in that file system is still part of the file system and will be copied along with occupied space. dd doesn't know anything about what it is copying, it just does it block by block. If you only want to copy the data then you need to preallocate a file system on the destination partition and use a higher level tool like "tar", "cpio", or "cp". You have to account for different physical properties of each drive which may mean that the destination partition has to be created larger than the source partition.

Just as a test try creating the destination partition about 10% larger than the source partition and see if the copy is successful. You can always resize the file system after the copy so it takes up the entire partition size using the resize2fs command. Or you can leave that gap between the end of the file system and end of partition unused (I always resize to make use of every last byte). I don't know how to figure out exactly what size destination partition is needed but I am sure there is some forumula that you can use based on cylinders/heads/tracks/sectors, etc, etc. Just guessing on that. But no, if it is successful you should get no messages at all. Before you change anything could I see a copy of your partition tables?

Code: Select all

# fdisk -l /dev/hda
# fdisk -l /dev/hdc


[agent007]

Well, VoidMain , u were right about everything...I created the partitions bigger than the source and dd worked perfectly...The 20gig partition took very long though, cause as u mentioned dd copies the free space too. In this case it was 15GB of free space!

I backed up the MBR & restored the 446 bytes but LILO did not work, so Knoppix came to the rescue..I chmounted the imaged r00t partition and re-ran LILO. Worked fine!

I guess it would be a big time-saver if the partitions were gzipped & untarred....

[Void Main]

Actually a big time saver can be using an optimal block size param in your "dd" command. I am usually lazy and just let it take however long it takes without the optimal "bs=" flag though.

[agent007]

Void,

Do u create the image from Fedora? Wont that create a prob if the r00t filesystem is in use? I heard that one has to reboot the system and create backups using Knoppix or some other live-distro.....

[Void Main]

If I actually were to do it (I haven't had the need to copy an image of a partition for quite some time) then you could just boot from the Fedora CD in rescue mode. Of course you could also use Knoppix etc. This is only necessary if you are copying the root file system. I suppose you could also bring your system down into single user mode and do it (init 1) after running the "sync" command a couple of times. Even better if you opt for that is to remount your root file system read-only until after the "dd" finishes and then remount it back to read-write ("mount / -o remount,ro").

[agent007]

And what would happen if the image of the r00t file system was created when in Fedora? Would the backup be corrupt or something?

[Void Main]

And what would happen if the image of the r00t file system was created when in Fedora? Would the backup be corrupt or something?

You can actually do this. In fact I have done it on the server that this site is running on because I didn't want to bring down the server. You can look at my mounted file systems in the sysinfo() link on the front page. I originally was planning on mirroring a couple of my partitions because I don't trust the hda drive. It's wigged out a couple of times.

You would want as little activity going on as possible though and there will surely be a write or two to something (log files etc) so before you mount the new image you would want to do an "fsck" on it. In fact you could probably run an "fsck" directly on the image file iteself and repair it. In fact you could even mount the image file as if it were already written to a parition to look it over (mount imagefile.dat /mnt/somewhere -o loop). By first unmounting the device you are imaging none of this is necessary and you shouldn't have to worry about any kind of corruption, which is why it's recommended.