Overview
VIGIA’s multi-tenant architecture requires careful backup and restore procedures. Each tenant database must be backed up independently, while the master database contains critical tenant registry information.Backup Strategy
Database Hierarchy
VIGIA uses a three-tier database structure:- Master Database: Tenant registry (
clientes_saastable) - Tenant Databases: Individual client data (one per tenant)
- Legacy Database: Single-tenant deployments (optional)
Backup Frequency Recommendations
| Database Type | Frequency | Retention | Priority |
|---|---|---|---|
| Master | Hourly | 30 days | Critical |
| Active Tenants | Daily | 90 days | High |
| Demo Tenants | Weekly | 30 days | Medium |
| Legacy | Daily | 90 days | High |
PostgreSQL Backup Methods
pg_dump (Logical Backup)
Logical backups export database contents as SQL statements.Backup Single Tenant
Backup Master Database
Backup All Tenants (Script)
pg_basebackup (Physical Backup)
Physical backups copy the entire PostgreSQL data directory.- Full cluster recovery
- Replication setup
- Disaster recovery
- Large databases (faster than pg_dump)
Automated Backup Scripts
Daily Backup with Rotation
Cron Configuration
Restore Procedures
Restore Single Tenant
From SQL Dump
From Custom Format
Restore Master Database
CRITICAL: Restoring master database affects all tenant references.Disaster Recovery (Full System)
Data Export/Import
Export Tenant Data (JSON)
Create a Python script to export tenant data as JSON:Export ICSR Cases (CSV)
Import Data to New Tenant
After tenant provisioning, import historical data:Tenant Deletion and Data Retention
Soft Delete (Deactivate)
Preserves data for potential reactivation (backend/app/routers/admin_clientes.py:124-128):
Hard Delete (Permanent)
Completely removes tenant and database (backend/app/routers/admin_clientes.py:130-142):
- Terminates all active connections to tenant database
- Drops tenant database using
DROP DATABASE - Deletes tenant record from
clientes_saas - Logs deletion with tenant ID, subdomain, and database name
Point-in-Time Recovery (PITR)
PostgreSQL supports recovering to any point in time using WAL archives.Enable WAL Archiving
Editpostgresql.conf:
Create Base Backup
Recover to Point in Time
Cloud Backup Integration
AWS S3 Backup
Google Cloud Storage
Monitoring and Alerts
Backup Verification Script
Cron for Verification
Best Practices
Backup Strategy
- 3-2-1 Rule: 3 copies, 2 different media, 1 offsite
- Test restores regularly: Monthly restore drills
- Automate backups: Use cron or systemd timers
- Monitor backup jobs: Alert on failures
- Document procedures: Keep runbooks updated
Security
- Encrypt backups: Use
gpgor cloud provider encryption - Secure credentials: Use
.pgpassor environment variables - Limit access: Restrict backup file permissions (chmod 600)
- Audit logs: Track who accesses backups
Performance
- Parallel dumps: Use
-jflag for large databases - Compression: Always compress backups (
-Fcor gzip) - Off-peak backups: Schedule during low usage
- Incremental backups: Use WAL archiving for large databases
Retention
- Daily backups: Keep 90 days for active tenants
- Weekly backups: Keep 1 year
- Monthly backups: Keep indefinitely (compliance)
- Archive deleted tenants: Keep 2 years after deletion
Disaster Recovery Plan
Recovery Time Objective (RTO)
- Master Database: < 1 hour
- Critical Tenants: < 4 hours
- All Tenants: < 24 hours
Recovery Point Objective (RPO)
- Master Database: < 1 hour (hourly backups)
- Tenant Databases: < 24 hours (daily backups)
- PITR: < 5 minutes (WAL archiving)