After performing the configuration process described in Chapter 4, you can begin the BART backup and recovery management process.
1. Run the CHECK-CONFIG subcommand without the -s option. When used without specifying a server with the -s option, the CHECK-CONFIG subcommand checks the parameters in the global section of the BART configuration file.
2. If you have not already done so, run the INIT subcommand to finish creation of the BART backup catalog, which results in the complete directory structure to which backups and WAL files are saved. This step must be done before restarting the database servers with enabled WAL archiving, otherwise the copy operation in the archive_command parameter of the postgresql.conf file or the postgresql.auto.conf file fails due to the absence of the target archive directory. When the directory structure is complete, the lowest level subdirectory named server_name/archived_wals, referred to as the archive path, should exist for each database server.
3. Start the Postgres database servers with archiving enabled. Verify that the WAL files are appearing in the server_name/archived_wals archive paths for each database server. (The archiving frequency is dependent upon other postgresql.conf configuration parameters.) Check the Postgres database server log files to ensure there are no archiving errors. Archiving should be operational before taking a backup in order to ensure that the WAL files that may be created during the backup process are archived.
5. Run the BART CHECK-CONFIG subcommand for each database server with the -s option specifying the server name. This ensures the database server has been properly configured for taking backups.
• Verify the checksum of the full base backups using the VERIFY-CHKSUM subcommand.
• Display database server information with the SHOW-SERVERS subcommand.
• Display backup information with the SHOW-BACKUPS subcommand.
• Perform the BACKUP subcommand to create additional full base backups or incremental backups.
• Establish the procedure for using the MANAGE subcommand to enforce the retention policy for backups. This may include using cron jobs to schedule the MANAGE subcommand.
1. Shut down the database server using the appropriate method such as service ppas-x.x stop, systemctl stop edb-as-x.x, POSTGRES_INSTALL_HOME/bin/pg_ctl stop –D data_directory, etc.
2. Decide if you want to restore the database cluster and tablespace files a) to new, empty directories; or b) to reuse the existing database cluster directories. For option (a), create the new directories with the appropriate directory ownership and permissions. For option (b), delete all the files and subdirectories in the existing directories, but it is strongly recommended that you make a copy of this data before deleting it. Be sure to save any recent WAL files in the pg_xlog subdirectory that have not been archived to the BART backup catalog server_name/archived_wals subdirectory.
3. Run the BART SHOW-BACKUPS -s server_name subcommand to list the backup IDs and backup names of the backups for the database server. You will need to supply the appropriate backup ID or backup name with the BART RESTORE subcommand unless you intend to restore the most recent backup in which case the -i option of the RESTORE subcommand for specifying the backup ID or backup name may be omitted.
4. Run the BART RESTORE subcommand with the appropriate options. The backup is restored to the directory specified by the -p restore_path option. In addition, if the RESTORE subcommand -c option is specified or if the enabled setting of the copy_wals_during_restore BART configuration parameter is applicable to the database server, then the required, archived WAL files from the BART backup catalog are copied to the restore_path/archived_wals subdirectory. Note: Be sure the restore_path directory and its subdirectories and files are owned by the proper Postgres user account (for example, enterprisedb or postgres). Also be sure that only the Postgres user account has access permission to the restore_path directory. Make the appropriate adjustments where needed such as with the command, chown -R enterprisedb:enterprisedb restore_path or chmod 700 restore_path.
5. Copy any saved WAL files from Step 2 that were not archived to the BART backup catalog to the restore_path/pg_xlog subdirectory.
6. If generated for point-in-time recovery, verify that the recovery.conf file created in the directory specified with the RESTORE subcommand’s -p restore_path option was generated with the correct recovery parameter settings. Note that if the RESTORE subcommand -c option is specified or if the enabled setting of the copy_wals_during_restore BART configuration parameter is applicable to the database server, then the restore_command parameter retrieves the archived WAL files from the restore_path/archived_wals subdirectory that was created by the RESTORE subcommand, otherwise the restore_command retrieves the archived WAL files from the BART backup catalog.
7. The BART RESTORE subcommand disables WAL archiving in the restored database cluster. If you want to immediately enable WAL archiving, modify the postgresql.conf file by deleting the archive_mode = off parameter that BART appends to the end of the file.
8. Start the database server, which will then perform the point-in-time recovery operation if a recovery.conf file was generated.