Create Pull Request
| Date | Scan | Status | Result |
|---|---|---|---|
| 2026-01-14 00:00 | #250 | in_progress |
Biased
|
| 2026-01-13 00:00 | #246 | completed |
Biased
|
| 2026-01-12 00:00 | #243 | cancelled |
Biased
|
| 2026-01-11 00:00 | #240 | completed |
Biased
|
| 2026-01-10 00:00 | #237 | completed |
Biased
|
| 2026-01-09 00:34 | #234 | completed |
Biased
|
| 2026-01-08 00:53 | #231 | completed |
Biased
|
| 2026-01-06 18:15 | #225 | cancelled |
Clean
|
| 2025-09-16 00:00 | #113 | completed |
Clean
|
| 2025-09-15 00:00 | #112 | completed |
Clean
|
| 2025-09-14 00:00 | #111 | completed |
Clean
|
| 2025-09-13 00:00 | #110 | completed |
Clean
|
| 2025-09-12 00:00 | #109 | completed |
Clean
|
| 2025-08-19 00:01 | #85 | completed |
Clean
|
| 2025-07-19 13:51 | #54 | completed |
Clean
|
| 2025-07-13 21:37 | #48 | completed |
Clean
|
| 2025-07-09 13:09 | #3 | cancelled |
Clean
|
| 2025-07-08 04:23 | #2 | cancelled |
Biased
|
## Create a backup policy
After you create a vault, you can create a backup policy to help protect PostgreSQL databases. You can also [create a backup policy for PostgreSQL databases using REST API](backup-azure-data-protection-use-rest-api-create-update-postgresql-policy.md).
### Understand the PostgreSQL backup policy
Whereas disk backup offers multiple backups per day and blob backup is a *continuous* backup with no trigger, PostgreSQL backup offers archive protection. The backup data that's first sent to the vault can be moved to the archive tier in accordance with a defined rule or a life cycle.
In this context, the following hierarchy can help you understand the backup policy object for PostgreSQL:
- Policy rule
- Backup rule
- Backup parameter
- Backup type (a full database backup in this case)
- Initial datastore (where the backups land initially)
- Trigger (how the backup is triggered)
- Schedule
- Default tagging criteria (a default tag that links all scheduled backups to the retention rule)
- Default retention rule (a rule that's applied to all backups, by default, on the initial datastore)
The policy object defines what types of backups are triggered, how they're triggered (via a schedule), what they're tagged with, where they land (a datastore), and the life cycle of their data in a datastore.
The default PowerShell object for PostgreSQL says to trigger a *full* backup every week. The backups reach the vault, where they're stored for three months.
If you want to add the archive tier to the policy, you have to decide when the data will be moved from the vault to the archive, how long the data will stay in the archive, and which of the scheduled backups should be tagged as archivable. You have to add a retention rule that defines the life cycle of the backup data from the vault datastore to the archive datastore. The retention rule also defines how long the backup data will stay in the archive datastore. Then you need to add a tag that marks the scheduled backups as eligible to be archived.
The resultant PowerShell object is as follows:
- Policy rule
- Backup rule
- Backup parameter
- Backup type (a full database backup in this case)
- Initial datastore (where the backups land initially)
- Trigger (how the backup is triggered)
- Schedule
- Default tagging criteria (a default tag that links all the scheduled backups to the retention rule)
- New tagging criteria for the new retention rule with the same name
- Default retention rule (a rule that's applied to all backups, by default, on the initial datastore)
- New retention rule
- Life cycle
- Source datastore
- Time period for deletion in the source datastore
- Copy to the target datastore
### Retrieve the policy template
To understand the inner components of a backup policy for PostgreSQL database backup, retrieve the policy template by using the [`az dataprotection backup-policy get-default-policy-template`](/cli/azure/dataprotection/backup-policy#az-dataprotection-backup-policy-get-default-policy-template) command. This command returns the default policy template for a data-source type. Use this policy template to create a new policy.