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:
5. Re-evaluate permissions now that services are back up, substituting <base-url> with your deployment's actual API base URL:
This re-evaluates permissions after a restore so they reflect the restored database state.
6. Validate using the Validation Checklist in Verification and Access.
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.
Last updated