Backup & Restore

A robust backup and restore strategy is essential for protecting your Prisme.ai platform data and ensuring business continuity. This guide provides detailed instructions for backing up and restoring all components of your self-hosted Prisme.ai environment.

Backup Strategy

What to Back Up
Backup Frequency

Your Prisme.ai platform requires backing up several components:

Client-Managed Databases

PostgreSQL or MongoDB
Elasticsearch or OpenSearch
Redis

Object Storage

S3 or compatible object storage
Document files and attachments

Configuration

Kubernetes manifests
Helm values
Terraform state files

Secrets

Kubernetes secrets
Certificate files
API keys and credentials

Recommended backup frequencies based on data criticality:

Component	Frequency	Retention
MongoDB	Daily	30 days
Elasticsearch or OpenSearch	Daily	14 days
Redis	Daily	7 days
S3 Storage	Weekly (incremental)	90 days
Configuration	After changes	Last 10 versions

Adjust backup frequency based on your organization’s Recovery Point Objective (RPO) requirements.

Database Backup Procedures

Per-engine backup commands and managed-service options live on the dedicated database pages:

MongoDB

mongodump / mongorestore, Atlas continuous backups.

Elasticsearch or OpenSearch

Snapshot API, S3 / Azure Blob / GCS snapshot repositories.

Redis

RDB / AOF persistence, managed snapshot schedules.

PostgreSQL

pg_dump / pg_restore, RDS / Azure / Cloud SQL point-in-time recovery.

Object Storage (S3 / Azure Blob / GCS)

Use the provider’s tooling to mirror or version your buckets:

# AWS S3: sync to a backup bucket (cross-region for DR)
aws s3 sync s3://your-prisme-bucket s3://your-backup-bucket

# Enable versioning (built-in restore safety)
aws s3api put-bucket-versioning --bucket your-prisme-bucket \
  --versioning-configuration Status=Enabled

Apply lifecycle policies to manage backup retention and storage tier. Equivalents exist on Azure Blob (snapshots / soft delete) and GCS (object versioning).

Configuration Backup

Back Up Kubernetes Resources

Save your Kubernetes configuration resources:

# Back up all resources in the Prisme namespace
mkdir -p /path/to/backup/kubernetes/$(date +%Y-%m-%d)

# Export deployments, services, configmaps, secrets, etc.
kubectl get all,pvc,cm,secret -n prisme-system -o yaml > \
  /path/to/backup/kubernetes/$(date +%Y-%m-%d)/prisme-resources.yaml

Back Up Helm Values

Save your Helm chart values for each release:

# Get values for each Helm release
helm get values prismeai-core -n prisme-system -o yaml > \
  /path/to/backup/helm/$(date +%Y-%m-%d)/prismeai-core-values.yaml

helm get values prismeai-securechat -n prisme-system -o yaml > \
  /path/to/backup/helm/$(date +%Y-%m-%d)/prismeai-securechat-values.yaml

# Repeat for each product module

Back Up Terraform State

If using Terraform, back up your state files:

# If using local state
cp terraform.tfstate terraform.tfstate.backup
cp -r terraform.tfstate.d /path/to/backup/terraform/$(date +%Y-%m-%d)

# If using remote state (recommended), ensure your remote backend has proper backup

Using remote state in Terraform (like S3 with versioning or Terraform Cloud) provides built-in backup capabilities.

Restore Procedures

Per-engine restore commands live on the dedicated database pages; see the Backup & restore section of each:

Object Storage restore

# Restore from a backup bucket
aws s3 sync s3://your-backup-bucket s3://your-prisme-bucket --delete

# Restore a specific object version (when versioning is enabled)
aws s3api get-object --bucket your-prisme-bucket --key path/to/file \
  --version-id <VERSION_ID> /tmp/restored

Configuration Restore

Restore Kubernetes Resources

Apply your backed-up Kubernetes configurations:

# First, clean up the namespace if necessary
# WARNING: This will delete all resources! Use with caution.
# kubectl delete namespace prisme-system
# kubectl create namespace prisme-system

# Apply backed-up resources
kubectl apply -f /path/to/backup/kubernetes/YYYY-MM-DD/prisme-resources.yaml

