diff --git a/baremetal.rst b/baremetal.rst
new file mode 100644
index 0000000..5ef0051
--- /dev/null
+++ b/baremetal.rst
@@ -0,0 +1,60 @@
+Baremetal Backup/Restore - Another Approach
+===========================================
+
+
+Overview
+--------
+
+Many commercial and open source solutions exist to solve the
+problem of being able to 
+
+Backup
+------
+
+
+Restore
+-------
+
+
+Conclusions & Limitations
+-------------------------
+
+- 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.
+
+- There are two downsides:
+
+    1) You cannot do this while the machine is up and running.
+
+    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
+  was used for the backup.  However, this was not tested and theory
+  and Reality usually collide in rather nasty ways.  Mr. Murphy is not
+  our friend.
+
+- Same story for VMs.  Not tested.  It's unclear whether a VM booted
+  from a rescue disk would see the underlying disk storage (VMDK or
+  whatever).
+
+- Again, *theoretically* this should work with other operating system
+  partitions and data partitions.  But ... not tested.
+
+
+
+Document Information & Disclaimer
+---------------------------------
+
+This document describes an *experimental* procedure for learning
+purposes.  It has not been tested in all possible hardware, operating
+system, and network configurations.  You should not trust this
+approach unless you prove that you can backup *and* restore correctly in *your
+environment*.
+
+Copyright (c) 2014, TundraWare Inc.
+
+$Id: baremetal.rst,v 1.1 2014/08/22 21:28:22 tundra Exp $
+