Using

Suggest edits

These use cases show how backups are taken and restored from EDB Postgres Advanced Server using Cohesity DataProtect for PostgreSQL.

Setting a protection policy with Cohesity DataProtect for PostgreSQL

Cohesity has standard protection policies that are available when you install the software. However, you can also create your own policies to back up your data. These policies are a reusable set of settings that define how and when objects are protected, replicated, and archived.

Create a standard policy

  1. In the Cohesity dashboard, select Data Protection > Policies.

  2. At the top-right of the Policy page, select Create Policy.

  3. Specify a policy name for your protection policy.

    Cohesity Create Protection Policy

  4. Specify all the options for when you want backups captured.

    The options section is highly customizable. Select More Options to view the rest of the options, such as Periodic Full Backups, Replications, Archives, and Log Backups.

    Cohesity Backup Options

  5. After you specify all of your options for your backup policy, select Create.

    Your policy is then visible in the list of policies on the Policies page.

Protect an EDB Postgres Advanced Server source with a policy

  1. From the Cohesity dashboard, select Data Protection > Protection.

  2. At the top-right of the page, select Protect, and then select Universal Data Adapter.

    Cohesity EDB Advanced Server Protection

  3. From the Source menu, select the EDB Postgres Advanced Server source that you registered.

    Cohesity New Protection

  4. In the Objects section, specify a name for the server you want to protect. This name doesn't affect the server that's being backed up. Cohesity uses it to help track your backups.

    Cohesity Object Name

  5. In the Protection Group field, give your source a unique protection name that you can identify.

    Cohesity Protection Group Choice

  6. In the Policy field, from the list, select the policy that you created.

    Cohesity Protection Policy Choice

  7. Check the settings that appear. At the bottom, select Additional Settings to make sure you have all the appropriate settings for your protection group. After you review and adjust your selections, select Protect.

    Cohesity Protection Additional Settings

    Cohesity Protection More Additional Settings

  8. After you protect your sources, they appear on the main Protection page.

    • Select a specific source to see the various backup runs that were set during policy creation.
    • Select a run, and then select the name in the Objects list to view the logs from that run.

    Cohesity Protection Page Overview

    Cohesity Protection Details

Restore an EDB Postgres Advanced Server Instance from a Cohesity protection run

You can restore an EDB Postgres Advanced Server instance to the same EDB Postgres Advanced Server or to a different server. Currently, the restores are full database restores. Granular restores aren't supported yet.

Recovery script arguments are an important piece of the recovery process. They define script parameters for your EDB Postgres Advanced Server recovery. The restore script argument is - -target-dir=<path>, where <path> is the path on the target cluster where you want to restore the data.

EDB Postgres Advanced Server database prerequisites before recovery initiation

Before you can recover your EDB Postgres Advanced Server instance, make sure that the server isn't running. Verify that your server is stopped. If it's running, stop it.

For example:

  1. Log in to your machine as a root user.

  2. With systemctl commands, first check the status of your instance to determine whether it's up: systemctl status edb-as-(version)

  3. If it's running, use systemctl stop edb-as-(version) to stop your server. Then, recovery can take place.

    Cohesity Restore Database Steps

Cohesity recovery of EDB Postgres Advanced Server data

  1. In the Cohesity dashboard, select Data Protection > Recoveries.

  2. At the top right of the page, select Recover. Then select Universal Data Adapter from the list of sources.

  3. Search for the protection group that contains the snapshots to recover from. Enter characters of the protection group name, or enter * for the wildcard option.

    Cohesity Recover Choose Protection Group

    Cohesity Recover Protection Group

  4. From the search results, select the protection group that you want to recover.

  5. In the Object Name field, specify a name for the server to restore. This name doesn't affect the restore. Cohesity uses it to help track your backups and restores.

    By default, the latest snapshot is selected to recover from. If you want to select a point-in-time recovery or a specific data backup that you took, select the pencil to edit the recovery point.

    Cohesity Recover Object Name

    Cohesity Recovery Point

    Note from Cohesity

    Only cluster-level restore is supported. Object-level restore isn't yet supported. Hence the given object name is ignored by the PostgreSQL restore workflow.

  6. Select Next: Recovery Options.

  7. Depending on your requirement, select Replace Original or Recover to a New Object.

  8. In the Recovery Options area, configure the following options:

  • Mounts/VIPs: The number of IPs to use.
  • Concurrency: The number of parallel streams to read data from Cohesity storage.
  • Recovery Script Arguments: The path on the target cluster where you want to restore data, for example: - - target-dir=/var/lib/edb/as13/data.
  • Task Name: Keep the default name or enter a name for the recovery task.

