Documentation fixups

diff --git a/BackupPC_ovz b/BackupPC_ovz
index 883b693723273fc789a15fc99245851e4f635121..bb4b100dc00322e8bf51b28e616119bcbb65a277 100755 (executable)
--- a/BackupPC_ovz
+++ b/BackupPC_ovz
@@ -4,6 +4,8 @@
 #
 # OpenVZ integration for BackupPC allowing the latter to backup OpenVZ VE's
 # with ovz awareness to improve backup and restore efficiency and features.
+#
+# 20080605     0.1     Initial release
 
 # FIXME: signal handling to clean up mount point and snapshot on termination
 

diff --git a/README b/README
index a2c27875e5820fa9475ec19e369973e340eae1ee..93d60ab3405a27215ef1023188508a11795f94e2 100644 (file)
--- a/README
+++ b/README
@@ -17,10 +17,10 @@ BackupPC_ovz adds the following capabilities to BackupPC:
    upon the amount of application-dependent processing occurs at shutdown and
    startup.
 
- * Both rsync and tar BackupPC XferMethods are supported.  Because the backup
-   and restore agent processes actually run on the HN hosting the VE, direct
-   restore from BackupPC's web interface can be used to do a 'bare metal'
-   recovery of the VE.
+ * Currently, only the rsync BackupPC XferMethod has been tested, but tar
+   should probably work.  Because the backup and restore agent processes
+   actually run on the HN hosting the VE, direct restore from BackupPC's web
+   interface can be used to do a 'bare metal' recovery of the VE.
 
  * Any time the VE's /etc directory is backed up, the backup will add an
    /etc/vzdump directory containing the VE's configuration on the HN, notably
@@ -81,21 +81,37 @@ To install BackupPC_ovz:
 
  * Install BackupPC as normal.
 
