X-Git-Url: https://oss.titaniummirror.com/gitweb?a=blobdiff_plain;f=README;h=55a6de5e124fd9e6d6cc10a0c00c7a8390ce0acb;hb=HEAD;hp=375aee8096ebf2b10469ad3904eb059b8e13a7c9;hpb=61c07e8efed6aa4bfd36302bb75efa320649e562;p=ovzbpc.git diff --git a/README b/README index 375aee8..55a6de5 100644 --- 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 @@ -36,6 +36,10 @@ BackupPC_ovz adds the following capabilities to BackupPC: 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 @@ -81,15 +85,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. 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. @@ -99,17 +125,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 @@ -131,21 +164,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 @@ -161,3 +201,17 @@ hosted the VE before. 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. +