Added section on when imaging does not make sense. Formatting cleanup.

Fork: 0

tundra / tbku

Browse code Added section on when imaging does not make sense. Formatting cleanup. master
1 parent 9051046 commit 8ba52730f1beb8a0fea254dc0df915ecc56c4e3b tundra authored on 12 Mar 2008

Patch

Unified Split

Showing 1 changed file

                Ignore Space
               Show notes
              View
            
          
          101 ■■■■■
          Imaging-SUSE-Linux-With-tbku.txt
 Suppose we need to build a new instance of a ``SUSE Linux`` system.
Perhaps we need to replace one that just had a hard drive failure.
Maybe we want to build a new server that is based on our "standard"
system configuration.  In other words, we want to go from "bare
metal" hardware to a fully running *and configured* system as quickly
as possible.
system configuration.  In other words, we want to go from "bare metal"
hardware to a fully running *and configured* system as quickly as
possible.
 
There are a number of commercial and open source solutions to this
problem, but they all have one thing in common: We want to minimize
the amount of manual labor needed to install, configure, and otherwise
"Imaging" or "Cloning" allows us to keep a copy of the entire OS *as
configured* - that means with all its applications and configuration
options set up as desired.  We then load or "Provision" a new hard
drive with this image and *voila'*, "instant" running system.
 
 
When Does Imaging NOT Make Sense?
=================================
 
Imaging works best when the system you are targeting is very similar
or identical to the system that made the image in the first place.
For example, Imaging is a great way to restore a single machine from
its own backups - say after a hard disk crash or upgrade.
 
Imaging is more complex when the source of the image and the target
machines are different.  The more different they are, the harder it
will be to get the image running on the new target machine.
 
As a practical matter, production Data Centers tend to keep a separate
restore image around *for each different system variant*.  So, for
example, you might have a separate image for your IBM servers, your
Dell servers, your Toshiba laptops, and so on.
 
 
What Is ``tbku``?
=================
          multiple copies of the backup image, and keep a couple
          of them off-site.
 
 
 
              
     
              
                        
 
 
Provisioning With The Master Image
==================================
 
Now that we have a "snapshot" or master image, we can use it
to (re)provision machines.
Now that we have a "snapshot" or master image, we can use it to
(re)provision machines.
 
    Provisioning Machines With A Master Image
 
       1. Boot the SUSE Linux installation disk and load the
       1. Boot the SUSE Linux installation disk and load the 
          ``Rescue System``.
 
       2. Now we have to prepare the disk to receive a Linux
          filesystem.  The example below assumes we are installing on
explanation.
 
This may all seem complex the first time you do it, but after a couple
of times, you'll be able to do this in your sleep.  This is one of
those things where describing it is more complicated than just
doing it!
those things where describing it is more complicated than just doing
it!
 
Depending on how large your backup image is, a complete system restore
can typically be done in less than an hour.  That's less than an hour
to a *completely configured system* with all your applications, custom
Gotchas
=======
 
 
If you use the approach described above to reprovision the 
same machine - say after a disk failure or disk upgrade - 
then that's all you have to do.  Your "target" machine is
essentially identical to the one from which you got the backup
image ... the same machine.
 
However, there are some circumstances where you cannot avoid doing some
configuration on the newly provisioned machine.  This is the case where
there is a significant difference between the machine that took the
snapshot and the machine receiving it.  This might be because the
If you use the approach described above to reprovision the same
machine - say after a disk failure or disk upgrade - then that's all
you have to do.  Your "target" machine is essentially identical to the
one from which you got the backup image ... the same machine.
 
However, there are some circumstances where you cannot avoid doing
some configuration on the newly provisioned machine.  This is the case
where there is a significant difference between the machine that took
the snapshot and the machine receiving it.  This might be because the
target machine has different hardware, needs a different IP address,
uses a different chipset, and so on. 
uses a different chipset, and so on.
 
There is no general way to solve these sorts of problems.  You'll have
to dig through YAST (if the system boots at all) and/or the individual
configuration tools to correct things.
 
As a personal preference, I like to work directly with configuration
files from the command line whenever I can.  If the target machine
will not boot, you sort of have no other choice.  You'll have to
do something like this to get to those files to edit them.
Boot the installation CD and select ``Rescue System``, then
mount the target drive(s)::
will not boot, you sort of have no other choice.  You'll have to do
something like this to get to those files to edit them.  Boot the
installation CD and select ``Rescue System``, then mount the target
drive(s)::
 
    mount /dev/hda2 /mnt
 
You can then edit the files found under /mnt.
 
 
 
A. Environmental Differences
 
B. Different Hardware
 
   1. CPU Architecture
   2. Motherboard Chipset
      - Disk Controllers
      - Network Controllers
      - Audio
      - Video
 
    A. Environmental Differences
 
    B. Different Hardware
 
       1. CPU Architecture
       2. Motherboard Chipset
          - Disk Controllers
          - Network Controllers
          - Audio
          - Video
 
Author
======
 
Document Information
====================
 
This document produced using the amazing ``reStructuredText`` tools in
the ``docutils`` package.  For more information, see: 
the ``docutils`` package.  For more information, see:
 
    http://docutils.sourceforge.net/rst.html
 
 
