[ale] Linux has been cloned, by me
Ron Frazier
atllinuxenthinfo at c3energy.com
Mon Feb 21 17:35:37 EST 2011
This is sort of a followup to a message on 01/20/11 with the subject of:
fun fun changing Linux swap partition to a swap file. However, the
focus has shifted, so I changed the subject line. I'll describe what
I've been doing, then reply to a few items from the prior post.
I have been desiring to have a more efficient backup system. I have
always preferred full drive imaging. If my HDD dies, I don't want to
have to spend days reinstalling things, copying things, and configuring
things. I just want to restore the backup and be back in business. In
the past, I've used Acronis TrueImage to make an image of the HDD and
put it into a big binary blob. Making the image takes about 3-4 hours
using an external USB drive. Restoring it after a failure takes a
similar amount of time. You can do this using the boot CD provided with
the product. I like the fact that the program has a friendly GUI
interface, even on the boot CD. I have described the reasons for this
in other posts.
Not too long ago, I started hearing about some backup programs that
create a bootable backup, so you can just take the backup drive and boot
from it and use it. This way, you don't have to find the restore CD and
wait 4 hours to restore from the blob. Also, you don't have to be
running the restore program or it's driver to access individual files
from the blob. This is very appealing to me.
I am currently using Acronis TrueImage 11, which is a couple of years
old. It does not make bootable backups in terms of it's feature set.
However, I figured I could use its clone disk function to do the same thing.
My laptop uses a 2.5" 500 GB SATA drive, so I got another one the same
size and put it into a USB enclosure. I am still using Acronis. I
couldn't locate any freely available Linux program with similar
features. I tried to clone to the new drive and the system complained
that there wasn't enough space on the destination. Apparently, there
was 12 MB of size difference between two Seagate 500 GB SATA drives. I
solved the problem by shrinking the last partition on all my computers
by 2077 MB or about 2 GB. This is an arbitrary number. This insures
that the drive I'm backing up is always smaller than the one I'm cloning to.
I will relate the procedure I used below. But first, here's what
happened the last time I tried this.
Originally, my hard drive was arranged as follows:
MBR structure
Partition 1 - NTFS - Windows Vista
Partition 2 - EXT4 - Linux
Partition 3 - SWAP - Linux Swap
Partition 4 - NTFS - Shared Data
The system dual boots. Rather than use GRUB as the primary boot
manager, I use the Windows NT Loader. This allows me to have easy
access to the diagnostic options in the NT loader. I set this up using
a program called EasyBCD from Neosmart Technologies. (
http://neosmart.net/dl.php?id=1 ) I have no idea how it works, only
that it does. When I installed Ubuntu, I manually told it to put GRUB
on the Linux partition, not on the boot partition. When I boot, I get
the Windows boot loader screen. It has Windows Vista and Ubuntu on it
as options. If I select Ubuntu, then GRUB appears and I boot Linux as
normal.
When I first started the first thread a month ago, I had cloned the hard
drive with Acronis TrueImage. I installed the backup drive and booted
it. Windows booted just fine and worked normally. Linux would boot
fine and appeared to be working normally. However, as I was using it, I
found that the swap had been deactivated and that the hibernate function
also had been deactivated since it requires swap. Also, once during an
update, the GRUB updater program complained about not being able to find
itself and I had to tell it which /dev/sd? to put itself on.
This swap issue precipitated my transition from a swap partition to a
swap file. That turned out to be somewhat challenging, but I got it
done. The disk structure is now as follows:
MBR structure
Partition 1 - NTFS - Windows Vista
Partition 2 - EXT4 - Linux (Extended to fill prior swap space.)
Partition 3 - NTFS - Shared Data
Just yesterday, I did the first backup, by cloning, since the transition
to using a swap file. I know, should have done so sooner. I am happy
to report 100% success, although I suspect the GRUB update problem may
still exist. I attached the spare drive to a USB port, booted the
Acronis CD and told it to clone my main drive to the USB drive. Then, I
shut down the PC and removed the main drive and installed the backup
drive. I booted into Windows and went on working as though nothing had
happened. This took all of 5 minutes, most of which was waiting for
Windows to start up. The physical swapping of the drives took 2 minutes
or less. I rebooted into Linux and, again, EVERYTHING worked just like
it did on the main drive. The swap file was there and active, and the
hibernate option is there on the shutdown menu, although I may not use
it (see below).
I REALLY like this method above and beyond the save to a blob method, or
the just save the data and reinstall method. I can now recover from a
drive failure in 5 minutes, and continue working exactly as I was on the
day the backup was done. I have data backups every 6 hours using
Jungledisk going to Amazon S3 servers. So, after I restore any new
data, and install any new apps since the backup, I'm back exactly the
way I was at the time of the failure. This is much easier for me than
reinstalling the whole system or restoring from a blob, and much
faster. I have two backup drives for one PC and one backup drive for
each of all the other PC's. I hope to add redundancy as soon as my
budget allows it.
Here's the exact procedure I use to clone the drive. (Newer versions of
Acronis TrueImage may differ.)
* Open the CD drive and insert Acronis TrueImage boot disc.
* Shut down the system.
* The backup drive is in a USB enclosure. Connect to a USB port.
* Boot the system to the CD drive and run Acronis TrueImage.
* Select the Clone Disk function.
* Click Next.
* Select the MANUAL method of operation, then next.
* Select the source drive. This varies by computer, but on my laptop,
it is Disk 1, and claims to be on a SCSI interface (it's really SATA).
* Select the target drive. This varies by computer, but on my laptop,
it is Disk 2, and is on the USB interface.
* Acronis complains that there are partitions on the destination drive
(which will be the case if you've used it before). Tell it to delete them.
* Acronis asks if you want to keep your old data on the source drive.
Tell it to keep it.
* Select the AS IS method to copy the partitions, so the system will not
attempt to resize them.
* Wait 30 seconds - 1 minute. Acronis presents a graphical map of what
is to be done.
* Review the map, and click next.
* Acronis presents a text description of what is to be done.
* Review this. Make SURE the source and destination drives are correct,
as the destination WILL BE ERASED.
* Once you're happy with it, click proceed.
* Go do something else for 4 hours. Hopefully, when you return, it will
say the operation is successful.
* Click OK to acknowledge the message. DO NOT shut down the PC or
remove the backup drive. You will be returned to the main Acronis
screen. Click the X in the corner to exit it. The PC will reboot.
Once you get back to your normal boot menu, and everything is dormant,
hit the up or down arrow to stop the boot timer. You can either boot
normally or shut down. You can remove the CD from the drive.
To test the backup drive, shut down the PC. Remove the main drive.
Install the backup drive in it's place. Boot on the backup drive. You
should be able to work completely normally. Shut down again, remove the
backup drive, and put the main drive back in. Store the backup drive in
a safe place.
Note, if you use a password to lock your HDD, which is activated through
the BIOS, as I do, that password will not exist on your backup drive, as
you wouldn't be able to access it in the USB enclosure if it had a
password on it. Therefore, if you have to install the backup drive
permanently, you will have to go into your BIOS and add the password to
the HDD for permanent use. It will work fine without the password, but
if it's stolen, the thief can easily read the drive. This option is
more common on laptops.
As it turns out, you really have to think about which drives you're
accessing and make sure you specify them correctly. Otherwise, you
could erase your main drive by cloning an OLD backup to your main drive
instead of the other way around. Because of this, I'm not recommending
this strategy to my Dad unless I can walk him through the procedure or
share his screen.
Here's what the source and destination hard drive settings look like on
my various PC's, the point being that you may see a variety of options
depending on how your PC is configured. Acronis will display the model
number of the drive, which is helpful to determine what you're doing.
You CANNOT always assume you're cloning from Disk 1 to Disk 2. You will
have to determine what the specific configuration is for your computer.
PC1 - Backup drive attached to USB port.
- Source - Disk 1 - SCSI interface (actually it's SATA)
- Destination - Disk 2 - USB interface
PC1 - Alternate. Backup drive attached to USB port, but it's the 1st of
2 drives in the enclosure.
- Source - Disk 1 - SCSI interface (actually it's SATA)
- Destination - Disk 2 - USB interface (Got lucky. The drive
I want is the 1st in the enclosure.)
PC2 - Backup drive attached to FIREWIRE port.
- Source - Disk 2 - IDE interface (actually it's PATA) (YES!
The source is DISK 2!) (This can easily make you insane.)
- Destination - Disk 1 - SCSI interface (actually it's
FIREWIRE) (YES! The destination is DISK 1! Apparently BIOS sees it first.)
PC3 - Backup drive attached to USB port, but it's the 2nd of 2 drives in
the enclosure.
- Source - Disk 1 - SCSI interface (actually it's SATA)
- Destination - Disk 5 - USB interface (Disks 2 and 3 are
internal. Disk 4 is the 1st in the USB enclosure. Disk 5 is the 2nd in
the USB enclosure.)
Confused yet. Every PC will have different drive mappings, and they may
change over time.
I really wish I could automate this. However, I don't like the idea of
having the backup clone drive attached to a running PC, because of
possible conflicts having two identical drives, as Michael T.
mentioned. That's one reason I boot into the Acronis boot CD. Also, I
don't like the idea of a system crash or virus taking out my backup
drive because it's attached and running all the time.
Anyway, this is the system I'm using. Hope the info us useful to
others. I find it very useful for my purposes.
See comments to parts of the original posts below.
Sincerely,
Ron
On 01/20/2011 03:56 AM, Michael B. Trausch wrote:
> * If you are using the hibernation feature of the kernel, it is almost
> a given that you should be using a full swap partition, and not a
> swap file. Hibernation will leave files open and will preserve the
>
>
I've turned off automatic hibernation in the power settings menu.
However, I'd like to learn more about the implications. Windows doesn't
seem to mind hibernating, but it uses a separate hibernation file. I'd
still like the option of hibernating in Linux.
> I'd like to know more about your cloning setup to try to find out what
> happened to the swap partition during the clone process. It might have
> to do with the fact that most systems refer to just about everything
>
Documented above.
> Imagine this: you have two hard disk drives, /dev/sda and /dev/sdb.
> Now, imagine that your backup plan is to dd the contents of /dev/sda
> to /dev/sdb every day. If your system is setup as most modern systems
> are, this is going to cause a bit of an interesting problem: now, you
> have two drives that appear to be different (/dev/sda and /dev/sdb) but
> have filesystems with the same identifiers on them. Now you have
> created the ability for a race condition to occur. UUIDs prevent
> confusion caused by device reordering, but only if every filesystem on
> every drive has a truly unique identifier.
>
> Instead, what happens if at boot time, the drives change logical spots?
> Maybe the drives are on two different controllers, and sometimes one
> controller responds faster than the other and other times the second one
> responds faster. Or maybe the wires are just the tiniest bit
> squirrelly. Whichever filesystem with the specified UUID is the first
> filesystem to be found by the operating system is the one that will be
> used. That means that you might inadvertently find yourself using your
> backup drive as your primary drive. Or even worse, you won't realize it
> before you clobber the drive that you have been using as your primary
> drive. And in the worst case scenario, you won't notice it at all until
> you find files mysteriously missing, or filesystems that are seemingly
> inconsistent with each other.
>
>
I don't THINK this would be a problem in Windows, as the boot order
should be specified in the BIOS and should be referenced to a particular
port. Once booted, I don't think anything would get confused since the
extra drive might be E: and the boot drive might be C:. It would be
interesting to find out if there is a way to prevent problems in Linux,
since it would be nice to have the option to clone to an internal drive
every night, as you mentioned. Also, each drive should have a unique
serial number, even if the model number and the data is the same. Does
that help?
> It's not all impossible, however. There is a very useful component that
> is available with every modern Linux-based system at installation time:
> LVM, the Logical Volume Manager. LVM makes *so* many things a great
> deal easier. Among other things:
>
> * You can create (and mount) read-only or read-write snapshots of
> live filesystems such that you can safely run backups while the
> system is up and running. Snapshots usually only take a second
> or so to create, and can be destroyed almost instantly. You only
> need to keep them around long enough to create a new full or
> incremental backup, as well.
>
> * Logical volume management means that you can move, grow, shrink,
> create, delete, reshape, and reconfigure the logical volume,
> without worrying about whether the filesystem will be happy or
> not. Oh, and fileystems running on LVM do not have to be 100%
> contiguous, either; you can have them in extents all over the
> place, and you won't wind up with the odd problems of having to
> move them around to create enough useful contiguous space later
> on should you have to expand. LVM storage areas (called
> "physical volumes") and pools (called "volume groups") can grow
> and shink, as well, so you can increase your storage pool if
> desired, or shrink it if need be.
>
> * LVM's capabilities are filesystem agnostic. Snapshotting applies
> to all filesystems, including FAT, NTFS, ext2, ext3, ext4, minix,
> btrfs...
>
> * LVM does not have a (practical) limit on the number of logical
> volumes present. Unlike the MBR partition table, which is
> limited to 4 partitions, or the extended partition type which is
> limited to another certain number (and the Linux drivers which
> often have a limit of 16 total partitions for a device that uses
> the MBR partition table), logical volumes have either no limit,
> or a limit that is high enough that it is not likely to be
> encountered. I create tens of volumes (many of them snapshots)
> on production systems all the time. It's part of my daily
> backup processes.
>
> * Once you know how to use LVM and all of its functionality, you
> can perform volume management tasks far more quickly than
> without, especially if you do things like take backups quite
> often (as, IMHO, one should).
>
> * If you're using LVM, you no longer need to use UUIDs in your
> system files like /etc/fstab. Instead, you can use LVM device
> names like /dev/myvolumegroup/
>
>
The LVM's sound cool. I'll have to put that on my things to learn
list. It's a very long list, unfortunately.
--
(PS - If you email me and don't get a quick response, you might want to
call on the phone. I get about 300 emails per day from alternate energy
mailing lists and such. I don't always see new messages very quickly.)
Ron Frazier
770-205-9422 (O) Leave a message.
linuxdude AT c3energy.com
More information about the Ale
mailing list