- * Configure all HNs as Hosts (backup/restore targets in BackupPC) per normal
-   BackupPC instructions.  Until the HNs can be succesfully backed up and
-   restored, these operations cannot be successfully completed on any VEs.  We
-   reccommend the rsync or tar XferMethods, using ssh as a transport.  Only
-   the rsync method has been tested at this time.
+ * Install a recent version of rsync (we use 3.0.0pre6+) into each HN and the
+   BackupPC's VE.  A recent version of rsync is also required inside any VE
+   that may be online migrated via vzmigrate when shared storage is not in use.
+   (In otherwords, install rsync 3.0.0pre6+ on all HN's and inside all VEs).
+
+   NOTE: BackupPC doesn't have to be installed in a VE; it could be installed
+   on a separate server.  Do not install BackupPC or any other application
+   directly onto an HN (see the BackupPC FAQs).
+
+ * Configure all HNs as Hosts (backup/restore targets in BackupPC) per standard
+   BackupPC instructions and verify that backup and restore operations work
+   correctly.  Until the HNs can be succesfully backed up and restored,
+   operations on VE's cannot be successfully completed.  We reccommend the
+   rsync or tar XferMethods, using ssh as a transport.  Only the rsync method
+   has been tested at this time.
 
    - On the BackupPC SSH FAQ, there are instructions for installing an SSH
      key on servers to be backed up by BackupPC.  Because VEs are actually
      backed up and restored through the context of the hardware node (HN),
-     only the HNs need to have the keys.  They do NOT need to be installed
+     only the HNs need to have the keys.  Keys do NOT need to be installed
      in the VEs themselves.
 
- * Install a recent version of rsync (we use 3.0.0pre6+) into each HN.  Note
-   that a recent version of rsync is also required inside the VE to
-   successfully perform online migration without shared storage.
+ * Create the file /etc/backuppc/BackupPC_ovz.hnlist.  Its contents should
+   contain the fully qualified hostname of each HN.  An example:
+
+   ---- /etc/backuppc/BackupPC_ovz.hnlist ----
+   # List the HNs by hostname of IP address in this file.
+   pe18001.mydomain.com
+   pe18002.mydomain.com
+   pe18003.mydomain.com
+   ---- end of file ----
 
  * Install BackupPC_ovz into /usr/bin of each HN.  The owner should be root,
    the group root and file permissions 0755.
@@ -105,17 +121,24 @@ To install BackupPC_ovz:
    BackupPC_ovz:
 
    - On the Backup Settings page, set the DumpPreUserCommand and
-     RestorePreUserCommand fields to:
+     RestorePreUserCommand fields to contain:
        /usr/bin/BackupPC_ovz refresh
 
-   - On the Xfer page, add the following to the beginning of the RsyncClientCmd
-     field without altering the field's contents in any other way:
+   - On the Xfer page, add:
        /usr/bin/BackupPC_ovz server
+     to the beginning of the RsyncClientCmd field without altering the field's
+     contents in any other way.  Our VE's have this data in the RsyncClientCmd
+     field:
+       /usr/bin/BackupPC_ovz server $host $sshPath -q -x -l root
+           $host $rsyncPath $argList+
 
-   - On the Xfer page, add the following to the beginning of the
-     RsyncClientRestoreCmd field without altering the field's contents in any
-     other way:
+   - On the Xfer page, add
        /usr/bin/BackupPC_ovz server restore
+     to the beginning of the RsyncClientRestoreCmd field without altering the
+     field's contents in any other way.  Our VE's have this data in the
+     RsyncClientRestoreCmd field:
+       /usr/bin/BackupPC_ovz server restore $host $sshPath -q -x -l root
+           $host $rsyncPath $argList+
 
  * To add subsequent VE's to BackupPC, add each new VE into BackupPC using the
    NEWHOST=COPYHOST mechanism, as documented on the Edit Hosts page.  This will
@@ -137,21 +160,28 @@ recovered in its entirey, analogous to a 'bare metal' recovery of a physical
 server:
 
  * Stop the VE to be fully recovered using vzctl, if it is running.
- * Using BackupPC, do a Direct Restore of the desired backup to the VE.
+ * Using BackupPC, select all files and directories of the appropriate VE
+   backup and use Direct Restore to restore everything.
+   - Restore NOT to the VE host, but to the HN host that will host the newly
+     recovered VE.
+   - In the Direct Restore dialog, select the appropriate HN filesystem
+     location to restore the VE.  For example, if VE 123 has its private data
+     at /var/lib/vz/private/123 on the HN, then the recovery directory would be
+     /var/lib/vz/private/123.
  * After the restore is complete, recover the ovz-specific VE configuration
    files from the VE's /etc/vzdump directory into the appropriate locations
-   of the HN's /etc/vz/conf directory.  There is nothing to do if these
-   configuration files have not been changed (aka vzctl set).
+   of the HN's /etc/vz/conf directory.  This is only required if the config
+   file(s) has(have) changed.
  * Start the VE using ovz's vzctl utiltiy.
 
-The above strategy works great to restore an existing VE to a prior state.
-Using the rsync xfer method for recovery, a delta recovery is performed,
-dramatically reducing the recovery time.
+The above strategy works great to restore an existing VE to a prior state, as
+the rsync xfer method will not overwrite files that are the same, reducing I/O
+and therefore recovery time.
 
 What happens if we need to recover a VE where no existing version of the VE
 is running anywhere?  Consider a disaster recovery case where the HN hosting
-the VE melted and is completely unrecoverable.  We can then use a similar
-process as above to recover the VE to another HN -- even one that had never
+the VE melted and is completely unrecoverable.  We then use the same
+process as above to recover the VE to an HN -- even one that might never have
 hosted the VE before.
 
  * Using BackupPC, select all files and directories of the appropriate VE
@@ -175,6 +205,7 @@ Configurations Tested:
    Raid disks running under LVM2.
    XFS filesystem for VE private areas.
  * BackupPC running as a VE on one of the PE1800's.
+   Running version 3.0.0-ubuntu2
  * A number of other VE's distributed between the two PE1800's.
  * VEs running various OS's: Mandrake 2006, Ubuntu Feisty, Ubuntu Gutsy.
  * VE backups and restores using the rsync method.