Fork: 0
tundra / tbku
Browse code
Added sections on taking an image and provisioning with it.
master
1 parent 5b19c17 commit 2f55fefedc1de4266dbd674f45174fa190f97e7a
@tundra tundra authored on 12 Mar 2008
Patch
Unified Split
Showing 1 changed file
View
336
■■■■■
 Imaging-SUSE-Linux-With-tbku.txt
 
This document describes how to use the TundraWare Inc. ``tbku``
utility to "image" or "clone" SUSE Linux systems.
 
.. Note::
Most/Much of this will also be relevant to other Linux distributions,
though some of the fine points may be different.
.. Note::
 
Most/Much of this will also be relevant to other Linux
distributions, though some of the fine points may be
different.
 
 
Why Bother Imaging?
===================
every server, its applications, and its customization information.
 
"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 a new hard drive with this
image and *voila'*, "instant" running system.
options set up as desired. We then load or "Provision" a new hard
drive with this image and *voila'*, "instant" running system.
 
 
What Is ``tbku``?
=================
 
``tbku`` is a shell script that makes it easy to create tarballs
of some of all of your filesystems. If you've never used it before,
take a moment to download it and read the documentation. You'll
find the latest copy at:
``tbku`` is a shell script that makes it easy to create tarballs of
some of all of your filesystems. ``tbku`` does not help you with
*restoring* your image, it's just handy for creating the image in the
first place.
 
If you've never used it before, take a moment to download it and read
the documentation. You'll find the latest copy at:
 
http://www.tundraware.com/Software/tbku
 
There is no fee for using ``tbku`` in any context, personal or
commercial. However, there are some licensing terms you have to abide
by to use it, so take a moment to read the license in the distribution
tarball.
 
.. Note::
You don't *have* to use ``tbku`` to create your backup image.
The description below should work fine so long as you have a
backup of all the relevant files that preserves all the
appropriate file information such as ownership and permissions.
``tbku`` just makes it easy to automate the creation of such
backups.
.. Note::
 
You don't *have* to use ``tbku`` to create your backup
image. The description below should work fine so long
as you have a backup of all the relevant files that
preserves all the appropriate file information such as
ownership and permissions. ``tbku`` just makes it easy
to automate the creation of such backups.
 
 
The Big Picture
===============
Before diving into the details, it's good to get a sense of the
overall process. Imaging a system requires the following steps:
 
 
1) Create the "master" image
 
- Create a baseline system configured as you want it.
- Take an "image" of it. (That's where ``tbku`` is helpful.)
- Save the image somewhere (DVD, USB drive, network drive ...).
you can get at when you need it to (re)install a system.
 
2) Use the master image to (re)provision a machine
 
- Prepare the target hard disk to receive the image.
- Dump the image onto the hard disk.
- Adjust the configuration if/as needed for the new hardware.
A. Create the master image:
 
