Skip to main content

Configure Hot Backup (Physical) for PostgreSQL database on local or shared filesystem

PostgreSQL physical database backup (Hot) on local or shared filesystem.
Physical backup is copying of all the required database files to secondary location using OS command or any other available utility. Physical backup can be taken as hot or cold. The cold backup will be done while database or processes are completely stopped and the database files or directories will be copied to secondary or secure location.
On the other hand, the Hot backup will be done while the database and processes are up and running, application will be connected and using the database. user or application sessions might be doing either DDL or DML operations.
So lets get set go and configure the Hot backup for postgreSQL database on local file system.
Environment details: I have two machines currently configured.
pg01 -> postgreSQL database.
pg03 -> Used in future for pushing the database backup to remote.
Postgresql version -> 9.6.5
PGDATA = /u01/app/postgres/data (Database file location)
The steps are as follows:
1.) Create backup directory either on local or shared filesystem.
      [postgres@pg01 ~]$ mkdir -p /u01/backups/base
      [postgres@pg01 ~]$ mkdir -p /u01/backups/archive

2.) Set the archive parameter in postgresql.conf using your favorite editor and restart the server.
      wal_level = replica (you can set any value other then minimal)
      archive_mode = on
      archive_command = 'rsync -a %p /u01/backups/archive/%f'

3.) export the backup filename either on script or at OS level.
        [postgres@pg01 ~]$ export BACKUP_NAME=$(date '+%Y%m%d%H%M').tar

4.) Start the backup as follows at database level. You can also do the same by connecting to psql.
       [postgres@pg01 ~]$ psql -c "select pg_start_backup('standalone')"
        pg_start_backup
       -----------------
       0/F000028
       (1 row)

5.) Copy the database files excluding the pg_xlog directory using the below command.
[postgres@pg01~]$tar -cv --exclude='pg_xlog/*' ${PGDATA} -f /u01/backups/base/$BACKUP_NAME *

6.) Once copying is completed, stop the backup as follows,
[postgres@pg01 ~]$ psql -c "select pg_stop_backup(), current_timestamp"
NOTICE:  pg_stop_backup complete, all required WAL segments have been archived
 pg_stop_backup |               now             
----------------+----------------------------------
 0/F01B410      | 2017-12-29 18:38:42.647298+05:30
(1 row)
[postgres@pg01 data]$

7.) Goto backup location and check the tar file will be available.
[postgres@pg01 data]$ cd /u01/backups/
[postgres@pg01 backups]$ ls -ltr
total 8
drwxrwxr-x. 2 postgres postgres 4096 Dec 29 17:19 base
drwxrwxr-x. 2 postgres postgres 4096 Dec 29 18:38 archive
[postgres@pg01 backups]$ cd base/
[postgres@pg01 base]$ ls -ltr
total 66380
-rw-rw-r--. 1 postgres postgres 67973120 Dec 29 18:38 1712291715.tar
[postgres@pg01 base]$
Check the archive or WAL files are also available.
[postgres@pg01 backups]$ cd archive/
[postgres@pg01 archive]$ ls -ltr
-rw-------. 1 postgres postgres 16777216 Dec 29 18:37 00000001000000000000000E
-rw-------. 1 postgres postgres 16777216 Dec 29 18:38 00000001000000000000000F
-rw-------. 1 postgres postgres      294 Dec 29 18:38 00000001000000000000000F.00000028.backup
[postgres@pg01 archive]$ 

8.) Copy the postgres.conf, pg_hba.conf and archive files and bundle with backup file.
   [postgres@pg01 ~]$ tar -rf $BACKUP_NAME /u01/backups/archive

9.) Create the recovery.conf file which can be used to recover the database.
echo "restore_command = 'cp /u01/backups/archive/%f %p'" > recovery.conf
echo "recovery_end_command = 'rm -R /u01/backups/archive' " >> recovery.conf

10.) Add the recovery.conf file into backup bundle.
 [postgres@pg01 ~]$ tar -rf $BACKUP_NAME /u01/backups/recovery.conf

11.) Store the backup file somewhere on secure location, if not on NFS.

Note: This method only help you to restore and recover the database until the last backup WAL file. You can't perform the PITR.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Recovering the database from standalone backup

Now some disaster is happens and you need to restore the database from backup. Follow the below steps:
1.) Stop the server, if its already running.
2.) Make sure you have sufficient free space available to restore the database. If you are restoring on the same server, remove all the existing files and subdirectories from the cluster and any directory which is used for tablespace.
3.) restore the datafiles from backup.

 [postgres@pg01 ~]$ cd /u01/backups/base
 [postgres@pg01 ~]$ ls -ltr 
