diff --git a/Imaging-SUSE-Linux-With-tbku.txt b/Imaging-SUSE-Linux-With-tbku.txt index 7ce8118..dc688c7 100644 --- a/Imaging-SUSE-Linux-With-tbku.txt +++ b/Imaging-SUSE-Linux-With-tbku.txt @@ -17,9 +17,9 @@ 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 @@ -34,6 +34,24 @@ 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``? ================= @@ -139,22 +157,15 @@ 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 @@ -283,8 +294,8 @@ 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 @@ -296,18 +307,17 @@ ======= -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. +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 +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 @@ -315,28 +325,26 @@ 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 -A. Environmental Differences + B. Different Hardware -B. Different Hardware - - 1. CPU Architecture - 2. Motherboard Chipset - - Disk Controllers - - Network Controllers - - Audio - - Video - + 1. CPU Architecture + 2. Motherboard Chipset + - Disk Controllers + - Network Controllers + - Audio + - Video Author ====== @@ -350,9 +358,9 @@ ==================== 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 $``