Backing up and Restoring ACS 5.x

[Paul Masterton]

All,

Can I check I've understood the ACS backup and restoration procedure? Am I right in thinking:

1. A backup run from exec as "backup <filename> repository <repository name>" is the same command run automatically by "System Administrator -> Scheduled Backups" in the GUI, just scheduled for me...
2. That backup is enough to completely restore ACS to its state at the time of the backup, including ACS config (Users, Devices, NDGs, etc.) and the View database (reports, historical data, etc.)
3. It's entirely separate from the backups ACS View makes as part of it's purging action. (I only need those if I want to go way back in time, I don't need them to restore a functioning ACS with the recent reports and logs)

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!

[Tarik Admani · Accepted solution]

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.

http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.3/user/guide/admin_operations.html#wp1076270

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*

[Paul Masterton]

Tarik,

Thanks for this. So...

1. That makes sense. I guess the ADE-OS config is pretty much static once the box is in anyway? It's what, IP, NTP and repository settings and that's about it? I guess we just need to remember to back it up if we ever make any such minor changes?
2. D'oh! That was my first understanding then something I read talked me out of it. So, if I want to replace a lost ACS I would: install ADE-OS, configure an IP and repository so I can reach my backups and then restore my ADE-OS backup, restore my ACS backup and finally (optionally) the reporting database backup?

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!

[Tarik Admani · Accepted solution]

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*

[Paul Masterton]

Great stuff, many thanks for such clear and useful answers!

[Paul Masterton]

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:

http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.2/user/guide/admin_operations.html#wp1066163

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.

[Tarik Admani]

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*

[Paul Masterton]

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.