-rw-rw-r--. 1 postgres postgres 67973120 Dec 29 18:38 1712291715.tar
[postgres@pg01 ~]$ tar -xvf 1712291715.tar -C /u01/app/postgres/data

Make sure recovery.conf file exist in the data directory, if file doesn't exist copy the file to data directory before starting the cluster. Also make sure if you are using tbl_spc, the symbolic link must exist.
4.) Cleanup the pg_xlog directory, if you have not already excluded during backup.
5.) start the server, the server will go into recovery mode and start reading the WAL files which require for recovery. Once the recovery if complete ,the recovery.conf file will be renamed to recovery.done. this is to avoid the server go back into recovery during next restart. The server will also move the backup_label file to backup_label.old.
6.) Verify the contents of database to see the recovery is done.


Comments

Popular posts from this blog

ORA-29913: error in executing ODCIEXTTABLEOPEN callout

While running oracle datapatch in 12c, ORA-29913 error raised due to corrupted external table. The error you might see while running the datapatch after patching. $ ./datapatch -verbose Connecting to database...OK Determining current state... Currently installed SQL Patches: 18522516 DBD::Oracle::st execute failed: ORA-04063: package body "SYS.DBMS_QOPATCH" has errors ORA-06508: PL/SQL: could not find program unit being called: "SYS.DBMS_QOPATCH" ORA-06512: at line 4 (DBD ERROR: OCIStmtExecute) [for Statement "DECLARE x XMLType; BEGIN x := dbms_qopatch.get_pending_activity; ? := x.getStringVal(); END;" with ParamValues: :p1=undef] at /u01/app/oracle/product/12.1.0.2/db_1/sqlpatch/sqlpatch.pm line 1293. or Connecting to database...OK catcon: ALL catcon-related output will be written to /u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_53150146_2017_05_09_21_37_14/sqlpatch_catcon__catcon_53150146.lst catcon: See /u01/app/oracle/cfgtoollogs/sqlpatc

datapatch failed with error ORA-20009: Job Load_opatch_inventory_1execution failed

Today we have hit with issue while applying the OCT-2017 PSU. The Cluster and RDBMS software patched successfuly but while running the datapatch automation failed with below error. ERROR: Can't locate XML/Simple.pm in @INC (@INC contains: /u01/app/oracle/product/12.1.0.2/db_1/sqlpatch /u01/app/oracle/product/12.1.0.2/db_1/rdbms/admin /u01/app/oracle/product/12.1.0.2/db_1/sqlpatch/lib /u01/app/oracle/product/12.1.0.2/db_1/perl/lib/site_perl/5.14.1/x86_64-linux-thread-multi /u01/app/oracle/product/12.1.0.2/db_1/perl/lib/site_perl/5.14.1 /u01/app/oracle/product/12.1.0.2/db_1/perl/lib/5.14.1/x86_64-linux-thread-multi /u01/app/oracle/product/12.1.0.2/db_1/perl/lib/5.14.1 .) at /u01/app/oracle/product/12.1.0.2/db_1/sqlpatch/sqlpatch.pm line 173. BEGIN failed--compilation aborted at /u01/app/oracle/product/12.1.0.2/db_1/sqlpatch/sqlpatch.pm line 173. Compilation failed in require at /u01/app/oracle/product/12.1.0.2/db_1/sqlpatch/sqlpatch.pl line 64. BEGIN failed--compilatio

datapatch failed with ORA-27477: "SYS"."LOAD_OPATCH_INVENTORY_X" already exists

We have received the below error while working on the 6-node cluster patching. The patch has been applied on software GRID and RDBMS on all the node but the datapatch execution is failed with ORA-27477. rac06:dbp01:/u01/app/oracle/product/12.1.0.2/database/OPatch$ ./datapatch -verbose SQL Patching tool version 12.1.0.2.0 on Wed Oct 25 12:55:45 2017 Copyright (c) 2016, Oracle. All rights reserved. Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_12298_2017_10_25_12_55_45/sqlpatch_invocation.log Connecting to database…OK Bootstrapping registry and package to current versions…done Queryable inventory could not determine the current opatch status. Execute ‘select dbms_sqlpatch.verify_queryable_inventory from dual’ and/or check the invocation log /u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_12298_2017_10_25_12_55_45/sqlpatch_invocation.log for the complete error. Prereq check failed, exiting without installing any patches. Solution:  The