These use cases show how backups are taken and restored from EDB Postgres Advanced Server using 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.
In the Cohesity dashboard, select Data Protection > Policies.
At the top-right of the Policy page, select Create Policy.
Specify a policy name for your protection policy.
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.
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.
From the Cohesity dashboard, select Data Protection > Protection.
At the top-right of the page, select Protect, and then select Universal Data Adapter.
From the Source menu, select the EDB Postgres Advanced Server source that you registered.
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.
In the Protection Group field, give your source a unique protection name that you can identify.
In the Policy field, from the list, select the policy that you created.
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.
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.
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.
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.
Log in to your machine as a root user.
With systemctl commands, first check the status of your instance to determine whether it's up:
systemctl status edb-as-(version)
If it's running, use
systemctl stop edb-as-(version)to stop your server. Then, recovery can take place.
In the Cohesity dashboard, select Data Protection > Recoveries.
At the top right of the page, select Recover. Then select Universal Data Adapter from the list of sources.
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.
From the search results, select the protection group that you want to recover.
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.
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.
Select Next: Recovery Options.
Depending on your requirement, select Replace Original or Recover to a New Object.
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.
Select Start Recovery.
The recovery process proceeds. When the process is complete, a status message appears on the main Recoveries page.
To view the logs from the recovery run, select the Recover task, and then select Show Subtasks.
This figure shows the recoveries process bar.
This figure shows the recovery instance log information.
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.
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.
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.
- On this page
- Setting a protection policy with Cohesity DataProtect for PostgreSQL
- Create a standard policy
- Protect an EDB Postgres Advanced Server source with a policy
- Restore an EDB Postgres Advanced Server Instance from a Cohesity protection run
- EDB Postgres Advanced Server database prerequisites before recovery initiation
- Cohesity recovery of EDB Postgres Advanced Server data