Backups & Data Export

Every Sarudo instance takes a full backup at 03:00 server time every day. Each backup is a single compressed tarball containing a `pg_dump` of your entire Postgres database, your configuration files (`config.yaml` and the `.env` secrets), the full `skills/` directory, the `custom-tools/` tool-server source, the local knowledge store on disk, and any per-instance config under `/var/lib/sarudo/config/`. In one file, that is everything needed to reconstruct your instance from a clean base image. Backups are written to `/var/lib/sarudo/backups/` on your dedicated server and are automatically retained for 30 days — anything older is deleted to keep the backup directory from growing forever.

Before a risky operation — a major workflow change, a bulk CRM import, a schema migration, anything where you want a fresh snapshot you can roll back to — you can trigger a backup on demand. Ask your AI employee "take a backup" and it calls the admin endpoint, runs a fresh `pg_dump`, and reports back with the backup filename, timestamp, and size. One important detail: the on-demand backup captures the Postgres database, not the full tarball — if you need the full config+skills+knowledge snapshot, say so explicitly and your AI employee will use the full-backup script instead of the quick pg_dump path.

You can check the backup directory status at any time. "Show me the backup status" returns the latest backup filename, the total count of backups retained, and the disk usage of the backup directory. If you have a specific old backup you want to remove before the 30-day retention clock naturally expires it (for example, to free disk space after a particularly large one-off backup), your AI employee can delete a specific file by name. The retention cron keeps running regardless — so you do not need to prune manually as routine maintenance.

Restoring is a setup-team operation, not a self-service one. The rationale: a restore is destructive — it overwrites current state with an older snapshot — and doing that correctly requires pausing the live services, applying the restore in the right order (schema first, then data, then file assets), and then restarting cleanly. If you need to restore, contact the setup team with the specific backup filename you want to restore from (use "list my backups" to find it), a description of what you are trying to recover, and whether you want a full restore or just a specific table / a specific section of data. Most restores land within the hour.

You own all of your data, as stated in the Data Ownership section of Security & Privacy. If you ever want a full copy of everything your Sarudo instance has — whether for compliance, for archival, or because you are migrating off Sarudo — contact the setup team. The export is a single encrypted archive containing a SQL dump of the database, every uploaded document, every generated artifact (meeting transcripts, Google Doc references, blog drafts), every skill and configuration file, and a summary manifest that maps the structure. You provide a public key, we encrypt to it, and you have a complete portable copy of the instance.