> ## Documentation Index
> Fetch the complete documentation index at: https://docs.prisme.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Backup & Restore

> Protect your Prisme.ai platform data with comprehensive backup and restore procedures

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

<Tabs>
  <Tab title="What to Back Up">
    Your Prisme.ai platform requires backing up several components:

    <CardGroup cols={2}>
      <Card title="Client-Managed Databases" icon="database">
        * PostgreSQL or MongoDB
        * Elasticsearch or OpenSearch
        * Redis
      </Card>

      <Card title="Object Storage" icon="hard-drive">
        * S3 or compatible object storage
        * Document files and attachments
      </Card>

      <Card title="Configuration" icon="gear">
        * Kubernetes manifests
        * Helm values
        * Terraform state files
      </Card>

      <Card title="Secrets" icon="key">
        * Kubernetes secrets
        * Certificate files
        * API keys and credentials
      </Card>
    </CardGroup>
  </Tab>

  <Tab title="Backup Frequency">
    Recommended backup frequencies based on data criticality:

    <table>
      <thead>
        <tr>
          <th>Component</th>
          <th>Frequency</th>
          <th>Retention</th>
        </tr>
      </thead>

      <tbody>
        <tr>
          <td>MongoDB</td>
          <td>Daily</td>
          <td>30 days</td>
        </tr>

        <tr>
          <td>Elasticsearch or OpenSearch</td>
          <td>Daily</td>
          <td>14 days</td>
        </tr>

        <tr>
          <td>Redis</td>
          <td>Daily</td>
          <td>7 days</td>
        </tr>

        <tr>
          <td>S3 Storage</td>
          <td>Weekly (incremental)</td>
          <td>90 days</td>
        </tr>

        <tr>
          <td>Configuration</td>
          <td>After changes</td>
          <td>Last 10 versions</td>
        </tr>
      </tbody>
    </table>

    <Warning>
      Adjust backup frequency based on your organization's Recovery Point Objective (RPO) requirements.
    </Warning>
  </Tab>
</Tabs>

## Database Backup Procedures

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

<CardGroup cols={2}>
  <Card title="MongoDB" icon="database" href="/self-hosting/databases/mongodb#backup--restore">
    `mongodump` / `mongorestore`, Atlas continuous backups.
  </Card>

  <Card title="Elasticsearch or OpenSearch" icon="magnifying-glass" href="/self-hosting/databases/elasticsearch#backup--restore">
    Snapshot API, S3 / Azure Blob / GCS snapshot repositories.
  </Card>

  <Card title="Redis" icon="server" href="/self-hosting/databases/redis#backup--restore">
    RDB / AOF persistence, managed snapshot schedules.
  </Card>

  <Card title="PostgreSQL" icon="database" href="/self-hosting/databases/postgresql#backup--restore">
    `pg_dump` / `pg_restore`, RDS / Azure / Cloud SQL point-in-time recovery.
  </Card>
</CardGroup>

### Object Storage (S3 / Azure Blob / GCS)

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

```bash theme={null}
# 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

<Steps>
  <Step title="Back Up Kubernetes Resources">
    Save your Kubernetes configuration resources:

    ```bash theme={null}
    # 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
    ```
  </Step>

  <Step title="Back Up Helm Values">
    Save your Helm chart values for each release:

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

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

    # Repeat for each product module
    ```
  </Step>

  <Step title="Back Up Terraform State">
    If using Terraform, back up your state files:

    ```bash theme={null}
    # 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
    ```

    <Info>
      Using remote state in Terraform (like S3 with versioning or Terraform Cloud) provides built-in backup capabilities.
    </Info>
  </Step>
</Steps>

## Restore Procedures

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

