There's a discussion in OpenAM mailing list regarding export-svc-cfg sub-command. This command is related to Backing Up and Restoring OpenAM Configurations in OpenAM Administration Guide.
My friend, Peter, has something to say (he usually does. Ha! *joking*) :
export-svc-cfg and import-svc-cfg aren't necessarily the most trustworthy backup solution for configuration data. An example where things can go wrong is OPENAM-718 and OPENAM-3793. Since my recent encounters with these commands personally I'm more inclined to use OpenDJ's export-ldif command for backup.
This email thread brought me back to an discussion I had with a customer a month back. He was reading the same document from ForgeRock and wanted to implement the same for his backup and restoration procedure.
That's not necessary, I told him. When we implemented the project, we already have a Backup and Restoration procedure in place.
Maybe Azimuth's way of Backup and Restoration procedure looks too old-school, not sexy enough.
1. Backup OpenAM war directory
2. Backup OpenAM var directory (this would already back-up the configuration data in the embedded OpenDJ)
3. Backup OpenDJ data in LDIF format and DB format (for customers with external OpenDJ)
1. Restore OpenDJ data (for customers with external OpenDJ)
2. Restore OpenAM var directory
3. Restore OpenAM war directory
The beauty/concept of embedded OpenDJ has to be appreciated. It's embedded and thus backing up the var directory will be more than sufficient. That's my own opinion.
I'm not here to argue about which approach is better. I'm more of a practical person when it comes to operation. It has to be fast for roll-back/restoration with minimal downtime as much as possible.