[ale] HELP! Mint machine is booting from the wrong hard drive

[JD]

Ron,

I stopped using image-based backups about 15 yrs ago for UNIX systems.  I would
be curious if anyone here still uses them?  Even old style dump/restore doesn't
do that.

There are thousands of different backup methods possible, each with different
issues. You've discovered 1 of the smaller issues with image-based backups going
to disks on the same machine.

If you use versioned backups like duplicity, rdiff-backup and many others
support, you'll have different issues, but much more flexibility.  There are
GUIs for most of these.  I can restore everything from yesterday, last week,
last month and for some systems, the month before that.  30 says of versioned
backups doesn't require 30x the storage.  Let me see ...
$ sudo rdiff-backup --list-increment-sizes /Backups/desktop
        Time                       Size        Cumulative size
-----------------------------------------------------------------------------
Wed Jul  3 02:03:06 2013         4.66 GB           4.66 GB   (current mirror)
Tue Jul  2 02:03:07 2013         9.13 MB           4.67 GB
Mon Jul  1 02:03:07 2013         9.64 MB           4.67 GB
Sun Jun 30 02:03:06 2013         24.5 MB           4.70 GB
....
Fri Jun  7 02:03:06 2013         9.55 MB           4.94 GB
Thu Jun  6 02:03:07 2013         19.1 MB           4.95 GB
Wed Jun  5 02:03:06 2013         8.56 MB           4.96 GB
Tue Jun  4 02:03:05 2013         9.08 MB           4.97 GB

I haven't done much on my desktop the last month, so there really isn't much
change data ... just daily emails and a few scripts.  4.66G (mirror) vs 4.97G
(all changes for the last 30 days).  Might need to up the retention to 60 days.

This backup is just the information to restore the desktop. All OS settings
(/etc, crontabs, selected /var/ things ), package lists (apt, cpan, gems),
hardware list, plus my $HOME.  I do NOT backup the OS itself.

Currently, there are 32 systems here with backups of a similar style.  Total
storage for these systems is: 421GB. Most were migrated from Xen to KVM using
this method in the last 2 yrs.  If I stored the entire OS for each, that would
be roughly 32 x 4G = 128G ... extra for very little added convenience, IMHO.
Plus I'd have to manage that extra storage, check it as part of the backups,
move it around, ... just more hassles.  Pushing more data to a remote location
is a killer too.

Before I switched methods, backups were taking many, many hours. Now each system
backup is usually just 2-3 minutes.

Large data that doesn't change much is backed up differently - basically using
rsync without any versioning. It just isn't practical to have 30 versions of a
25G file.



On 07/03/2013 07:30 AM, Jim Kinney wrote:
> You want a data clone but not a clone of the hard drive meta data - UUID in
> particular. Change the backup drive UUID (for each partition) and change the
> backup method to only capture files - rsync is a good choice. Lastly, check the
> backed-up fstab file and make sure the UUIDs there point to the backup drive. Be
> sure to exclude that file from being overwritten later
> 
> 
> On Wed, Jul 3, 2013 at 1:07 AM, Ron Frazier (ALE)
> <atllinuxenthinfo at techstarship.com <mailto:atllinuxenthinfo at techstarship.com>>
> wrote:
> 
> 
> 
>     see below
> 
>     Phil Turmel <philip at turmel.org <mailto:philip at turmel.org>> wrote:
> 
>     >On 07/02/2013 11:15 PM, Ron Frazier (ALE) wrote:
>     >> Hi all,
>     >>
>     >> One of my machines is running Mint 13 (based on Ubuntu 12.04).  The
>     >> machine has two hard drives, a 320 GB hard drive on /dev/sda and a
>     >500
>     >> GB hard drive on /dev/sdb.  The 500 GB drive is for backup purposes
>     >> only.  Tonight, I made an exact clone (as far as I know) of the 320
>     >GB
>     >> hdd over to the 500 GB hdd with clonezilla.  The 500 GB hdd is still
>     >> attached.
>     >
>     >The problem is that you made an *exact* clone.  Modern distros use the
>     >UUID or LABEL embedded in a filesystem to find the necessary partitions
>     >during boot (to avoid issues with hot-pluggable drives).  If you clone
>     >partitions, both will have that metadata, and your boot process becomes
>     >random.
>     >
>     >> My bios is set to boot from the 320 GB drive (/dev/sda).  Once I
>     >boot,
>     >> the grub menu asks if I want to boot Mint on /dev/sda2, which is
>     >> correct.  I select that, but, when the system comes up, I find that
>     >the
>     >> 500 GB hdd (/dev/sdB2) is the one that's mounted, and that's not what
>     >I
>     >> want.
>     >>
>     >> Can someone tell me why this is happening and how to prevent it
>     >without
>     >> physically unplugging the drive?
>     >
>     >Change the label and uuid on the partition(s) on one of the drives,
>     >then
>     >change /etc/fstab within that one to point to its own label/uuid.  The
>     >utilities needed vary with filesystem type, but it would be "tune2fs"
>     >for anything in the "ext" family.
>     >
>     >Use a rescue CD or thumb drive so you have total control over temporary
>     >mounts.  Check your work with "blkid".
>     >
>     >Phil
>     >
> 
>     Hi Phil,
> 
>     Thanks for the info.  I understand what you're saying.  I have a few more
>     questions.
> 
>     * Would I not want an exact clone if I had to put the backup drive into service?
> 
>     * Do you know if Windows is susceptible to this problem?  I've had a clone
>     drive connected to Windows in the past and haven't noticed a problem.  To be
>     honest, I don't know if I booted that way, but I was wondering if that's a
>     problem in that environment.
> 
>     * I'd rather not have to tweak every backup that I make.  Is there some way
>     to automate the changes?  Or, perhaps I should just put a switch on the sata
>     power cable and switch the drive off when I don't want to be accessing the
>     backup drive.
> 
>     Sincerely,
> 
>     Ron
> 
>