07-19-2012 01:28 AM - edited 03-10-2019 07:19 PM
All,
Can I check I've understood the ACS backup and restoration procedure? Am I right in thinking:
Oh, and one last bonus question... if I still have a working ACS left after the primary dies, is it not just easier to promote the survivor to primary and then add the replacement in as a secondary and let replication restore the configs? Perhaps re-promote the new box to primary afterwards?
Cheers all!
Solved! Go to Solution.
07-19-2012 06:44 AM
Paul,
Here are the answers:
1: The scheduled backup only backup the ACS configuration data, so the command equivalent is "acs backup....", "backup ..." backs up both the cli (ADE-OS) and the acs configuraiton.
2. No, the ACS backups only backup the database that covers the ACS configuration, the monitoring and view database is covered in the purging and full backup settings in the monitoring configuration page. So if you restore this backup on a rebuilt box then you will not have any logs, it wil be like a fresh box configured with all your policies and ACS related configuration.
3. Yes, it is entirely seperate from the purging operations. If you are looking to rebuild your ACS then you will have to create a seperate full db backup of the view database and then you can restore that once your ACS is rebuilt.
I have seen the scenario before where you can not register a secondary node if the primary node was to ever go down. I dont know if this has been fixed in the recent code, because the secondary ACS needs to contact the primary ACS in order to make the switch. If you run into an issue where this is the case please make sure your databases are up to date and you can have Cisco TAC flip the status in the db for you. If you have the luxury to test I would suggest going through these specific test.
In the guide here - http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.3/user/guide/admin_operations.html#wp1066176
This only specifies a secondary instance.
Thanks,
Tarik Admani
*Please rate helpful posts*
07-19-2012 07:32 AM
Paul,
You are correct, the ADE-OS is pretty much static but if you ever needed to all you do is create the ip and repository that the backups are stored under, and then restore that backup that has the ADE-OS backup included, you can then pick a later scheduled backup in order to update the ACS configuration database then afterwards.
Exactly when it comes to promoting a primary the secondary ACS needs to contact the primary, so if you were test this feature I would either shut the port that the primary ACS is connected to, or setup a port based ACL which will block all communication to this device and see if it does take the primary role. I know this was the case in earlier releases where this would not work.
Thanks,
Tarik Admani
*Please rate helpful posts*
07-19-2012 06:44 AM
Paul,
Here are the answers:
1: The scheduled backup only backup the ACS configuration data, so the command equivalent is "acs backup....", "backup ..." backs up both the cli (ADE-OS) and the acs configuraiton.
2. No, the ACS backups only backup the database that covers the ACS configuration, the monitoring and view database is covered in the purging and full backup settings in the monitoring configuration page. So if you restore this backup on a rebuilt box then you will not have any logs, it wil be like a fresh box configured with all your policies and ACS related configuration.
3. Yes, it is entirely seperate from the purging operations. If you are looking to rebuild your ACS then you will have to create a seperate full db backup of the view database and then you can restore that once your ACS is rebuilt.
I have seen the scenario before where you can not register a secondary node if the primary node was to ever go down. I dont know if this has been fixed in the recent code, because the secondary ACS needs to contact the primary ACS in order to make the switch. If you run into an issue where this is the case please make sure your databases are up to date and you can have Cisco TAC flip the status in the db for you. If you have the luxury to test I would suggest going through these specific test.
In the guide here - http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.3/user/guide/admin_operations.html#wp1066176
This only specifies a secondary instance.
Thanks,
Tarik Admani
*Please rate helpful posts*
07-19-2012 07:20 AM
Tarik,
Thanks for this. So...
I'm not thinking of registering a secondary but promoting an existing to primary, or is the issue still the same? That the primary must be available to relinquish control? I might have a go at this in the lab shortly and see what happens. Will report back.
Thanks again!
07-19-2012 07:32 AM
Paul,
You are correct, the ADE-OS is pretty much static but if you ever needed to all you do is create the ip and repository that the backups are stored under, and then restore that backup that has the ADE-OS backup included, you can then pick a later scheduled backup in order to update the ACS configuration database then afterwards.
Exactly when it comes to promoting a primary the secondary ACS needs to contact the primary, so if you were test this feature I would either shut the port that the primary ACS is connected to, or setup a port based ACL which will block all communication to this device and see if it does take the primary role. I know this was the case in earlier releases where this would not work.
Thanks,
Tarik Admani
*Please rate helpful posts*
07-19-2012 08:13 AM
Great stuff, many thanks for such clear and useful answers!
07-19-2012 08:41 AM
OK, tried it in the lab and the Secondary ACS took the Primary roll just fine with the previous Primary shutdown. This page here seems to suggest it's an allow operation:
It just warns not to promote two at the same time to primary! I'll reimage the old-primary and see if it'll join the group OK.
07-19-2012 08:45 AM
Sounds great! Also keep in mind that if the old primary ACS shows up as a secondary node under the new primary that the entry is deleted prior to rejoining the reimaged node to the deployment, it will error out because the database already has an entry for this old unit.
thanks,
Tarik Admani
*Please rate helpful posts*
07-19-2012 09:36 AM
Ha, funny you should mention that. I accidentally started the wrong VM and instead of bringing up a plain ACS install I brought back the old primary.
For anyone else who reads this...
At this point, both thought they were primary and both thought the other was it's secondary. Replication had stopped (as you might expect...).
As you mentioned, I could not make the old-primary a secondary as there was already an entry for it on the new-primary. I deleted and it joined A-OK. I then re-promoted old-primary to primary to get back to where we started and simulate the full cycle of losing the Primary, promoting the secondary until new hardware arrives, re-connecting them for replication and then re-promoting the original primary.
I did notice I ended up with no Log Collector after this. I think the right thing to have done in the real world would have been to make the new-primary the log collector at failure and then consider moving it back to old-primary once restored.
Thanks again.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide