Line 283: |
Line 283: |
| ==== [Todo] Two production servers backup each other ==== | | ==== [Todo] Two production servers backup each other ==== |
| ... | | ... |
− | ==== Moving a SME 7 server installation to a new hardware using the Affa rise feature ====
| |
− | The following example describes a method to move a production server to a new hardware with a minimized down time.
| |
− |
| |
− | You have a SME 7 production server with hostname 'prodbox‘ running and want to move it to a new hardware.
| |
− |
| |
− | # Connect the new hardware to your local net, install SME Server and all the contribs package you have installed on the 'prodbox‘. You can assign any unused IP address and hostname, as these are only temporary used. Ensure, that both servers have identical SME version installed. Run 'yum update' on both servers, if necessary.
| |
− | # Install and configure Affa (on the new hardware) as described in the examples above and configure a job 'prodbox' to backup your 'prodbox‘ using the 'jobconfig-sample.pl.' file<br>Important is to set these properties;<br><code>'SMEServer'=>'yes',</code><br><code>'RPMCheck '=>'yes',</code><br><code>'status'=>'disabled',</code>
| |
− | # Now run the job 'prodbox' manually, while your users can still work on the server 'prodbox'<br><code># affa --run prodbox</code><br>The run may take a long time, depending of the size of the backup.
| |
− | # When the run has finished, check the file /var/affa/prodbox/rpms-missing.txt. As the filename indicates, all RPMS installed on 'prodbox‘, but not on this Affa server, are listed there. Install the missing RPMs.
| |
− | # Ask all your users to log off. To ensure, that no data will be modified from now on, you may want to stop a couple of services on the 'prodbox‘, e.g. qpstmpd, qmail, crond (because of fetchmail), smb, atalk, httpd. Don't stop mysqld, as this service is required by mysqldump in the pre-backup event.
| |
− | # Run the job again<br><code># affa --run prodbox</code><br>This run should be completed quickly, as only the differences compared to the last run are backuped.
| |
− | # When this final run has finished, powerdown the 'prodbox‘ (old hardware) and rise the Affa box (new hardware) to a 'prodbox‘ clone.<br><code># affa --rise prodbox</code><br>
| |
− | # Reboot the server. Your users can now re-logon.
| |
− |
| |
− | With this method you should be able to move even a typical 50 Gbyte sized server to a new hardware with downtime less than 20 minutes. The rise time does not really depend on the total files size, but on the number of files and directories.
| |
| | | |
| ==== Use Affa to backup to a NFS-mounted NAS or a local attached USB drive ==== | | ==== Use Affa to backup to a NFS-mounted NAS or a local attached USB drive ==== |
Line 411: |
Line 396: |
| | | |
| '''Important note:''' A full restore reconstruct the server as it was at the time of the backup. That means, files created or server configuration changes after the backup run will be lost. After the restore is done, the restored server reboots automatically. | | '''Important note:''' A full restore reconstruct the server as it was at the time of the backup. That means, files created or server configuration changes after the backup run will be lost. After the restore is done, the restored server reboots automatically. |
| + | |
| + | ==== Moving a SME 7 server installation to a new hardware using the Affa rise feature ==== |
| + | The following example describes a method to move a production server to a new hardware with a minimized down time. |
| + | |
| + | You have a SME 7 production server with hostname 'prodbox‘ running and want to move it to a new hardware. |
| + | |
| + | # Connect the new hardware to your local net, install SME Server and all the contribs package you have installed on the 'prodbox‘. You can assign any unused IP address and hostname, as these are only temporary used. Ensure, that both servers have identical SME version installed. Run 'yum update' on both servers, if necessary. |
| + | # Install and configure Affa (on the new hardware) as described in the examples above and configure a job 'prodbox' to backup your 'prodbox‘ using the 'jobconfig-sample.pl.' file<br>Important is to set these properties;<br><code>'SMEServer'=>'yes',</code><br><code>'RPMCheck '=>'yes',</code><br><code>'status'=>'disabled',</code> |
| + | # Now run the job 'prodbox' manually, while your users can still work on the server 'prodbox'<br><code># affa --run prodbox</code><br>The run may take a long time, depending of the size of the backup. |
| + | # When the run has finished, check the file /var/affa/prodbox/rpms-missing.txt. As the filename indicates, all RPMS installed on 'prodbox‘, but not on this Affa server, are listed there. Install the missing RPMs. |
| + | # Ask all your users to log off. To ensure, that no data will be modified from now on, you may want to stop a couple of services on the 'prodbox‘, e.g. qpstmpd, qmail, crond (because of fetchmail), smb, atalk, httpd. Don't stop mysqld, as this service is required by mysqldump in the pre-backup event. |
| + | # Run the job again<br><code># affa --run prodbox</code><br>This run should be completed quickly, as only the differences compared to the last run are backuped. |
| + | # When this final run has finished, powerdown the 'prodbox‘ (old hardware) and rise the Affa box (new hardware) to a 'prodbox‘ clone.<br><code># affa --rise prodbox</code><br> |
| + | # Reboot the server. Your users can now re-logon. |
| + | |
| + | With this method you should be able to move even a typical 50 Gbyte sized server to a new hardware with downtime less than 20 minutes. The rise time does not really depend on the total files size, but on the number of files and directories. |
| | | |
| | | |