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 (Fargate)

Last updated

Use this to restore your Fargate deployment from an RDS snapshot. Restore your snapshot to a new database, point your tasks at it, and empty your cache before those tasks start.

Keep your existing tines.env. Change DATABASE_HOST, and change REDIS_URL only when your cache endpoint changes. Leave your TENANT_NAME, DOMAIN, APP_SECRET_TOKEN, database credentials, and field-level encryption keys as they are. Your encryption keys are what make the restored credentials readable.

Backups are covered in Data backup recommendations. For Kubernetes, see Migration and Disaster recovery (Kubernetes).

Restore your database

In RDS, take a snapshot of your database, or use the snapshot you already have. Wait for it to finish.

In Elastic Container Service, set the desired task count to zero for your tines-app, tines-sidekiq, and tines-command-runner services. Leave them at zero until your cache is ready.

Restore the snapshot to a new database in the same VPC. Choose your existing subnet group and security group, so your tasks can still reach it. Wait for the new endpoint.

Point Tines at your new database

Set DATABASE_HOST in your tines.env to the new endpoint. Upload that file to the same S3 location your tasks already read. Your tasks read it when they start.

aws s3 cp tines.env s3://<env-bucket>/tines.env

If you store DATABASE_HOST in Secrets Manager, update that secret instead.

Decide which of these applies before you touch ElastiCache:

  • If ElastiCache was also lost or deleted, skip this step. A new cluster starts empty.

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

  • If you have an ElastiCache snapshot taken at the same time as your RDS snapshot, restore that snapshot instead and point REDIS_URL at it. Skip the flush.

To flush, run this from a host inside your VPC:

redis-cli -h <cache-endpoint> -n 1 FLUSHDB

Add -a <password> when your REDIS_URL contains a password, and --tls when it begins with rediss://.

Start Tines

Set the desired task count for each of your services back to what it was. Open Tines and sign in. Confirm that your stories, credentials, and cases are present. You sign in again after your cache is emptied, and queued jobs from before the restore are gone unless you restored ElastiCache from the same snapshot.

Was this helpful?