Log inSign upBook a demo
Tines Stories
  1. Docs
  2. Self-Hosted
  3. Best Practices
  1. Docs
  2. Self-Hosted
  3. Best Practices

Migration and Disaster Recovery (Kubernetes)

Last updated

Use this to bring your Tines installation back after a cluster is lost, or to move it to a new database. Restore your database, install Tines against it, and empty your cache before Tines starts.

The backup and restore commands are in Data backup recommendations. Installing the chart is covered in Helm Charts.

Restore your database

Scale your running installation to zero first, so nothing writes during the restore. Infrastructure maintenance uses these deployment names. Check kubectl get deploy -n tines and use the names you see there.

kubectl scale deploy -n tines --replicas=0 tines-app tines-sidekiq

Restore your latest backup to a new PostgreSQL instance and wait until it accepts connections. A copied data directory has to go back onto the same PostgreSQL major version. A pg_dump file can go onto that version or a newer one.

Deploy the same Tines version you were running, or a newer one. On startup, Tines migrates an older database. A newer database will not run on an older Tines.

Install Tines against your restored database

Follow our Helm Charts, and keep your original configuration: TENANT_NAME, DOMAIN, APP_SECRET_TOKEN, your database credentials, and your field-level encryption keys. Tines reads your tenant name and domain from the environment on startup. Your encryption keys are what make the restored credentials readable.

For a hosted database, set db.create to false and point DATABASE_HOST at your restored instance:

db:
  create: false

tinesApp:
  databaseConfiguration:
    DATABASE_HOST: <restored-database-host>
    DATABASE_NAME: tines_production
    DATABASE_USERNAME: tines
    DATABASE_PASSWORD: <password>
helm install tines-app tines/tines \
  -n tines \
  -f values.yaml

The tines-app-setup job migrates your database and then seeds it. Seeding stops when your restored database already contains a tenant. Follow it with:

kubectl logs -n tines job/tines-app-setup

To move your existing release, change DATABASE_HOST and run helm upgrade with the same values file. Leave your deployments at zero until your cache is empty.

If the chart created your database, restore your backup into that database before tines-app and tines-sidekiq start.

Clear or restore your cache, then start Tines

Valkey and Redis hold your sign-in sessions and queued jobs. Decide which case applies:

  • If your Valkey or Redis cluster was also lost, skip this step. A new cache starts empty.

  • If your cache is still running and you don't have a cache backup from the same time as your database backup, flush it. It holds sessions and jobs for data your restored database no longer has.

  • If you have a cache backup taken at the same time as your database backup, restore that backup instead and point REDIS_URL at it. Skip the flush.

To flush, run:

kubectl exec -n tines <cache-pod> -- redis-cli -n <database-number> FLUSHDB

Start Tines again by scaling your tines-app and tines-sidekiq deployments back to their previous replica counts. Sign in and confirm that your stories, credentials, and cases are present. If you flushed or started with an empty cache, you sign in again and queued jobs from before the restore are gone.

Was this helpful?