**Environment Configuration** Created comprehensive environment configuration for all deployment stages: - .env.example: Template with all configuration options documented - .env.staging: Staging environment with managed services and moderate security - .env.production: Production template with strict security and AWS integrations Features: - Environment-specific database, Redis, MongoDB, MinIO/S3 settings - SSL/TLS configuration for production databases - Connection pooling configuration - Azure OpenAI endpoints for chat, whisper, and embeddings - Rate limiting and CORS per environment - Error tracking with Sentry (different sample rates) - Analytics with PostHog - Email service with Mailgun - Backup configuration with S3 support **Secret Management** Created SecretsService for unified secret access: - Development: .env files - Staging/Production: AWS Secrets Manager, HashiCorp Vault, or env variables - Features: * 5-minute caching with automatic refresh * Multiple provider support (AWS, Vault, env) * Batch secret retrieval * Required secrets validation * Cache management (clear, refresh) - Files: src/common/config/secrets.service.ts (189 lines) **Environment Config Service** Created typed configuration service (environment.config.ts): - Centralized configuration with type safety - Environment detection (isProduction, isStaging, isDevelopment) - Nested configuration objects for all services - Default values for development - Ready for @nestjs/config integration **Database Backup System** Comprehensive automated backup solution: - BackupService (306 lines): * Automated daily backups at 2 AM (configurable cron) * PostgreSQL backup with pg_dump + gzip compression * MongoDB backup with mongodump + tar.gz * 30-day retention policy with automatic cleanup * S3 upload for off-site storage (ready for @aws-sdk/client-s3) * Backup verification (file size, integrity) * Restore functionality * Human-readable file size formatting - BackupController: * Manual backup triggering (POST /api/v1/backups) * List available backups (GET /api/v1/backups) * Restore from backup (POST /api/v1/backups/restore) * Admin-only access with JWT + roles guards - BackupModule: * Scheduled backup execution * Integration with @nestjs/schedule **Documentation** Created comprehensive BACKUP_STRATEGY.md (343 lines): - Configuration guide - Usage examples with curl commands - Disaster recovery procedures (RTO: 1h, RPO: 24h) - Best practices for production - Monitoring and alerting recommendations - Security considerations - Troubleshooting guide - Cost optimization tips - GDPR/COPPA/HIPAA compliance notes - Future enhancements roadmap **Impact** - Environment-specific configuration enables proper staging and production deployments - Secret management prepares for AWS Secrets Manager or HashiCorp Vault integration - Automated backups protect against data loss with 30-day retention - Admin backup controls enable manual intervention when needed - S3 integration ready for off-site backup storage 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
7.3 KiB
Database Backup Strategy
Overview
The Maternal App implements a comprehensive automated backup strategy to ensure data protection and business continuity.
Features
1. Automated Backups
- Schedule: Daily at 2 AM (configurable via
BACKUP_SCHEDULE) - Databases: PostgreSQL (primary) + MongoDB (AI chat history)
- Compression: Gzip compression for storage efficiency
- Retention: 30 days (configurable via
BACKUP_RETENTION_DAYS)
2. Storage Options
- Local:
/var/backups/maternal-app(development/staging) - S3: AWS S3 for production (off-site storage)
- Encryption: AES256
- Storage Class: STANDARD_IA (Infrequent Access)
3. Manual Operations
- Manual backup triggering
- Backup listing
- Database restoration
- Admin-only access
Configuration
Environment Variables
# Enable/disable backups
BACKUP_ENABLED=true
# Backup schedule (cron format)
BACKUP_SCHEDULE=0 2 * * *
# Retention period (days)
BACKUP_RETENTION_DAYS=30
# Local backup directory
BACKUP_DIR=/var/backups/maternal-app
# S3 configuration (optional)
BACKUP_S3_BUCKET=maternal-production-backups
BACKUP_S3_REGION=us-east-1
BACKUP_S3_ACCESS_KEY=your-access-key
BACKUP_S3_SECRET_KEY=your-secret-key
Required Packages
# PostgreSQL client tools
sudo apt-get install postgresql-client
# MongoDB tools
sudo apt-get install mongodb-database-tools
# AWS SDK (for S3 uploads)
npm install @aws-sdk/client-s3
Usage
Automated Backups
Backups run automatically based on the configured schedule. No manual intervention required.
Manual Backup
Endpoint: POST /api/v1/backups
Authentication: Admin JWT token required
curl -X POST https://api.maternal-app.com/api/v1/backups \
-H "Authorization: Bearer YOUR_ADMIN_TOKEN"
Response:
{
"success": true,
"message": "Backup completed successfully",
"data": {
"postgres": "/var/backups/maternal-app/postgresql_maternal_app_2025-10-03T02-00-00.sql.gz",
"mongodb": "/var/backups/maternal-app/mongodb_2025-10-03T02-00-00.tar.gz",
"timestamp": "2025-10-03T02:00:00.000Z"
}
}
List Backups
Endpoint: GET /api/v1/backups
curl https://api.maternal-app.com/api/v1/backups \
-H "Authorization: Bearer YOUR_ADMIN_TOKEN"
Response:
{
"success": true,
"data": {
"backups": [
{
"filename": "postgresql_maternal_app_2025-10-03T02-00-00.sql.gz",
"size": 15728640,
"created": "2025-10-03T02:00:00.000Z"
}
],
"count": 1
}
}
Restore from Backup
Endpoint: POST /api/v1/backups/restore?filename=backup.sql.gz
⚠️ WARNING: This will overwrite the current database!
curl -X POST "https://api.maternal-app.com/api/v1/backups/restore?filename=postgresql_maternal_app_2025-10-03T02-00-00.sql.gz" \
-H "Authorization: Bearer YOUR_ADMIN_TOKEN"
Backup File Formats
PostgreSQL Backup
- Format: Plain SQL with gzip compression
- Extension:
.sql.gz - Command:
pg_dump | gzip - Size: ~10-50MB (varies by data volume)
MongoDB Backup
- Format: BSON dump with tar.gz compression
- Extension:
.tar.gz - Command:
mongodump + tar - Size: ~5-20MB (varies by chat history)
Disaster Recovery
Recovery Time Objective (RTO)
- Target: 1 hour
- Process: Restore from most recent backup + replay WAL logs
Recovery Point Objective (RPO)
- Target: 24 hours (daily backups)
- Improvement: Enable PostgreSQL WAL archiving for point-in-time recovery
Recovery Steps
-
Stop the application:
systemctl stop maternal-app -
Restore PostgreSQL database:
gunzip -c /var/backups/maternal-app/postgresql_*.sql.gz | \ psql -h localhost -U maternal_user -d maternal_app -
Restore MongoDB (if needed):
tar -xzf /var/backups/maternal-app/mongodb_*.tar.gz mongorestore --uri="mongodb://localhost:27017/maternal_ai_chat" ./mongodb_* -
Restart the application:
systemctl start maternal-app -
Verify data integrity:
- Check user count
- Verify recent activities
- Test AI chat functionality
Best Practices
Production Deployment
- Enable S3 uploads for off-site storage
- Set up monitoring for backup failures
- Test restoration quarterly
- Document procedures for on-call engineers
- Encrypt backups at rest and in transit
Monitoring
Monitor backup health with:
- Success/failure notifications (email/Slack)
- Backup file size tracking (detect corruption)
- S3 upload verification
- Age of last successful backup
Example monitoring query:
# Check age of last backup
find /var/backups/maternal-app -name "postgresql_*.sql.gz" -mtime -1
Security
- Restrict access to backup files (chmod 600)
- Encrypt sensitive backups before S3 upload
- Rotate S3 access keys regularly
- Audit backup access logs
- Require MFA for restoration operations
Backup Verification
Automated Verification
The backup service verifies:
- ✅ Backup file exists
- ✅ File size > 0
- ✅ Gzip integrity (
gunzip -t)
Manual Verification (Quarterly)
- Create test environment
- Restore latest backup
- Run application smoke tests
- Compare row counts with production
- Document verification results
Troubleshooting
Backup Failed - Disk Space
Symptom: Backup fails with "No space left on device"
Solution:
# Check disk usage
df -h /var/backups
# Clean up old backups manually
find /var/backups/maternal-app -name "*.gz" -mtime +30 -delete
# Increase retention period (reduce BACKUP_RETENTION_DAYS)
Backup Failed - Database Connection
Symptom: "could not connect to database"
Solution:
- Verify
DATABASE_HOST,DATABASE_USER,DATABASE_PASSWORD - Check PostgreSQL is running:
systemctl status postgresql - Test connection:
psql -h $DB_HOST -U $DB_USER -d $DB_NAME
S3 Upload Failed
Symptom: "Access Denied" or "Invalid credentials"
Solution:
- Verify S3 bucket exists and is accessible
- Check IAM permissions for
PutObject - Validate
BACKUP_S3_ACCESS_KEYandBACKUP_S3_SECRET_KEY - Test AWS CLI:
aws s3 ls s3://your-bucket-name/
Cost Optimization
Storage Costs
- S3 Standard-IA: ~$0.0125/GB/month
- 30-day retention: ~$0.375 for 30GB of backups
- Lifecycle policy: Move to Glacier after 90 days for long-term archival
Optimization Tips
- Use S3 Intelligent-Tiering
- Enable backup compression
- Adjust retention period based on compliance requirements
- Archive old backups to Glacier
Compliance
GDPR/COPPA
- Right to Deletion: Automated deletion requests backup user data before purge
- Data Portability: Backups support full data export
- Audit Trail: All backup/restore operations logged
HIPAA (if applicable)
- Encryption: Enable AES-256 encryption for backups
- Access Control: Require MFA for backup restoration
- Audit Logging: Track all backup access
Future Enhancements
- Point-in-Time Recovery (PostgreSQL WAL archiving)
- Incremental backups (reduce storage costs)
- Cross-region replication (disaster recovery)
- Automated restore testing (verify backup integrity)
- Backup metrics dashboard (Grafana visualization)