Backup and Restore

Protect your Jitera Self-Hosted data with regular backups

Backup Components

Component	Data	Priority
PostgreSQL (Automation)	Application data	Critical
PGVector PostgreSQL	Embedding vectors	Critical
MongoDB / DocumentDB / Cosmos DB	AI / chat data	Critical
Object Storage	Files, exports	High
Redis	Session data	Low
Configuration	Helm values	High

PostgreSQL is split into the Automation database and the PGVector database, hosted on separate instances. Backing up only Automation leaves the PGVector embeddings unprotected. For the chat / AI store you run one of MongoDB, AWS DocumentDB, or Azure Cosmos DB for MongoDB depending on your deployment.

---

PostgreSQL Backup

The commands below target an in-cluster PostgreSQL pod. If you’re using a managed Postgres service (RDS, Cloud SQL, Azure Database for PostgreSQL Flexible Server, etc.), use the cloud-provider snapshot mechanism instead (aws rds create-db-snapshot, etc.). Apply the same procedure to the PGVector instance as a separate PostgreSQL.

Manual Backup

# Get PostgreSQL pod
PG_POD=$(kubectl get pod -n jitera -l app.kubernetes.io/name=postgresql -o jsonpath='{.items[0].metadata.name}')

# Create backup
kubectl exec -n jitera $PG_POD -- pg_dump -U jitera -Fc jitera > backup-$(date +%Y%m%d).dump

Automated Backup with CronJob

apiVersion: batch/v1
kind: CronJob
metadata:
  name: postgres-backup
  namespace: jitera
spec:
  schedule: "0 2 * * *"  # Daily at 2 AM
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: postgres:15
            command:
            - /bin/sh
            - -c
            - |
              pg_dump -h jitera-postgresql -U jitera -Fc jitera > /backup/jitera-$(date +%Y%m%d).dump
              # Upload to S3/Azure
            volumeMounts:
            - name: backup
              mountPath: /backup
            env:
            - name: PGPASSWORD
              valueFrom:
                secretKeyRef:
                  name: jitera-postgresql
                  key: password
          volumes:
          - name: backup
            persistentVolumeClaim:
              claimName: backup-pvc
          restartPolicy: OnFailure

Restore PostgreSQL

# Copy backup to pod
kubectl cp backup-20240101.dump jitera/$PG_POD:/tmp/

# Restore
kubectl exec -n jitera $PG_POD -- pg_restore -U jitera -d jitera -c /tmp/backup-20240101.dump

---

MongoDB Backup

The commands below target an in-cluster MongoDB pod. If you’re using a managed MongoDB-compatible service (AWS DocumentDB, Azure Cosmos DB for MongoDB, etc.), use the cloud-provider snapshot mechanism instead (aws docdb create-db-cluster-snapshot, Cosmos DB continuous backup, etc.).

Manual Backup

# Get MongoDB pod
MONGO_POD=$(kubectl get pod -n jitera -l app.kubernetes.io/name=mongodb -o jsonpath='{.items[0].metadata.name}')

# Create backup
kubectl exec -n jitera $MONGO_POD -- mongodump --out /tmp/backup

# Copy backup locally
kubectl cp jitera/$MONGO_POD:/tmp/backup ./mongo-backup-$(date +%Y%m%d)

Restore MongoDB

# Copy backup to pod
kubectl cp ./mongo-backup-20240101 jitera/$MONGO_POD:/tmp/backup

# Restore
kubectl exec -n jitera $MONGO_POD -- mongorestore /tmp/backup

---

Object Storage Backup

AWS S3

Use S3 versioning and cross-region replication:

# Enable versioning
aws s3api put-bucket-versioning \
  --bucket jitera-prod-automation \
  --versioning-configuration Status=Enabled

# Set up replication (requires destination bucket)
aws s3api put-bucket-replication \
  --bucket jitera-prod-automation \
  --replication-configuration file://replication.json

Azure Blob Storage

Enable soft delete and geo-redundancy:

# Enable soft delete
az storage blob service-properties delete-policy update \
  --account-name jiteraprod \
  --enable true \
  --days-retained 30

MinIO Backup

# Use mc mirror for backup
mc mirror ./charts/jitera-automation backup/jitera-automation

---

Configuration Backup

Backup Helm Values

# Get current values
helm get values jitera -n jitera > values-backup-$(date +%Y%m%d).yaml

# Backup to version control
git add values-backup-*.yaml
git commit -m "Backup Jitera values"

Backup Secrets

# Export secrets (encrypted)
kubectl get secret -n jitera -o yaml > secrets-backup.yaml

# Store securely (encrypt before storing)
gpg --encrypt --recipient [e-mail] secrets-backup.yaml

---

Disaster Recovery

Recovery Time Objectives

Component	RTO	RPO
PostgreSQL	1 hour	24 hours
MongoDB	2 hours	24 hours
Object Storage	4 hours	1 hour

Recovery Procedure

1. Provision new cluster

   # Create new namespace
   kubectl create namespace jitera
   

2. Restore configuration

   # Apply secrets
   kubectl apply -f secrets-backup.yaml
   

3. Deploy Jitera with backup values

   helm install jitera ./charts/jitera \
     -f values-backup.yaml \
     -n jitera
   

4. Restore databases

   # PostgreSQL
   kubectl exec -n jitera $PG_POD -- pg_restore -U jitera -d jitera backup.dump
   
   # MongoDB
   kubectl exec -n jitera $MONGO_POD -- mongorestore /tmp/backup
   

5. Verify functionality

   • Check all pods are running
   • Verify data integrity
   • Test user login

---

Backup Verification

Monthly Restore Test

1. Create test environment
2. Restore latest backup
3. Verify data integrity
4. Test critical functions
5. Document results

Verification Checklist

• Backup files exist and are readable
• Backup size is expected
• Restore completes without errors
• Application starts successfully
• Data is intact and queryable
• User authentication works

---

External Backup Services

For AWS

• AWS Backup: Automated backup for RDS, S3
• EBS Snapshots: Volume snapshots

For Azure

• Azure Backup: Managed backup service
• Azure Site Recovery: Disaster recovery

Third-Party

• Velero: Kubernetes backup tool
  velero backup create jitera-backup \
    --include-namespaces jitera
  

---

Retention Policy

Backup Type	Retention
Daily	7 days
Weekly	4 weeks
Monthly	12 months
Yearly	7 years

---

Troubleshooting

Backup Failed

1. Check pod logs
2. Verify storage space
3. Check credentials
4. Test connectivity

Restore Failed

1. Verify backup integrity
2. Check version compatibility
3. Review error logs
4. Ensure clean target state

---

Related Documentation

Maintenance Overview

Backup, restore, and routine maintenance tasks

Monitoring

Health, metrics, and alerting for Jitera Self-Hosted

Troubleshooting

Incident workflow and common issues