PostgreSQL Backup

Updated May 26, 2023

Introduction to PostgreSQL Backup

If you are using the PostgreSQL database in the production environment for your clients, you need to ensure that your database is always working fine and available 24 * 7. For the availability of the database, you must often keep a backup of your client’s database. To ensure data restoration in the event of database corruption, crashes, or loss, you must have the ability to restore the data. For this reason, PostgreSQL provides us with a facility to keep the backups using three methods –

Methods of PostgreSQL Backup

Three methods of PostgreSQL backup are given below:

1. SQL Dump

There is a facility to dump the database using the pg_dump utility. The advantage of this utility is that it is not server-side version specific and can work even on the machine having different architectures. For example, if you dump your database from a 32-bit architecture machine and then use it in a 64-bit machine, it will work fine.

2. File System-Level Backup

As we all know, PostgreSQL stores its database data in files and directory structures.The idea behind file system-level backup is to store the backup of these files and then restore them whenever required. However, it has several disadvantages, one of which is the requirement to close the database system. In other words, you need to shut down the server while taking the backup. You can only utilize this type of backup methodology when you need to take a complete backup and restore the database in its entirety. You have the flexibility to store the file data in any desired format. One of the techniques is –

tar -cf mydatabasebackup.tar /etc/psql/12/data

that exports the data in the tar file on the specified location – /etc/psql/12/data

3. Continuous Archiving

This methodology combines the File system-level backup methodology and Write Ahead Logs (WAL) stored in pg_xlog. The database maintains logs for each and every transaction performed on it. To determine the successful completion and commitment of a transaction, the system maintains a checkpoint. Whenever a crash occurs or data is lost. To recover the database, you can restore the data stored in the file-based system and then apply the logs from that point until the checkpoint to bring the database to its current state. However, this process is a bit clumsy and complex but provides some benefits over the other two, as discussed previously.

In the upcoming session, we will briefly discuss the SQL dump method, which we consider the most convenient and preferred approach.

Explanation of SQL Dump

Dumping your database frequently would be best to have the updated backup available. When restoring the backup, the database will revert to the state at which the dump file was created using pg_dump. Another advantage of using the pg_dump utility instead of file-level backups and archiving is that it is not specific to the version of the PostgreSQL server.

Furthermore, the database operations continue to run while pg_dump is in progress and not locked. However, it is important to note that certain operations, like ALTER TABLE, which are related to structural changes, will be blocked during the execution of pg_dump. You must specify external -o in the pg_dump command if your database schema depends on OIDs such as foreign keys. For this, you will also need to dump the OIDs.

Syntax:

pg_dump databaseName > outputFile

• pg_dump: It is the utility program provided in PostgreSQL to store the current state of the database into a file containing commands which, when run on the database server, will recreate the state of the database when it was dumped using the same. To run it, you need to execute pg_dump as a client-side program through the Linux command line prompt.
• databaseName: It is the database name you want to dump.
• outputFile: It is the file name that has to be created after the dumping is finished.

The execution of the pg_dump process is limited to the superuser login because only the superuser has the necessary permissions to read all databases and tables. Although, you do have a facility to dump the database remotely. By default, the environment variables PGHOST, PGPORT, and PGUSER consider the localhost, port 5432, and the username associated with the operating system as the default values for connecting to the database.

You can change the PGHOST and PGPORT by using the options -h for the host and -p for the port in the pg_dump command. To change and override the PGUSER variable, you can use the -U option in the statement. Client authentication mechanisms confirm all of this.

Example:

pg_dump postgres > myBackupFile

Check whether the file is created successfully. Let us use the ls command, which lists all the files in the current directory –

ls

Output:

Now, we have a ready backup file named “myBackupFile” that has been dumped.

Let us see the contents of the Postgres database by checking all its tables with the help of the \dt command.

\c postgres
\dt

Output:

So, it contains three tables which we will drop one by one. By using the commands

drop table educba;
drop table teams cascade;
drop table developers;

and then further check whether all of them are deleted by \dt command.

\dt

Output:

So, now the database Postgres does not contain any tables in it. Now, we will learn how to restore the data to the database.

Restoring the Dump

Having a backup file allows us to restore the database at any time, which proves helpful in situations where the database becomes corrupted or is lost.However, it would be best if you considered some things before restoring. The database you are trying to restore should be on the server. If not, then you should create the database with the help of the command

• createdb -T template0 Postgres

in our case. Since the database already exists, you can verify its presence by using the command \l, which displays the following output from the database server. Therefore, there is no need to execute the createdb command now.

\l

Output:

The other thing is to ensure that the database you are restoring should already consist of all the users with the right to it. In our case, the Postgres user owns the Postgres database. Hence, a database server should already have a user named Postgres, or it will give an error while restoring. You can check this by firing the command –

SELECT usename FROM pg_catalog.pg_user;

which results in the following –

Now, the Postgres database and user are already in my database server. I can go for restoring the database using the command –

psql postgres < myBackupFile;

as the syntax of restoring the dump is

psql empty_database < backup_file

where empty_database is the database you want to restore, and backup_file is the file resulting from the pg_dump command.

psql postgres < myBackupFile;

Output:

Now, if we check the contents of the Postgres database using the command \dt, it gives the output as –

\dt

Output:

Also, the contents of all the tables are restored correctly –

select * from developers;

Output:

Handling Restoration Errors

In PostgreSQL, the restoration process persists even if an error occurs in between. It only tells about them at the end of the completion of the restore. In this case, the database is restored incompletely. If you want to stop the restoration process on error occurrence, you can use –

psql --set ON_ERROR_STOP=on postgres < myBackupFile

ON_ERROR_STOP option helps you to stop the restoration process whenever the error occurs. To restore the database in a transactional manner, where only the entire database is restored or no changes are made, you can use the “-1” or “–single-transaction” option. This option ensures that the restoration process operates as a transactional process.

psql -1 postgres < myBackupFile

For dumping all the databases in the current database server to a file, you can use the pg_dumpall utility program and provide the default database while restoration.

Conclusion – PostgreSQL Backup

We can dump our database so that a backup is available in the near future to restore the database in case of any problem with data available from the database using pg_dump in PostgreSQL. You can utilize other methods, including File system level backup and Continuous archiving, to maintain backups of your PostgreSQL database.

Recommended Articles

We hope that this EDUCBA information on “PostgreSQL Backup” was beneficial to you. You can view EDUCBA’s recommended articles for more information.

1. PostgreSQL round
2. PostgreSQL GRANT
3. Inner Join in PostgreSQL
4. PostgreSQL Auto Increment