April 2009 Archives

From: swerdna.net.au

Here's a fairly full discussion of creating and restoring images of partitions. It covers master boot records, partition tables, partitions and drives, plus the cantankerous but excellent NTFS filesystem. You can create rescue images on DVD for restoring crashed operating systems and whole drives to factory install state. This technology is essentially a free Linux alternative to Ghost.

Rationale: Most Linux users are inquisitive; this can lead to damaged filesystems on hard drives. Windows users on the other hand don't need to do anything wrong to achieve damaged filesystems. That follows automatically from the low-security nature of Windows.

This page is really a reference list with emphasis on imaging partitions, adapted from the On Line Manual at the System Rescue CD Site.

Getting and Starting the System Rescue CD

You download the SystemRescueCD ISO file from the project download link and can then use Nero/windows or K3B/Linux to create the CD itself. When you boot your workstation off the CD, you'll be placed in a console, in the /root directory, using the Command Line Interface (CLI).

If you want to explore the functions and tools available in the Window Manager GUI, enter the command startx. Notable in there is GParted, the GUI partition manager. When you've finished exploring R-click --> Exit will take you back to the command line.

Finding Out About the Computer

Here's a summary of CLI commands you can enter to gather information about your system:

List the hard disks and their partitions (including USB drives and USB stubs)

fdisk -l (l is a letter)

List mounted partitions (including mounted CD/DVD drives)

df -Th T means "filesystem" and h means "human readable form"

List (CD/DVD)ROM drives

ls -l /dev/cd* (l is a letter)

List partition table of all disks:

sfdisk -l

Accessing Filesystems

To mount a Linux or DOS partition you first create a folder to mount it in, say /mnt/hda3, with this command:

mkdir /mnt/hda3.

Then issue the mount command for hda3 like so:

mount /dev/hda3 /mnt/hda3.

Finally, to see the files on hda3 you use this list command:

ls -l /mnt/hda3.

Mounting NTFS partitions is slightly different. Create the folder to mount it in, say /mnt/hda3, with this command:

mkdir /mnt/hda3.

Then issue the NTFS mount command for hda3 like so:

ntfs-3g /dev/hda3 /mnt/hda3.

Finally, to see the files on hda3 you use the same list command:

ls -l /mnt/hda3.

Backing Up: A topic rich with possibilities - not for the faint hearted!

In order to cover most situations encountered in the wild, assume we have a usb storage drive which is recognised as device drive sda. Assume further that we have an IDE1 drive recognised as hda1, hda2, hda3 and so on. The task is to back up the various operating system and data partitions on drive hda. You can check the partitioning of hda in your Linux console with the command fdisk -l /dev/hda. This is slightly different from the earlier usage. Here's the listing for the console session:

This result is typical of a Windows user with Windows on hda1 (NTFS filesystem), data on hda2 (NTFS again) and perhaps dabbling in Linux with an Ext3 Linux partition at hda3.

Before Running Partimage: First unmount drives that are about to be imaged or are about to be restored. Of course, you must mount storage drives where you need to access earlier images or save new images.

Backup/Restore Master Boot Record: Sometimes the rewrite of the mbr doesn't work and you have to reconstruct it with tools like Windows XP's FIXMBR tool and Linux's rewrite of the mbr from Grub or Lilo. For those advanced procedures I'd recommend the tutorials (a) HowTo Multiboot openSUSE and Windows using the GRUB bootloader and (b) HowTo Multiboot openSUSE and Windows using the Windows bootloader. Those are the fallback articles. Here are the normal steps to backup or restore the mbr:

Save the MBR from /dev/hda1 to file "backup-hda.mbr" on partition sda1:

dd if=/dev/hda of=/mnt/sda1/backup-hda.mbr count=1 bs=512

Restore the mbr from file "backup-hda.mbr" on sda1 to /dev/hda1:

dd if=/mnt/sda1/backup-hda.mbr of=/dev/hda

Backup/Restore Partition Table: The partition table contains the geometry and structre of a disk by partitions. It must faithfully reflect the structure of the actual partitions so the filesystems can be properly accessed. In practice you rarely need a copy because each time you modify a disk's partitions the partition table is (should be) rewritten to reflect the current structure.

Save the Partition Table for device hda to file "backup-hda.sf" on partition sda1:

sfdisk -d /dev/hda > /mnt/sda1/backup-hda.sf

Restore the Partition Table from file "backup-hda.sf" on sda1 to device hda:

sfdisk /dev/hda < /mnt/sda1/backup-hda.sf

Record Partition Sizes & Filesystems: You can't restore a partition image to a partition formatted for a different filesystem or that's smaller than the partition from whence it came. You can restore to a larger partition if you wish. So you see, you need to know from whence the images came. A good appplication for that is the command which lists the partition sizes and used space on mounted partitions, df -Tf, mentioned above in Finding Out About the Computer. Here's the information from df -Th for the drive being exemplified here (mount the partitions first, so their usage can be read):

To store this information on file "usage-df.txt" on partition sda1 you execute this command:

df -Th > /mnt/sda1/usage-df.txt.

To Compress or not to Compress: You've got the option with partimage to set a switch for compression to occur during the production of the image file, or not, as you prefer. The compressed file is much smaller of course, but it's produced a lot slower than the uncompressed image. It's a trade off.

