Topic: [ANNOUNCEMENT] Turn SME7 into a dedicated backup server

[m]

Many thanks for this excellent piece of software and for you ingenuity!

and many thanks to you for the praise.

[m]

Now a problem... seems I can't undo the rise.  On the 'risen' Affa server, now self identified as mail3:

Code: [Select]

[root@mail3 ~]# affa --undo-rise
Error log:
Fri May 18 21:01:01[START.5267]: Running /sbin/e-smith/affa --undo-rise
Fri May 18 21:01:01[undo-rise.5267]: Error: No server base backup found.
Fri May 18 21:01:01[undo-rise.5267]: Exiting. <<<
Affa exited with errors.


J have tested the rise and undo-rise again on SME 7.1.3. Both work as expected.
My guess is, that you have run a '--rise' while the server configuration was in an unclean state with the BootstrapConsole flag set. This can happen, if you change the configuration (via the Console) and then do not run the required reboot.  
With BootstrapConsole flag set, Affa skips its own backup, as it assumes that a rise has just run. (Otherswise Affa would backup the just restored data)

[markseymour]

Michael,

Perhaps some further explanation of the '--rise' and '--undo-rise' processes would be a useful addition to the wiki howto, along with an example that includes both, and emphasizes the need to reboot, and when. I am confused as to where in the sequence of events that manual 'reboots' by the admin are required for things to work correctly.

My guess is, that you have run a '--rise' while the server configuration was in an unclean state with the BootstrapConsole flag set. This can happen, if you change the configuration (via the Console)....

For example, what? -- A server configuration change via the console....  such as, a change to Affa config? to an Affa job? to SME? to Linux config apart from SME? I'm not following your meaning, and I would like to understand. I don't think I made any configuration changes between the time that I started the successful backup and the time that I did the 'affa --undo-rise'.

...and then do not run the required reboot.  
With BootstrapConsole flag set, Affa skips its own backup,....

I'm sorry, ... skips *making* its own backup, or skips *using* its own backup made previously?  From the rest of your sentence, I think you mean skips making its own backup.

as it assumes that a rise has just run. (Otherswise Affa would backup the just restored data)

But (I think) /var/log/affa shows that a local backup was made as part of the --rise that I did.

Code: [Select]

Fri May 18 20:39:31[START.17161]: Running /sbin/e-smith/affa --rise mail3prod
...
<snip>
...
Fri May 18 20:39:42[mail3prod.17161]: Backup the affa server base (this host).
Fri May 18 20:39:43[mail3prod.17161]: Exec Cmd: /sbin/e-smith/affa --run AFFA.sme2.guildassociates.com-192.168.111.2
Fri May 18 20:39:44[START.17333]: Running /sbin/e-smith/affa --run AFFA.sme2.guildassociates.com-192.168.111.2
Fri May 18 20:39:45[AFFA.sme2.guildassociates.com-192.168.111.2.17333]: Starting job (localhost,scheduled)
Fri May 18 20:39:45[AFFA.sme2.guildassociates.com-192.168.111.2.17333]: Description: for internal use only
Fri May 18 20:39:45[AFFA.sme2.guildassociates.com-192.168.111.2.17333]: Shifting backup archives...
Fri May 18 20:39:45[AFFA.sme2.guildassociates.com-192.168.111.2.17333]: Nothing to be done.
Fri May 18 20:39:45[AFFA.sme2.guildassociates.com-192.168.111.2.17333]: signaling pre-backup event on localhost
Fri May 18 20:39:48[AFFA.sme2.guildassociates.com-192.168.111.2.17333]: Running rsync...
Fri May 18 20:39:55[AFFA.sme2.guildassociates.com-192.168.111.2.17333]: writing /var/affa/AFFA.sme2.guildassociates.com-192.168.111.2/scheduled.0/.AFFA-REPORT
Fri May 18 20:39:55[AFFA.sme2.guildassociates.com-192.168.111.2.17333]: Job (localhost,scheduled) finished.
Fri May 18 20:39:55[AFFA.sme2.guildassociates.com-192.168.111.2.17333]: Exiting. <<<
Fri May 18 20:39:55[mail3prod.17161]: Exec Out: exitstatus=0

The example in the howto entitled 'Moving a SME 7 server installation to a new hardware using the Affa rise feature' is the one place I see a mention of a need to manually reboot.  This (step 8) comes immediately after the '# affa --rise prodbox' in step 7.  Is this the reboot that I missed? I'm fairly certain that I did not reboot the Affa server after the --rise command, as it reboots itself in the process of rising, and I thought that was it.  Is this what I missed or is there something else?

Finally,  two more questions:

1) Do I assume correctly that the only path for my current *risen* Affa server to become an Affa backup server again is to  start over?

