Backups
one command, every night, off the server.
Everything Kinetica stores is in DATA_DIR. npm run backup packs it safely while the server runs, and npm run restore brings it back into an empty folder.
01What is in DATA_DIR
| In DATA_DIR | What it is | In a backup |
|---|---|---|
studio.sqlite | Accounts, workspaces, videos, renders, credits, payments | Always |
admin.sqlite | Console: settings, encrypted keys, team, audit log | Always |
.admin-secret-key | The generated secret key (only when ADMIN_SECRET_KEY is not in .env) | When it exists |
files/assets | Every workspace's uploads | Always |
files/music | The music library | Always |
files/renders, files/voicecache | Rendered videos and cached voiceovers | Only with --with-renders |
Rendered videos can be rendered again and are usually the largest part, so they are left out unless you ask.
02Make a backup
In the Kinetica folder:
npm run backup
# Docker:
docker exec kinetica npm run backup
It writes kinetica-backup-YYYYMMDD-HHMMSS.tar.gz into DATA_DIR/backups (or BACKUP_DIR when set). It is safe while the server runs: the databases are copied with SQLite's online backup, checked with SQLite's integrity check, and only then packed. The archive is readable by its owner only. With Docker it lands in the data volume under /app/data/backups.
Option (after --) | Effect |
|---|---|
--out /mnt/backups | Write somewhere else this time |
--keep 14 | Afterwards delete all but the newest 14 backups in that folder |
--with-renders | Include rendered videos and cached voiceovers |
The console's System health page shows when the last backup was made and where it is.
03Every night
crontab -e as the user that runs the studio, and add (change the folder to yours):
0 3 * * * cd /opt/kinetica && /usr/bin/npm run backup -- --keep 14 >> backup.log 2>&1
With Docker, in the host's crontab:
0 3 * * * docker exec kinetica npm run backup -- --keep 14 >> /var/log/kinetica-backup.log 2>&1
A backup on the same disk is lost with the disk. For example, from another machine: rsync -a server:/opt/kinetica/data/backups/ ~/studio-backups/. A backup contains your customers' data and, when the key was generated, the key that opens the saved API keys: store it like a password. If ADMIN_SECRET_KEY is in .env, the backup does not contain it; keep a copy of that line with your backups.
04Restore
A restore goes into an empty DATA_DIR only, so it can never mix two installs.
- Stop the server
sudo systemctl stop kineticaordocker stop kinetica. - Move the old data away
mv data data-old(abackupsfolder alone inDATA_DIRmay stay). - Restore
npm run restore data-old/backups/kinetica-backup-20261109-030000.tar.gz - Start the server again.
The restore checks the archive and both databases before it moves anything into DATA_DIR, and warns when the backup was made with a newer Kinetica than the one installed (install that version first), or when ADMIN_SECRET_KEY in .env is not the key the backup was made with (put the old key back, or enter the API keys again).
With Docker, restore into a new volume from a stopped container:
docker volume create kinetica-data-restored
docker run --rm --env-file .env -v kinetica-data-restored:/app/data -v "$PWD/backups:/restore:ro" \
kinetica npm run restore /restore/kinetica-backup-20261109-030000.tar.gz
Then start the container with -v kinetica-data-restored:/app/data.