Backing up and restoring PostgreSQL
Backup AX Server data on a regular, scheduled basis so that no critical audit data is lost due to technical problems or hardware failures. A planned and verified restore process is also required to ensure data access continuity.
You can backup and restore your production data to a disaster recovery instance of AX Server running on a different machine.
Caution
While PostgreSQL supports online backup and restore procedures while AX Server is running, ACL does not support online backup and restore procedures and recommends that you do not employ this backup method.
PostgreSQL online backup/restore involves database data and not ACL data files. As a result, online backup can result in data corruption and incomplete backups. ACL strongly recommends you stop all AX Server services before backing up your data.
Backup strategies
You can employ one of many backup strategies depending on your IT infrastructure, the tools available to you, and your organization's IT business processes. Strategies run from fully automated and scheduled backups to manual ad hoc backups.
Existing general backups
Incorporate your AX Server backups into existing general backup programs in your organization. This is the most reliable and robust strategy as your backups are performed along with other critical system backups.
For further assistance with this strategy, contact your IT department.
Scripted backups
Backup AX Server on a recurring, scheduled basis using a script. This is also a reliable strategy, but the backup is not done along with other critical systems.
Note
To ensure reliability, thoroughly test any automated processes and schedule backups so they do not conflict with scheduled analytic jobs.
Manual backups
Backup AX Server manually in an ad hoc fashion. This is the least reliable strategy as backup intervals are not scheduled and the process is more prone to human error.
What to backup
Backup and restore procedures must handle all AX Server data in the database and file system.
PostgreSQL database
The database stores security information and configuration information for scheduled jobs, data files, and resource names in the PostgreSQLdata sub-folder.
The default location is App\pgsql93\data. AX Server data is stored in sub-folders while security certificates and configuration files are stored directly in the data folder. Restoring all contents may overwrite new certificates and configuration with older versions.
Note
Depending on how your organization configured the installation of AX Server, the PostgreSQL database may or may not be on the same server as the AX Server application server.
The file system
AX Server stores .fil data files that must be backed up in two Windows folders. The default locations are Data\repository\datafiles and Data\aclse.
Tip
You can locate your data file directories using the AX Server Configuration web application. You need to back up the folders specified in the Data Directory and the Connector Working Directory fields.
Backup AX Server data
After you make sure that no analytic scripts are running on AX Server, stop the services and backup the database and specific folders on the file system.
Before you backup
- Notify all AX Client and AX Web Client users in advance of the backup so that they log out of any ACL GRC Analytics Exchange applications.
- In AX Client, verify that there are no analytic jobs currently running, queued, or scheduled to run during the backup.
- Stop the AX Server services in the following order:
- Analytics Exchange Connector
- Analytics Exchange Service
- Analytics Exchange Database
Backup the server data
- To backup the AX Server database, on the server where PostgreSQL is installed, copy the contents of App\pgsql93\data.
You can copy all files and sub-folders, or just the sub-folders depending on what you intend to backup. Data is stored in the sub-folders.
- To backup the AX Server data files stored in the Windows file system, copy the files in the following folders:
- Data directory the default location is Data\repository\datafiles on the AX Server machine
- Connector working directory the default location is Data\aclse on the AX Server machine
After you backup
Restart all AX Server services in the following order:
- Analytics Exchange Database
- Analytics Exchange Service
- Analytics Exchange Connector
Restore AX Server data
After you make sure that no analytic scripts are running on the AX Server instance you are restoring to, stop the services and restore the backed up database and specific folders on the file system.
Before you restore
- Backup AX Server data.
- Notify all users of the server instance you are restoring on in advance of the restore so that they log out of any client applications.
- In AX Client, verify that there are no analytic jobs currently running, queued, or scheduled to run during the restore.
- Stop the AX Server services in the following order:
- Analytics Exchange Connector
- Analytics Exchange Service
- Analytics Exchange Database
Restore the server data
- To remove the AX Server database, on the PostgreSQL server, delete the contents of the App\pgsql93\data sub-folder.
Caution
If you have not backed up the configuration files and security certificates in the data sub-folder, do not delete them. Just delete the sub-folders within pgsql93\data.
- To remove the AX Server data files stored in the Windows file system, delete the files in the following folders:
- Data directory the default location is Data\repository\datafiles on the AX Server machine
- Connector working directory the default location is Data\aclse on the AX Server machine
- To restore the backed-up data, copy the backup files to the appropriate data folders so that they replace the files you deleted.
After you restore
- Restart all AX Server services in the following order:
- Analytics Exchange Database
- Analytics Exchange Service
- Analytics Exchange Connector
- If you restore on a different server than the instance you backed up, such as a disaster recovery server, reset the activation record:
Delete all records from the activations table in the database.
The activations table contains data specific to the machine on which AX Server was activated, such as the hostname, so the backup instance cannot activate unless this data is cleared.
You can use the pgAdmin GUI to remove this record, for more information see Managing the database on PostgreSQL
- Re-activate AX Server as the appropriate server type on this machine.
For more information about activating AX Server, see Activate AX Server.