To Compress or not to Compress with NTFS: NTFS partitions can be cantankerous; but mostly they're not. The Partimage Devs describe support for NTFS in Partimage as "experimental". See this linked page for the Developers' take on NTFS. I'll present two ways to image NTFS. One involves compressing the image files while they are being made. The other involves compressing them afterwards. You decide which to use. If you're alert you won't have a problem. The way I proceed with NTFS is to set up for gzip compression. If I don't get an error message early on then all is well. If the imaging aborts with an error message then I simply switch to the uncompressed method. My experience is that if the gzip switch is on with NTFS and it starts OK, then it finishes OK and restores just fine. But the decision to compress or not to compress with NTFS lies with you.

Here's the uncompressed method

You'll see compression included here - after the event of creating the image file/s. You don't have to compress the image file/s. It's an option.

Tip: don't forget to unmount the partition.

Step 1: Generate image of /dev/hda1 as file "hda1.partimg" on /mnt/sda1

partimage -z0 -d -f3 -b save /dev/hda1 /mnt/sda1/hda1.partimg

Step 2 optional: Replace file "hda1.partimg.00n" with "hda1.partimg.00n.gz" in situ, using gzip:

gzip /mnt/sda1/hda1.partimg.*

You can look up the meanings of the switches on the partimage help page. Step 1 produces a series of files with manageable size circa 2Gb. Here's a typical listing from ls -l /mnt/sda1/hda1.partimg.*:

and here's the listing after compression step 2, showing a 50% space saving. That's what makes it an attrctive option.

You can control the file size at which the split 000, 001, 002 ... occurs, although I can't see an immediate reason to do that. See the partimage help page. Also, if you have FAT on sda, be aware of file size limitations.

Here's the Compressed Method: This is much more straightforward because the compression is taken care of in the same command that makes the partition image. So there's only this one step to create a backup image:

Tip: don't forget to unmount the partition.

One step: Generate an image of /dev/hda1 as compressed file/s "hda1.partimg" on /mnt/sda1

partimage -z1 -d -f3 -b save /dev/hda1 /mnt/sda1/hda1.partimg.gz

The compressed image files that are generated from this command have names like hda1.partimg.gz.000, ..001, ..002 etc. These have slightly different name structure to the .gz files you produce for NTFS (above).

Restoring Partitions

Restoring the master boot record and the partition table were dealt with above.

Restore a Partition that was Compressed After the Event: Recall that with these images you first create the image and then optionally compress it. Well to restore the partition you first uncompress the image then write it back to the drive.

Step 1: Replace files "hda1.partimg.*.gz" with "hda1.partimg.*" in situ, using gunzip:

gunzip /mnt/sda1/hda1.partimg.*.gz

Step 2: Restore from image files /mnt/sda1/hda1.partimg.00n to /dev/hda1 with:

partimage -f3 -b restore /dev/hda1 /mnt/sda1/hda1.partimg.000

[You only need to point to .........000, the first image file.]

Restore a Partition that was Compressed During the Event: This is much more straightforward because the compression is taken care of in the same command that restores the partition. Like so:

One step: Restore from image files /mnt/sda1/hda2.partimg.gz.00n to /dev/hda2 with:

partimage -f3 -b restore /dev/hda2 /mnt/sda1/hda2.partimg.gz.000

[You only need to point to .........gz.000, the first image file.]

All this fuss about compression or no compression is basically to cater for the cantankerousness of NTFS. Remember, if you stay alert you shouldn't have a problem.

Saving Data on a Bootable DVD

You can install SystemRescueCD on about 100Mb of a DVD to make it bootable. And you can store data on the remaining space. This allows imitating Norton's Ghost rescue CD/DVD by making a DVD that contains a bootable copy of SystemRescueCD plus the image of your operating system, either Windows or Linux.

Here are the steps to make a bootable CD/DVD plus data on either a rewriteable DVD±RW or a write-once DVD±R. You can do this completely from the booted-up SystemRescueCD, using the "docache" option which causes the necessary files and filesystems to be cached to RAM. Or you can do it from an installed Linux system that has "growisofs" and "dvd+rw-tools" installed; standard packages these days. I find the latter easier. Let's also assume that you have the image file data stored in directory "imagedata" and that the ISO is stored as "systemrescuecd-x86-x.y.z.iso".

Tip: make the folder permissions for "imagedata" into drwxrwxrwx and the contained files to rwrwrw.

To find out the system name of your DVD drive, insert a CD so it mounts, then execute this:

df -Th.

Here's what I get - revealing /dev/hdc:

/dev/hdc iso9660 3.7G 3.7G 0 100% /media/SU1020.001

Follow the next two steps to make a bootable DVD±R and write data onto it:

Step 1: Make a bootable DVD containing Linux operating system (SystemRescueCD):

growisofs -Z /dev/hdc=/path_to/systemrescuecd-x86x.y.z.iso.

Step 2: Add the image folder to the bootable DVD, execute command as non-root user (remember Tip):

growisofs -M /dev/hdc -J -R /path_to/imagedata/.

But if you want to make the disk REwriteable [DVD±RW] there are two extra steps, like this:

Step 1: Make sure the RW disk is not mounted.

Step 2: Erase and initialise the unmounted DVD±RW with this command issued as root:

dvd+rw-format -force /dev/hdc.

Step 3: Make a bootable DVD containing Linux operating system (SystemRescueCD):

growisofs -Z /dev/hdc=/path_to/systemrescuecd-x86x.y.z.iso.

Step 4: Add the image folder to the bootable DVD, execute command as non-root user:

growisofs -M /dev/hdc -J -R /path_to/imagedata/.

The files copied across from folder "imagefolder" will appear in the directory /mnt/cdrom (after you boot the new DVD). So if you transferred a partition image file for an opearting system across, you have a permanent version of the Norton Ghost tyle of utility to restore your operating system after a disaster.