Backups
Per-app backups, scheduled automation, and one-command restore.
Talome backs up individual apps as compressed tarballs — volumes, configuration, and environment variables in a single file. Restore from any backup with one message.
What Gets Backed Up
| Included | Description |
|---|---|
| Docker volumes | All named volumes attached to the app's containers |
| Configuration files | App config files within the Talome data directory |
| Environment variables | The .env and compose environment from the running stack |
| Compose file | The docker-compose.yml used to create the stack |
| Not Included | Why |
|---|---|
| Docker images | Images are pulled from registries — backing them up wastes space. On restore, the exact image is re-pulled using the pinned digest. |
| External mounts | If you bind-mounted /mnt/media into Jellyfin, that media is not included. Back up external storage separately. |
Per-App Backup
Creating a Backup
The backup_app tool:
- Pauses the app's containers to ensure data consistency
- Creates a tarball of all attached Docker volumes
- Includes the compose file and environment variables
- Compresses the archive with gzip
- Stores the backup in
~/.talome/backups/<appId>/<timestamp>.tar.gz - Resumes the containers
- Records the backup in the
backupsdatabase table
The entire process typically takes seconds for small apps, or a few minutes for apps with large databases.
Backing Up Multiple Apps
The AI iterates through each app and creates individual backups. Each backup is independent — you can restore them individually.
Viewing Backup History
The backups table tracks every backup run: app ID, timestamp, file size, duration, and success/failure status. The backup-status dashboard widget shows this at a glance.
Restoring from Backup
The restore_app tool:
- Stops the app's containers
- Removes the current volumes
- Extracts the backup tarball into fresh volumes
- Restores the compose file and environment variables
- Pulls the exact Docker image using the pinned digest
- Starts the app
- Verifies health
Restoring replaces all current app data with the backup contents. If you've made changes since the backup, those changes will be lost. Consider creating a fresh backup before restoring an older one.
Restoring to a Specific Point
If you have multiple backups, specify which one:
Scheduled Backups
Use automations to run backups on a schedule:
The automation engine runs backup_app on the cron schedule you specify. Failed backups are logged and can trigger notifications:
Recommended Schedule
| Apps | Frequency | Why |
|---|---|---|
| Databases (Sonarr, Radarr, Prowlarr) | Daily | Small backups, frequent config changes |
| Media servers (Jellyfin, Plex) | Weekly | Larger backups, less frequent changes |
| Everything else | Weekly | Good baseline protection |
Database Backup
Talome's own data lives in a SQLite database. This includes your settings, memories, automations, installed app metadata, and backup history.
The simplest backup:
cp ~/.talome/data/talome.db ~/.talome/data/talome.db.backupOr use the AI:
The SQLite database is typically under 10MB. Include it in your system-level backup strategy (rsync, Borg, Restic, etc.) alongside the ~/.talome/backups/ directory for complete disaster recovery.
Pre-Update Backups
Talome automatically creates a backup before updating an app. If the update fails or breaks something, you can roll back:
The rollback_update tool restores the pre-update backup and reverts to the previous image digest. This is separate from the restore_app flow — it specifically targets update failures.
Conversation Examples
Full backup workflow
Disaster recovery
The AI stops Sonarr, restores the backup, starts it back up, and verifies the healthcheck passes.
Pre-migration backup
The AI backs up every installed app and tells you the total backup size and location, so you can copy the ~/.talome/backups/ directory to the new server.