* [MongoDB](/self-hosting/databases/mongodb#backup--restore)
* [Elasticsearch or OpenSearch](/self-hosting/databases/elasticsearch#backup--restore)
* [Redis](/self-hosting/databases/redis#backup--restore)
* [PostgreSQL](/self-hosting/databases/postgresql#backup--restore)

### Object Storage restore

```bash theme={null}
# 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

<Steps>
  <Step title="Restore Kubernetes Resources">
    Apply your backed-up Kubernetes configurations:

    ```bash theme={null}
    # 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
    ```

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

      ```bash theme={null}
      # 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
      ```
    </Warning>
  </Step>

  <Step title="Restore Helm Releases">
    Use your backed-up values to reinstall or upgrade Helm releases:

    ```bash theme={null}
    # Reinstall core
    helm upgrade --install prisme-core prisme/prisme-core \
      -f /path/to/backup/helm/YYYY-MM-DD/prisme-core-values.yaml \
      --namespace prisme-system

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

    # Repeat for other product modules
    ```
  </Step>

  <Step title="Restore Terraform State">
    If you need to restore Terraform state:

    ```bash theme={null}
    # 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.
  </Step>
</Steps>

## Disaster Recovery Planning

<Tabs>
  <Tab title="Recovery Objectives">
    Define your recovery objectives to guide your backup strategy:

    <CardGroup cols={2}>
      <Card title="RPO (Recovery Point Objective)" icon="clock-rotate-left">
        Maximum acceptable data loss in time:

        * Critical data: RPO \< 1 hour
        * Important data: RPO \< 24 hours
        * Regular data: RPO \< 1 week
      </Card>

      <Card title="RTO (Recovery Time Objective)" icon="stopwatch">
        Maximum acceptable time to restore service:

        * Critical services: RTO \< 4 hours
        * Important services: RTO \< 24 hours
        * Regular services: RTO \< 3 days
      </Card>
    </CardGroup>
  </Tab>

  <Tab title="DR Scenarios">
    Plan for different disaster recovery scenarios:

    <Accordion title="Single Component Failure">
      **Example:** MongoDB database corruption

      **Recovery Plan:**

      1. Scale down dependent services
      2. Restore MongoDB from most recent backup
      3. Verify data integrity
      4. Scale up services
      5. Monitor application functionality
    </Accordion>

    <Accordion title="Entire Platform Failure">
      **Example:** Kubernetes cluster compromise

      **Recovery Plan:**

      1. Deploy new Kubernetes cluster
      2. Restore configuration (secrets, configmaps)
      3. Reconnect to database services (if intact)
      4. Restore databases if necessary
      5. Deploy Helm charts with backed-up values
      6. Verify connectivity and functionality
    </Accordion>

    <Accordion title="Datacenter/Region Failure">
      **Example:** Cloud provider region outage

      **Recovery Plan:**

      1. Activate secondary region (if configured)
      2. Restore from cross-region backups
      3. Update DNS/load balancing to point to new region
      4. Verify application functionality
      5. Communicate status to users
    </Accordion>
  </Tab>

  <Tab title="DR Testing">
    Regularly test your disaster recovery procedures:

    <Steps>
      <Step title="Scheduled Testing">
        Conduct regular DR tests:

        * Quarterly: Component-level recovery
        * Bi-annually: Full platform recovery
        * Annually: Regional failover (if applicable)
      </Step>

      <Step title="Test Documentation">
        Document each test with:

        * Date and scope
        * Procedures followed
        * Time to recover
        * Issues encountered
        * Improvements identified
      </Step>

      <Step title="Continuous Improvement">
        Update procedures based on test results:

        * Optimize recovery scripts
        * Improve automation
        * Address gaps or failures
        * Update documentation
      </Step>
    </Steps>
  </Tab>
</Tabs>

## Testing and Validation

<Steps>
  <Step title="Verify Backup Integrity">
    Regularly test your backups to ensure they can be restored:

    ```bash theme={null}
    # 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
    ```
  </Step>

  <Step title="Validation Checkpoints">
    Establish validation points for successful restoration:

    <CardGroup cols={2}>
      <Card title="Data Validation" icon="database">
        * Record counts match pre-backup state
        * Sample record content is intact
        * Relationships between data are preserved
        * Application-specific data tests pass
      </Card>

      <Card title="Functionality Validation" icon="check-circle">
        * Core services start successfully
        * API endpoints respond correctly
        * Authentication and authorization work
        * Data processing functions operate properly
        * UI elements display and function as expected
      </Card>
    </CardGroup>
  </Step>

  <Step title="Document Restoration Procedures">
    Maintain detailed, tested restoration runbooks:

    * Step-by-step instructions
    * Required credentials and access
    * Validation checkpoints
    * Troubleshooting guidance
    * Contact information for support
  </Step>
</Steps>

## Next Steps

<CardGroup cols={3}>
  <Card title="Updates" icon="arrow-up-right-dots" href="/self-hosting/operations/updates">
    Keep your platform current with the latest updates
  </Card>

  <Card title="Scaling" icon="arrows-up-down-left-right" href="/self-hosting/operations/scaling">
    Scale your platform to meet growing demands
  </Card>
</CardGroup>