diff --git a/baremetal.rst b/baremetal.rst
index aa7f43b..e314600 100644
--- a/baremetal.rst
+++ b/baremetal.rst
@@ -6,7 +6,7 @@
 
 :Author: Tim Daneliuk (tundra@tundraware.com)
 
-:Version: ``$Id: baremetal.rst,v 1.102 2014/08/22 23:05:22 tundra Exp $``
+:Version: ``$Id: baremetal.rst,v 1.103 2014/08/22 23:38:40 tundra Exp $``
 
 
 Précis
@@ -65,18 +65,76 @@
 ----------------
 
 ::
+    Boot from  the System Rescue CD
 
-    mount nas1:/shared /shared   # Mount shared storage
+    mount nas1:/shared /shared                     # Mount shared storage
+
+    sfdisk -d /dev/sda >/shared/ptbl               # Preserve the partition table
+
+    dd if=/dev/sda of=/shared/MBR bs=512 count=1   # Backup the Master Boot Record
+
+    dd if=/dev/sda1 of=/shared/boot.dd bs=12M      # Backup /boot
+
+    dd if=/dev/sda2 of=/shared/root.dd bs=12M      # Backup rootvg LVM (rest of OS)
+
+    reboot machine to make it operational again
 
 
+How long this takes depends on what your write speed to the shared storage is
+and how big your partitions are.  In this case ``sda1`` is only about 100MB 
+and completed rather quickly.   But ``sda2`` was about 52GB and took around
+25 min to complete on a slow nfs mount - about 26MB/min in this case or about
+a quarter of the capacity of the 1Ge network connecting the NAS.
 
+The ``bs=12`` is environment-specific and you'll have to find a setting for this
+that makes best use of your network and NAS or other storage device.
 
 
 Restore Procedure
 -----------------
 
+Now, imagine that your OS is borked or the hard disk had to be replaced and you
+need to take the image from the backup above and getting running on the machine.
 
 
+::
+    Boot from  the System Rescue CD
+
+    mount nas1:/shared /shared                     # Mount shared storage
+
+    dd if=/dev/zero of=/dev/sda bs=512 count=10    # Nuke any old boot/partion info on the disk
+
+    sfdisk /dev/sda </shared/ptbl                  # Restore the partition table
+
+    dd if=/shared/MBR of=/dev/sda bs=512 count=1   # Restore the Master Boot Record
+
+    dd if=/shared/boot.dd of=/dev/sda1 bs=12M      # Restore /boot
+
+    dd if=/shared/root.dd of=/dev/sda2 bs=12M      # Restore rootvg LVM (rest of OS)
+
+    Reboot machine to make it operational again
+
+On the same network described above, restoring the 52MB ``rootvg``
+took about 35 mins.
+
+Because this is partition based - that is, you are imaging and
+restoring *partitions* not disks - you can actually restore to a
+physical disk that is a different size than the one from which the
+image was taken so long as there is room for all the data on the new
+disk.  This makes it easy to lay your operating system down on a new,
+larger disk.  Do an image of the old disk, restore it to the new disk,
+and thenm, while still running under the ``System Rescue CD``, run
+``parted`` or ``gparted`` to expand the partitions to use the
+additional disk space.
+
+.. warning:: **Do NOT try this with a machine that boots from SAN!!!**
+             SAN-booted machines put information into their
+             bootloaders about the boot LUN's WWID and the necessary
+             configuration of HBAs to see those LUNs.  If you present
+             a bigger LUN with a different WWID, the OS bootstrap will
+             probably fail, even though you can properly restore the
+             image.  There are ways around this.  This document is not
+             the place to find these ways.
 
 
 Conclusions & Limitations
@@ -84,14 +142,20 @@
 
 - This seems to work fine in the limited configuration that was tested.
 
-- The upside of this approach is that you can use standard Linux
-  commands to do imaged backups of your machine.
+- Upside:
 
-- There are two downsides:
+    1) You can use standard Linux commands to do imaged backups of
+       your machine.
 
-    1) You cannot do this while the machine is up and running.
+    2) You can use this to migrate an OS to a bigger disk.
 
-    2) Every block in the partition gets copied whether it is used or not.
+- Downside:
+
+    1) You cannot do this while the machine is up and running so
+       imaging this way requires a machine outage.
+
+    2) Every block in the partition gets copied whether it is used or
+       not.
 
 - In *theory* this should also work on SAN-booted machines so long as
   the exact same LUN (WWID and size) is presented for the restore as
@@ -106,12 +170,33 @@
 - Again, *theoretically* this should work with other operating system
   partitions and data partitions.  But ... not tested.
 
+- This works well for Unix-style operating systems because they boot with
+  a full complement of drivers and discover what is on the machine
+  at boot time.  However, Windows may have a fit if you do this,
+  especially if you restore to machine substantially different than
+  the one where the backup image was created.  First of all, Windows
+  doesn't carry around any drivers it doesn't think it needs.  Secondly,
+  Windows licensing logic is designed to prevent this sort of thing
+  as a deterrent to software piracy.  
+
+- This approach assumes the disk us partitioned using standard ``fdisk``
+  type tools.  Some OSs - notably ``FreeBSD`` - have the option to use
+  their own disk slicing and labeling tools.  This general approach will
+  work, but you have to tweak it to ensure you preserve those boot loaders
+  and custom slicing tables.
 
 
 Copyright And Licensing
 =======================
 
 This document is Copyright (c) 2014, TundraWare Inc., Des Plaines, IL
+
+
+
+
+
+
+
 60018, All Rights Reserved.
 
 Permission is hereby granted for the free duplication and dissemination of