When it comes to backups, many people think copying the database file is enough. It's only when they switch servers or accidentally delete data that they discover: the database opens, but the DeepSeek keys and payment private keys inside can't be decrypted at all; or the database comes back, but images and attachments are all gone. This article explains the backup scope, scheduled tasks, and restore process of KingCMS X1 clearly.
What one-click backup actually does
The backup in the admin panel doesn't directly copy the database file being written to; instead, it uses SQLite's online backup interface to take a consistent snapshot, so it can back up even while visitors are on the site. After each backup, it runs a PRAGMA integrity_check; files that fail validation are not recorded as valid backups. Each record stores the file name, size, SHA256, source (manual/scheduled/pre-restore), creator, and time; by default it is compressed with gzip into .sqlite.gz. When "Include uploaded files" is checked, the database and data/uploads/ are packed into a single zip.
The easiest thing to miss: app.key
data/app.key is not included in backups. It is responsible for decrypting the key fields in settings—the DeepSeek API Key, payment private key, and third-party API keys all depend on it. If you only restore the database and not app.key, these configurations become ciphertext that cannot be decrypted. When switching servers or reinstalling the system, back up data/app.key separately, take it with you, and never commit it to any repository.
What to take with you when switching servers
The entire data/ directory is the safest: the database, uploads/ uploaded files, app.key, and the backups/ backup records. If you only migrate the database, remember to bring app.key and uploads/ separately; the usual result of bringing only the database is "pages open, all images broken, key errors."
Scheduled backups
Under "Settings → Security & System → Data Backup" you can configure: automatic backup interval (off/daily/weekly, executed every Monday), execution time (default 03:15, according to the site time zone), maximum number of copies to keep (default 15; when exceeded, the oldest scheduled backups are automatically deleted, while manual backups and pre-restore backups are not automatically deleted), and whether to compress. Scheduled backups only back up the database, not uploaded files.
Scheduled backups depend on the scheduler running cron:run once per minute. In the BT Panel, create a Shell task under "Scheduled Tasks" and set the interval to 1 minute; run the command as the user that runs the website to avoid incorrect file ownership. Without a scheduler, automatic backups will not trigger, and you can only click manually in the admin panel.
Restore process
In the backup list, expand "Restore" and enter the site name or "确认". The system first validates the selected file and rejects it directly if validation fails; .sqlite.gz is first decompressed to a temporary file and then validated. After validation passes, it automatically creates a "pre-restore" backup, then overwrites the current database with the backup data, keeping the current database structure (migration records are not restored), and finally clears all login sessions, so the administrator needs to log in again. Restore overwrites current data, so it's best to do it during off-peak hours and confirm you've selected the correct copy.
Also tidy up the database
After deleting data, the SQLite file does not automatically shrink; the space remains in free pages. The weekly maintenance task runs VACUUM, and you can optionally run PRAGMA optimize after maintenance. Before maintenance, if there has been no successful backup within 24 hours, it will automatically make a backup first; if the lock cannot be acquired or the database is in use, it skips and tries again in the next cycle. Maintenance holds a write lock, so scheduling it during off-peak hours is more reliable.
Summary
Remember three things: backups must include app.key and uploaded files; scheduled backups only back up the database and depend on cron:run every minute; the system automatically makes another backup before restoring, but overwriting is irreversible. Write these three items into your operations checklist—it's much less stressful than trying to recover after something goes wrong.