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
periodically rebalance VE's using the ovz vzmigrate utility, as BackupPC_ovz
will correctly locate a moved VE at the next backup.
+ * BackupPC_ovz refreshConfig() copies itself to the known OpenVZ hardware
+ nodes. This means that BackupPC_ovz upgrades must happen on the BackupPC
+ server (in our case, an OpenVZ container/VE).
+
Requirements
BackupPC_ovz requires that the HN be set up correctly as if it were to be a
* 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. Note
- that a recent version of rsync is also required inside the VE to
- successfully perform online migration without shared storage.
+ * 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. Keys do NOT need to be installed
+ in the VEs themselves.
+
+ * 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.
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
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
files from the VE's /etc/vzdump directory into the appropriate locations
of the HN's /etc/vz/conf directory.
* Start the VE using ovz's vzctl utiltiy.
+
+Configurations Tested:
+
+ * Twin Dell PowerEdge 1800 servers (the HNs).
+ Running a minimal Ubuntu Gutsy server OS.
+ 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.
+ * All VEs and HNs have rsync 3.0.0pre6 or newer installed.
+