Skip to content

Backups and recovery

Backups happen automatically. You don’t have to think about them most days. This chapter is what they cover, how often they run, and how to restore when you need to.

Your instance’s full state, including:

  • The PostgreSQL database (conversations, projects, knowledge graph, all entities).
  • Uploaded files and generated artifacts.
  • Configuration: settings, channels, integration metadata (without secrets — they’re managed separately).
  • Playbooks, goals, and installed toolkit configurations.

What’s NOT backed up:

  • API keys and credentials. These are encrypted with your instance’s encryption key and held in a different system. They’re not in the daily backup; they’re protected separately.
  • Ephemeral caches and indices. They’re regenerable.

The default schedule, applied to all instances:

  • Hourly snapshots of the database, retained for 24 hours.
  • Daily full backups retained for 30 days.
  • Weekly archives retained for 90 days.
  • Monthly cold-storage backups retained for 1 year (Business plan and above).

Most customers don’t need more than the defaults. If you have stricter retention requirements (regulatory or operational), we can configure longer windows on Business / Enterprise plans.

Backups are stored in encrypted form in our cloud provider’s backup storage, in the same region as your instance (or a paired region for redundancy).

Backups are NOT stored on your instance’s primary disk. They are NOT accessible to anyone except Jootle’s operational team and you (on request).

The cases that come up:

For deletes within the last 24 hours, ask in chat:

“Restore the artifact I deleted yesterday on the kitchen project.”

Your AI can pull from recent snapshots and restore specific items without a full restore. No support ticket needed.

”I want to roll back the whole instance to a point in time.”

Section titled “”I want to roll back the whole instance to a point in time.””

For larger restorations (the last day, the last week), email support@jootle.com with:

  • The target time you want to restore to.
  • Whether you want a full restore (overwrites current state) or a side-by-side restore (a new instance with the restored data, your current one untouched).

Side-by-side is the safer default; you get a chance to compare and decide.

Full restores have a turnaround of a few hours for most plans, faster on Business / Enterprise plans with priority support.

”I want to migrate to a fresh instance.”

Section titled “”I want to migrate to a fresh instance.””

This is technically a backup-and-restore operation. Talk to support; we’ll set it up. You’d typically do this if you wanted to change geographic region, or if you wanted a clean slate while keeping old data around for reference.

What can you restore:

  • A single item (artifact, project, list, contact) from the past 24 hours: self-service via chat.
  • A specific user’s data from the past 30 days: through support.
  • The full instance from any point in the retention window: through support.

Cross-cutting restores (e.g., “restore everything related to the kitchen project to last Tuesday”) require a manual operation; we can do it but it’s slower than the canned options.

A reasonable question. The safeguards:

  • Your data is exportable at any time. See Data, privacy, and exports. Run an export periodically if you want a snapshot you control.
  • Source code escrow for Enterprise plans, on request.
  • Annual export reminder for customers who’d like one. Settings → Data → Annual export reminder.

The export is in open formats (JSON, plus standard file types for uploaded content). It’s not held hostage by any proprietary format.

Backups are monitored. If a scheduled backup fails:

  1. The operational team is alerted.
  2. The backup is retried within a short window.
  3. If retries fail, you’re notified by email.
  4. We investigate the root cause and resolve.

This is rare but worth knowing. Backups failing silently would be the worst case; we’d rather you know.

You can trigger an on-demand backup at any time from Settings → Data → Create snapshot now. Use cases:

  • Before a major change you’re nervous about.
  • Before you delete something irreversibly.
  • Before importing a large toolkit or running a batch operation.

On-demand snapshots count toward your retention quota the same as scheduled ones.

For Business and Enterprise plans, we periodically run test restores into an isolated environment to verify backup integrity. You don’t see this; we do it operationally. If a backup is found to be corrupt, you’re notified and we re-snapshot.

In the case of a regional outage at our cloud provider:

  • Backups stored in paired regions allow recovery of your instance in an alternative region.
  • The recovery time objective (RTO) for individual instances is hours, not days.
  • The recovery point objective (RPO) is at most 1 hour (the last hourly snapshot).

We have a documented DR plan. We rehearse it. Cloud provider regional outages are rare events but do happen; we’d rather over-prepare than discover the gaps mid-incident.

Backups protect against data loss. They do not protect against:

  • A user with appropriate permissions doing something they regret. (“I told my AI to delete all my emails for the last year.”) Backups make this recoverable, but the original action was authorized.
  • A bad actor with credentials. If your password is compromised, the attacker can do anything you can do. See Security for prevention.

Backup is a recovery mechanism, not a substitute for good operational habits. Both layers matter.