- Create a baseline system configured as you want it.
- Take an "image" of it. (That's where ``tbku`` is helpful.)
- Save the image somewhere (DVD, USB drive, network drive ...)
you can get at when you need it to (re)install a system.
 
B. Use the master image to (re)provision a machine:
 
- Prepare the target hard disk to receive the image.
- Dump the image onto the hard disk.
- Adjust the configuration if/as needed for the new hardware.
 
 
Creating The Master Image
=========================
 
Unlike other approaches that make an image of *the disk*, ``tbku``
which the master image (sometimes called a "snapshot") was made. You
can clone systems back and forth between SCSI, IDE, and SATA. You can
clone from smaller disks to larger ones or go the other way.
 
.. Note::
 
The whole point of doing imaging is to avoid having to do custom
configuration for each new installation. However, some small
amount may be necessary when the target hardware is different
than the hardware on which the master image was created. This is
discussed a bit more below in the `Gotchas`_ section.
 
.. Note::
 
The whole point of doing imaging is to avoid having to
do custom configuration for each new installation.
However, some configuration changes may be necessary
when the target hardware is different than the hardware
on which the master image was created. This is
discussed a bit more below in the `Gotchas`_ section.
 
 
Creating The Master Image
 
1. Select the machine whose existing SUSE Linux installation
you want preserved or used as a standard installation image.
 
2. Image that system with ``tbku`` using the following
fileset::
 
/bin
/boot
/dwnl
/etc
/home
/lib
/local
/opt
/root
/sbin
/srv
/usr
/var
 
Notice that we do *not* backup the dynamic kernel-created
filesystems like ``/dev`` or ``/proc``.
 
3. Save the resulting ``.tar.gz`` (tarball) file somewhere
it can be retrieved later when you want to image another
machine. This can be a network server, a USB drive,
a DVD or whatever makes sense in your environment. As
with all backup systems, it's pretty important to make
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.
 
Provisioning Machines With A Master Image
 
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
/dev/hda - a PATA master on the first IDE controller - but
you can do what follows with any of the drives on your
system. Just substitute the device names as appropriate::
 
# Partition the drive:
 
fdisk /dev/hda
 
# Delete and create partitions as you like
# Make sure the partition that will mount /
# is toggled to be bootable
# Be sure to use the 'write' option before exiting
 
# Suppose you end up with this:
#
# /dev/hda1 is for swap (type 82)
# /dev/hda2 is for your filesystem (type 83)
 
mkswap /dev/hda1
mkfs.reiserfs /dev/hda2
mount /dev/hda2 /mnt
 
# Now, let's create the top level directories that that
# were not backed up and/or will be used by the kernel
# for its own filesystems:
 
cd /mnt
mkdir dev media mnt proc sys tmp
 
# Now it's time to mount your backup medium. Depending
# on your backup medium this can be one of several
# devices. CD/DVDs are often found at /dev/hdc1. USB
# drives show up as SCSI drives such as /dev/sda1, and
# so on. You'll also need to know the type of the
# backup medium (see: man mount for the details):
 
mount -tvfat /dev/sda1 /mnt/mnt # This is a USB drive
 
# OK, time to dump the image previously created by tbku
# onto our shiny new filesystem (make sure your current
# directory is still /mnt before doing this):
 
tar -xzvf /mnt/my-system-image.tar.gz
 
# Now we have to make sure that the boot tables and
# default file mounts are correct - Our target system
# may have a different drive type or device (SCSI, sata,
# pata) than the system from which tbku took the image:
 
# Edit /mnt/etc/fstab to reflect the partitioning
# you did with fdisk. Remember that drives can be
# named by device name (/dev/xxxx) or by the vendor
# name (/dev/disk/by-id/xxxx). In our case the
# relevant portion of /mnt/etc/fstab looks like this:
 
/dev/hda1 swap swap defaults 0 0
/dev/hda2 / reiserfs acl,user_xattr 1 1
 
# Be sure not to disturb the other stuff in the fstab
# file
 
# Now, check and fix the device map file,
# /mnt/boot/grub/device.map Say we took the tbku image
# from a system that boot from SCSI, that file
# would look like this:
 
(fd0) /dev/fd0
(hd0) /dev/sda
 
# But our new system wants to boot from ATAPI so it
# now needs to look like this:
 
(fd0) /dev/fd0
(hd0) /dev/hda
 
# We also have to correct any differences in the boot
# menu that appears when you first start the system.
# This is in /mnt/boot/grub/menu.lst Near the top of
# this file you'll see something like this:
 
gfxmenu (hd0,1)/boot/message
 
# hd0 is right - we made sure of that when we edited
# the map file above. Make sure that the offset (1 in
# this case) is also right. This is the number,
# *counting from 0* of the root/boot partition within that
# drive. In our case, (hd0,1) is correct because our
# root/boot partition is /dev/hda2.
 
# Following this are the individual menu entries.
# Make sure you check each line of every entry.
# Suppose we find this:
 
title SLED 10 - 2.6.16.54-0.2.5
root (hd0,1)
kernel /boot/vmlinuz-2.6.16.54-0.2.5-default root=/dev/sda2
resume=/dev/sda1 splash=silent showopts
initrd /boot/initrd-2.6.16.54-0.2.5-default
 
# All references to /dev/sda2 have to be changed to /dev/hda2
# All references to /dev/sda1 have to be changed to /dev/hda1
# Repeat this for every menu entry.
 
# Finally, lets make sure that the boot loader
# is properly installed and configured:
 
grub-install --root-directory=/mnt /dev/hda
 
 
We're DONE! Well ... maybe. If the hardware (chipset, CPU) of your
target machine is similar/same as the machine from which you took the
original image OR if the kernel you plan to boot has support for your
new target hardware, you should just be able to boot and run at this
point. If not, read the following `Gotchas`_ section for further
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. 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 configuration,
and so on as you last left them.
 
 
Gotchas
=======
 
There are some circumstances where you cannot avoid doing some
small amount of configuration on the newly provisioned machine.
configuration on the newly provisioned machine.
 
A. Network differences
 
B. Different Hardware
 
C. Different Chip Architectures
 
 
 
Author
======
 
Comments and/or improvements welcome!
 
 
Document Revision Information
=============================
 
``$Id: Imaging-SUSE-Linux-With-tbku.txt,v 1.103 2008/03/11 23:11:20 tundra Exp $``
Document Information
====================
 
This document produced using the amazing ``reStructuredText`` tools in
the ``docutils`` package. For more information, see:
 
http://docutils.sourceforge.net/rst.html
 
 
``$Id: Imaging-SUSE-Linux-With-tbku.txt,v 1.104 2008/03/12 22:40:44 tundra Exp $``