Cohesity Recover Recovery Scripts

  1. Select Start Recovery.

    The recovery process proceeds. When the process is complete, a status message appears on the main Recoveries page.

  2. To view the logs from the recovery run, select the Recover task, and then select Show Subtasks.

    This figure shows the recoveries process bar.

    Cohesity Recovery Status

    This figure shows the recovery instance log information.

    Cohesity Recovery Logs

  3. After the restore has completed successfully, log in to your EDB Postgres Advanced Server instance and check that the restore operation successfully recovered the data.

Example: Database “as13backup” dropped before the recovery

   edb=# DROP DATABASE as13backup;
DROP DATABASE
edb=# \l
                                           List of databases
   Name    |    Owner     | Encoding |   Collate   |    Ctype    | ICU |       Access privileges       
-----------+--------------+----------+-------------+-------------+-----+-------------------------------
 edb       | enterprisedb | UTF8     | en_US.UTF-8 | en_US.UTF-8 |     | 
 postgres  | enterprisedb | UTF8     | en_US.UTF-8 | en_US.UTF-8 |     | 
 template0 | enterprisedb | UTF8     | en_US.UTF-8 | en_US.UTF-8 |     | =c/enterprisedb              +
           |              |          |             |             |     | enterprisedb=CTc/enterprisedb
 template1 | enterprisedb | UTF8     | en_US.UTF-8 | en_US.UTF-8 |     | =c/enterprisedb              +
           |              |          |             |             |     | enterprisedb=CTc/enterprisedb
(4 rows)

edb=# \q

Example: Check a restore

After the restore is successful, check the databases to see if as13backup was restored. In this example, you can see that it was restored, along with the data.

edb=# \l
                                           List of databases
    Name    |    Owner     | Encoding |   Collate   |    Ctype    | ICU |       Access privileges       
------------+--------------+----------+-------------+-------------+-----+-------------------------------
 as13backup | enterprisedb | UTF8     | en_US.UTF-8 | en_US.UTF-8 |     | 
 edb        | enterprisedb | UTF8     | en_US.UTF-8 | en_US.UTF-8 |     | 
 postgres   | enterprisedb | UTF8     | en_US.UTF-8 | en_US.UTF-8 |     | 
 template0  | enterprisedb | UTF8     | en_US.UTF-8 | en_US.UTF-8 |     | =c/enterprisedb              +
            |              |          |             |             |     | enterprisedb=CTc/enterprisedb
 template1  | enterprisedb | UTF8     | en_US.UTF-8 | en_US.UTF-8 |     | =c/enterprisedb              +
            |              |          |             |             |     | enterprisedb=CTc/enterprisedb
(5 rows)

edb=# \c as13backup
psql (14.4.0, server 13.7.11)
You are now connected to database "as13backup" as user "enterprisedb".

as13backup=# \dir
                          List of relations
 Schema |       Name       | Type  |    Owner     |      Table       
--------+------------------+-------+--------------+------------------
 public | index_sales      | index | enterprisedb | tp_sales_db
 public | tp_dept_dname_uq | index | enterprisedb | tp_department_db
 public | tp_dept_pk       | index | enterprisedb | tp_department_db
(3 rows)

as13backup=# select * from tp_department_db
as13backup-# ;
 deptno |    dname    | location 
--------+-------------+----------
     10 | Development | Pakistan
     20 | Testing     | Pakistan
     30 | CM          | Pakistan
     40 | Marketing   | India
(4 rows)_

After a restore, Cohesity restarts the database using a sudo, runuser, -l, enterprisedb, -c, /usr/edb/as(version)/bin/pg_ctl start -D /var/lib/edb/as(version)/data command instead of starting the database with systemctl. This doesn't allow the server to be tracked by systemd. If you want to track the server using systemd, you need to stop and start the database. Go to your server and use ./pg_ctl -D /var/lib/edb/as(version)/ stop. Then, to allow your server to be tracked by systemd, log in as the root user, and issue the systemctl edb-as-(version) start command.

Could this page be better? Report a problem or suggest an addition!