> For the complete documentation index, see [llms.txt](https://docs.hivel.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hivel.ai/self-managed-hivel-deployment/virtual-private-cloud/azure/hivel-on-premises-deployment-guide-azure/backup-and-restore.md).

# Backup and Restore

**What must be backed up:** the Azure Database for PostgreSQL insightly database - all Hivel application data lives here. There is no separate object store to back up in this deployment path.

### Azure's Automated Backups

Azure Database for PostgreSQL Flexible Server performs automated backups continuously and supports **point-in-time restore (PITR)** without any setup on your part. Backup retention is a configurable server setting - check your **PostgreSQL Flexible Server → Backup** and restore in the Azure Portal to confirm the retention window configured for your environment.

**Recommended retention:** Hivel recommends daily backups retained for 7 days, which maps directly to the backup-retention setting on your Azure Database for PostgreSQL server. You're free to configure a longer retention window if your own compliance or operational requirements call for it.

**Live-backup safety:** Azure's automated backups and point-in-time restore are safe to use while Hivel's services are running normally - you do not need to pause integration polling or quiesce the application before a backup or restore is taken.

### Restore Sequence

**Goal:** recover the insightly database to a known-good point in time and get Hivel services pointed at it again.

1\. Stop services that write to the database: `./deploy.sh --stop` (on VM)

2\. In the Azure Portal, go to your **PostgreSQL Flexible Server → Restore → choose a restore point.** This creates a new server with a new hostname - it does not restore in place.

3\. Update config/.env's DB\_HOST on the VM to the new restored server's hostname, and re-apply the firewall rules from Database Setup → Configure Database Networking to the new server.

4\. Restart services:

{% code expandable="true" %}

```
./deploy.sh --start
```

{% endcode %}

5\. Re-evaluate permissions now that services are back up, substituting \<base-url> with your deployment's actual API base URL:

{% code expandable="true" %}

```
curl --location --request DELETE '<base-url>/hivelapi/v1/permissions/reevaluate?orgId=1'
```

{% endcode %}

This re-evaluates permissions after a restore so they reflect the restored database state.

6\. Validate using the Validation Checklist in [Verification and Access](/self-managed-hivel-deployment/virtual-private-cloud/azure/hivel-on-premises-deployment-guide-azure/verification-and-access.md).

This sequence is correct and complete as documented. If the restored server's hostname changed and you're fronting it with a DNS record or load balancer, also repoint that DNS/load-balancer configuration to the new hostname - this is a general caveat worth checking any time an underlying hostname changes, not something specific to this restore path.

**Next step:** Upgrade and Rollback.

<br>

{% columns %}
{% column %} <a href="/self-managed-hivel-deployment/virtual-private-cloud/azure/hivel-on-premises-deployment-guide-azure/troubleshooting.md" class="button primary" data-icon="backward">Troubleshooting</a>
{% endcolumn %}

{% column %}

{% endcolumn %}

{% column %} <a href="/self-managed-hivel-deployment/virtual-private-cloud/azure/hivel-on-premises-deployment-guide-azure/upgrade-and-rollback.md" class="button primary" data-icon="forward">Upgrade and Rollback</a>
{% endcolumn %}
{% endcolumns %}