Be cautious when restoring resources. Consider restoring specific resource types instead of everything at once:

# Restore only ConfigMaps and Secrets first
kubectl apply -f /path/to/backup/kubernetes/YYYY-MM-DD/configmaps.yaml
kubectl apply -f /path/to/backup/kubernetes/YYYY-MM-DD/secrets.yaml

# Then restore other resources
kubectl apply -f /path/to/backup/kubernetes/YYYY-MM-DD/deployments.yaml

Restore Helm Releases

Use your backed-up values to reinstall or upgrade Helm releases:

# Reinstall core
helm upgrade --install prismeai-core prismeai/prismeai-core \
  -f /path/to/backup/helm/YYYY-MM-DD/prismeai-core-values.yaml \
  --namespace prisme-system

# Reinstall product modules
helm upgrade --install prismeai-securechat prismeai/prismeai-securechat \
  -f /path/to/backup/helm/YYYY-MM-DD/prismeai-securechat-values.yaml \
  --namespace prisme-system

# Repeat for other product modules

Restore Terraform State

If you need to restore Terraform state:

# For local state
cp /path/to/backup/terraform/YYYY-MM-DD/terraform.tfstate .
cp -r /path/to/backup/terraform/YYYY-MM-DD/terraform.tfstate.d .

# Verify state
terraform state list

For remote state, follow your backend provider’s restoration process.

Disaster Recovery Planning

Recovery Objectives
DR Scenarios
DR Testing

Define your recovery objectives to guide your backup strategy:

RPO (Recovery Point Objective)

Maximum acceptable data loss in time:

Critical data: RPO < 1 hour
Important data: RPO < 24 hours
Regular data: RPO < 1 week

RTO (Recovery Time Objective)

Maximum acceptable time to restore service:

Critical services: RTO < 4 hours
Important services: RTO < 24 hours
Regular services: RTO < 3 days

Testing and Validation

Verify Backup Integrity

Regularly test your backups to ensure they can be restored:

# For MongoDB
mongorestore --uri="mongodb://username:password@hostname:port/test_db" \
  --nsFrom="database.*" --nsTo="test_db.*" \
  --dryRun /path/to/backup/mongo/YYYY-MM-DD

# For S3
aws s3 cp s3://your-backup-bucket/sample-file.pdf /tmp/test-restore.pdf

Validation Checkpoints

Establish validation points for successful restoration:

Data Validation

Record counts match pre-backup state
Sample record content is intact
Relationships between data are preserved
Application-specific data tests pass

Functionality Validation

Core services start successfully
API endpoints respond correctly
Authentication and authorization work
Data processing functions operate properly
UI elements display and function as expected

Document Restoration Procedures

Maintain detailed, tested restoration runbooks:

Step-by-step instructions
Required credentials and access
Validation checkpoints
Troubleshooting guidance
Contact information for support

Overview

Installation

Databases

Production Readiness

Entreprise Services

Operations

Backup Strategy

Client-Managed Databases

Object Storage

Configuration

Secrets

Database Backup Procedures

MongoDB

Elasticsearch or OpenSearch

Redis

PostgreSQL

Object Storage (S3 / Azure Blob / GCS)

Configuration Backup

Restore Procedures

Object Storage restore

Configuration Restore

Disaster Recovery Planning

RPO (Recovery Point Objective)

RTO (Recovery Time Objective)

Testing and Validation

Data Validation

Functionality Validation

Next Steps

Updates

Scaling

​Backup Strategy

Client-Managed Databases

Object Storage

Configuration

Secrets

​Database Backup Procedures

MongoDB

Elasticsearch or OpenSearch

Redis

PostgreSQL

​Object Storage (S3 / Azure Blob / GCS)

​Configuration Backup

​Restore Procedures

​Object Storage restore

​Configuration Restore

​Disaster Recovery Planning

RPO (Recovery Point Objective)

RTO (Recovery Time Objective)

​Testing and Validation

Data Validation

Functionality Validation

​Next Steps

Updates

Scaling

Backup Strategy

Database Backup Procedures

Object Storage (S3 / Azure Blob / GCS)

Configuration Backup

Restore Procedures

Object Storage restore

Configuration Restore

Disaster Recovery Planning

Testing and Validation

Next Steps