2) Do I assume correctly that upon installing SME, Affa, and additional contribs, that I must configure certain contribs, (I'm thinking of RoundCube) on the Affa server as I would on a new source server?  Or should I expect the configuration will be saved in the backup of the source server, and used when I restore or --rise? In case you are not familiar with where the RoundCube config stores things, Dungog has brief but complete setup instructions here: www.dungog.net/sme/webapp.php#roundcube

Thanks for your terrific work on this, and for your answers.

Mark

[m]

Mark,
would please update to version 0.3.2 as soon as it has appeared on the mirrors and run a --undo-rise again?
I have found and fixed a bug. Should work now.

[m]

2) Do I assume correctly that upon installing SME, Affa, and additional contribs, that I must configure certain contribs, (I'm thinking of RoundCube) on the Affa server as I would on a new source server?  Or should I expect the configuration will be saved in the backup of the source server, and used when I restore or --rise? In case you are not familiar with where the RoundCube config stores things, Dungog has brief but complete setup instructions here: www.dungog.net/sme/webapp.php#roundcube

When you want the Affa server to take over and become your productionserver any time, it is required to have on both machines the same contribs packages installed. The RPMCheck property helps you doing a comparison. It is not required to configure the contribs on the Affa server. A contrib package should be designed in way, that it is automatically reconfigured after a full restore. It should store all configuration data under pathes, which are included in a standard backup. And it should expand all configuration files from its templates during the post-upgrade event.
The Affa rise feature is identical to a restore from a tape. The only differences are, that it is much faster and you need not reconfigure the NICs settings and therefore can be run remotly over the network.

[mmccarn]

I posted a while back about using affa to backup a remote windows system running cygwin.  I eventually found lots of posts indicating that cygwin has insurmountable problems with long path names, and decided this could be my problem... Since the exact same AFFA settings work fine with the ubuntu appliance I setup at the other end, I think I was right about cygwin...

My questions now are:

a) Is there any way to pre-build the first backup?  The remote office isn't too far away; I could go there and get a copy of the backup data the first time to avoid the 36 - 48 hours required to download it...

b) I originally set up this job to backup to /var/affa; now I've connected a USB drive and moved /var/affa/<JOB> folder to it (and modified the affa job to use the new path) - but 'affa --list-status...' shows 'Incomplete' for the 'scheduled.0' backup job, and shows "?" for 'files' & 'size' for all backups as well as for 'disk usage' for 'scheduled.0'.  Is there a way to re-build the affa-report db for this backup job,  can I ignore this situation, or do I need to delete this job and start over?

(I have just upgraded to 0.3.2).

[m]

I think I was right about cygwin...

Could be. I have also encountered difficuiltiies to run rsync on cygwin. In my case, the rsync processes on the cygwin machine often hang unresponsive.

a) Is there any way to pre-build the first backup?  The remote office isn't too far away; I could go there and get a copy of the backup data the first time to avoid the 36 - 48 hours required to download it...

that is an easy job..

either

you run the very first backup with the Affa box located in the LAN of the remote office and then move it to your backup location. If you havn't a VPN. you only need to adjust the remoteHostname to the WAN IP of the remote office.

or

you connect an USB drive to your production server in the remote location and run the backup to the external drive, as described in the wiki docs.
Then connect und mount the drive to the Affa server and copy the archive directory using the tar command:

Code: [Select]


# cd /mnt/affadevice/
# tar -cf - prodbox | tar -C /var/affa -xf -


assuming that the jobname is prodbox and the drive is mounted on /mnt/affadevice

b) I originally set up this job to backup to /var/affa; now I've connected a USB drive and moved /var/affa/<JOB> folder to it (and modified the affa job to use the new path) - but 'affa --list-status...' shows 'Incomplete' for the 'scheduled.0' backup job, and shows "?" for 'files' & 'size' for all backups as well as for 'disk usage' for 'scheduled.0'.  Is there a way to re-build the affa-report db for this backup job,  can I ignore this situation, or do I need to delete this job and start over?

you probably have used the cp command and not copied the dot-file .AFFA-REPORT

use the tar command

[markseymour]

Mark,
would please update to version 0.3.2 as soon as it has appeared on the mirrors and run a --undo-rise again?
I have found and fixed a bug. Should work now.

Michael,

I'm fairly new to all this. Do I use yum update to do this?  What command syntax please?

Thanks,

Mark

[markseymour]

I should have noted that I originally downloaded, then installed with yum localinstall

[m]

I'm fairly new to all this. Do I use yum update to do this?  What command syntax please?

Code: [Select]

yum localinstall smeserver-affa-0.3.2-0.noarch.rpm

[markseymour]

Michael,

What do you envision as the best approach to returning a 'risen' Affa server to standard Affa backup server, after the repaired or replaced source server is ready?  My question is really about the data that has accumulated (email, ibay files, etc.) on the Affa server while it was taking the place of the source server, but it is desired that the Affa server go back to its backup role, and the data accumulated be retained, and restored to the repaired or replaced source server.

Mark

[markseymour]

'affa --undo-rise'  successful after update to smeserver-affa-0.3.2-0!!!  

[m]

What do you envision as the best approach to returning a 'risen' Affa server to standard Affa backup server, after the repaired or replaced source server is ready?  My question is really about the data that has accumulated (email, ibay files, etc.) on the Affa server while it was taking the place of the source server, but it is desired that the Affa server go back to its backup role, and the data accumulated be retained, and restored to the repaired or replaced source server.

Mark,
regard your 'risen' Affa server as your production server, which it is in fact now. Forget the 'sleeping' Affa backup function for a moment. Setup your new hardware following the instructions in chapter 'Moving a SME 7 server installation...' in the Wiki.
Now, as the production server is up and running, you can make the the Affa server a backup server again. Power it on and run affa --undo-rise, which deletes all the no longer needed production data and restores the Affa setup.  All backup archives are still there and Affa will backup your (new) production server against the last scheduled.0 archive. It's harder to explain, than doing it

[m]

Affa version  0.4.0 is available.
This version has the new functions --rename-job and  --move-archive. Please note, that the syntax of --send-keys has changed. See Wiki for further information.

[markseymour]

Michael,

It's harder to explain, than doing it

Quite so!  After re-reading 'Moving a SME 7 server installation...' in the wiki, in reference to your comment

regard your 'risen' Affa server as your production server....

all is clear.

Thank you!

Mark