``$Id: Imaging-SUSE-Linux-With-tbku.txt,v 1.105 2008/03/12 23:06:34 tundra Exp $``
``$Id: Imaging-SUSE-Linux-With-tbku.txt,v 1.106 2008/03/12 23:17:24 tundra Exp $``
 Suppose we need to build a new instance of a ``SUSE Linux`` system.
 Perhaps we need to replace one that just had a hard drive failure.
 Maybe we want to build a new server that is based on our "standard"
+system configuration.  In other words, we want to go from "bare
+metal" hardware to a fully running *and configured* system as quickly
+as possible.
+system configuration.  In other words, we want to go from "bare metal"
+hardware to a fully running *and configured* system as quickly as
+possible.
 There are a number of commercial and open source solutions to this
 problem, but they all have one thing in common: We want to minimize
 the amount of manual labor needed to install, configure, and otherwise
 "Imaging" or "Cloning" allows us to keep a copy of the entire OS *as
 configured* - that means with all its applications and configuration
 options set up as desired.  We then load or "Provision" a new hard
 drive with this image and *voila'*, "instant" running system.
+When Does Imaging NOT Make Sense?
+=================================
+Imaging works best when the system you are targeting is very similar
+or identical to the system that made the image in the first place.
+For example, Imaging is a great way to restore a single machine from
+its own backups - say after a hard disk crash or upgrade.
+Imaging is more complex when the source of the image and the target
+machines are different.  The more different they are, the harder it
+will be to get the image running on the new target machine.
+As a practical matter, production Data Centers tend to keep a separate
+restore image around *for each different system variant*.  So, for
+example, you might have a separate image for your IBM servers, your
+Dell servers, your Toshiba laptops, and so on.
 What Is ``tbku``?
 =================
           multiple copies of the backup image, and keep a couple
           of them off-site.
 Provisioning With The Master Image
 ==================================
+Now that we have a "snapshot" or master image, we can use it
+to (re)provision machines.
+Now that we have a "snapshot" or master image, we can use it to
+(re)provision machines.
     Provisioning Machines With A Master Image
+. Boot the SUSE Linux installation disk and load the
+. Boot the SUSE Linux installation disk and load the
           ``Rescue System``.
 . Now we have to prepare the disk to receive a Linux
           filesystem.  The example below assumes we are installing on
 explanation.
 This may all seem complex the first time you do it, but after a couple
 of times, you'll be able to do this in your sleep.  This is one of
+those things where describing it is more complicated than just
+doing it!
+those things where describing it is more complicated than just doing
+it!
 Depending on how large your backup image is, a complete system restore
 can typically be done in less than an hour.  That's less than an hour
 to a *completely configured system* with all your applications, custom
 Gotchas
 =======
+If you use the approach described above to reprovision the
+same machine - say after a disk failure or disk upgrade -
+then that's all you have to do.  Your "target" machine is
+essentially identical to the one from which you got the backup
+image ... the same machine.
+However, there are some circumstances where you cannot avoid doing some
+configuration on the newly provisioned machine.  This is the case where
+there is a significant difference between the machine that took the
+snapshot and the machine receiving it.  This might be because the
+If you use the approach described above to reprovision the same
+machine - say after a disk failure or disk upgrade - then that's all
+you have to do.  Your "target" machine is essentially identical to the
+one from which you got the backup image ... the same machine.
+However, there are some circumstances where you cannot avoid doing
+some configuration on the newly provisioned machine.  This is the case
+where there is a significant difference between the machine that took
+the snapshot and the machine receiving it.  This might be because the
 target machine has different hardware, needs a different IP address,
+uses a different chipset, and so on.
+uses a different chipset, and so on.
 There is no general way to solve these sorts of problems.  You'll have
 to dig through YAST (if the system boots at all) and/or the individual
 configuration tools to correct things.
 As a personal preference, I like to work directly with configuration
 files from the command line whenever I can.  If the target machine
+will not boot, you sort of have no other choice.  You'll have to
+do something like this to get to those files to edit them.
+Boot the installation CD and select ``Rescue System``, then
+mount the target drive(s)::
+will not boot, you sort of have no other choice.  You'll have to do
+something like this to get to those files to edit them.  Boot the
+installation CD and select ``Rescue System``, then mount the target
+drive(s)::
     mount /dev/hda2 /mnt
 You can then edit the files found under /mnt.
+A. Environmental Differences
+B. Different Hardware
+. CPU Architecture
+. Motherboard Chipset
+      - Disk Controllers
+      - Network Controllers
+      - Audio
+      - Video
+    A. Environmental Differences
+    B. Different Hardware
+. CPU Architecture
+. Motherboard Chipset
+          - Disk Controllers
+          - Network Controllers
+          - Audio
+          - Video
 Author
 ======
 Document Information
 ====================
 This document produced using the amazing ``reStructuredText`` tools in
+the ``docutils`` package.  For more information, see:
+the ``docutils`` package.  For more information, see:
     http://docutils.sourceforge.net/rst.html
+``$Id: Imaging-SUSE-Linux-With-tbku.txt,v 1.105 2008/03/12 23:06:34 tundra Exp $``
+``$Id: Imaging-SUSE-Linux-With-tbku.txt,v 1.106 2008/03/12 23:17:24 tundra Exp $``

Show line notes below