Short answer
Choose a backup folder, create the first backup and confirm that the new file appears.
Keep a protected copy on another physical device. If the database is ever damaged, the app can offer a valid automatic backup during startup.
When to use this method
Use this workflow for local database backups and damage recovery. It does not provide cloud sync, whole-PC backup or disaster recovery. Regular history remains unencrypted, so protect the backup folder like the live database.
Backup and recovery behaviorDatabase consistency, restore safeguards and off-device risk.
- How recovery works
- Automatic backup remains disabled until a directory is configured. When startup detects damage, recovery checks automatic backups, chooses the newest valid copy and preserves rollback material before activation.
- Important limit
- Seven rotating copies on the same failing SSD are not an off-device backup. Place at least one protected copy on independent storage and verify it before an emergency.
Choose the right kind of copy
App backup
The app creates a complete history copy and checks that it can be read. Locked Notes remain encrypted inside it; regular history remains unencrypted.
JSON export
JSON is the portable format intended for later import. Export offers privacy choices for images, file snapshots, Locked Notes and sensitive items. Read every option before creating a backup, then store that file only in a location you trust.
CSV or Favorites-only export
CSV is useful for a readable table, not for recreating every rich clipboard payload. A Favorites-only JSON export is useful when you need those lasting items without the full history.
Create and verify a recoverable copy
Select a separate destination
Open Settings. Choose Backup. Select a folder outside the active application-data directory. You should see the folder path in Backup settings. A second folder on the same SSD protects against accidental file deletion but not a failed, lost or encrypted drive. Keep another copy on independent, access-controlled storage.
Set interval and retention
Choose an interval from 1 to 168 hours. Choose how many copies to keep, from 1 to 30. Select Save Schedule. You should see the saved values remain in Backup settings.
Why this matters: The starting values are 24 hours and 7 copies. A shorter interval limits potential loss but writes more often. More retained copies improve the chance of finding one made before unnoticed damage.
Create an immediate checkpoint
Select Back Up Now. Wait for completion, then confirm a new timestamped database appears in the selected folder. A configured schedule is not evidence that the first backup already exists.
Check the backup file
Open the selected backup folder in File Explorer. Confirm that the newest backup has a recent time and a nonzero size. Do not rename a random SQLite file to make it look like an app backup.
Keep one copy away from the PC
Copy a recent backup to a protected external drive or another trusted device. Eject removable storage safely. You should see one backup in the app's folder and one independent copy.
Respond to a database-health warning
The app checks database health weekly and after an unclean shutdown. If it detects damage during startup, it opens a recovery dialog. This is when restore choices appear.
Do not overwrite the damaged database
The recovery flow preserves the damaged database family instead of silently replacing it. Keep those files until a verified restore works or a specialist confirms they are unnecessary.
Read every recovery choice
Restore verified backup uses the newest automatic backup that passes the database check. Start empty creates a clean database and does not recover missing history. Exit safely closes the app without choosing. Read the dialog before continuing.
Import only after the app is stable
If you also have a JSON export, use the app's Import command only after history opens normally. The app imports the file as one transaction, so an error should not leave only part of the data behind.
Recovery gaps
- Leaving the backup directory unset
- Keeping every copy beside the live database
- Assuming Backup settings contain a manual restore picker
- Assuming retention protects against physical drive loss
Checkpoint: prove the backup
- Confirm the destination differs from live storage.
- Create and timestamp one manual backup.
- Confirm the backup file has a recent time and nonzero size.
- Keep one independent copy away from the live database.
- Know that restore choices appear only after detected damage.
Changing the live database path is not a restore
A database-path change takes effect after the app restarts and does not silently move existing history. Record the old and new paths, make a verified backup, and use the recovery dialog or import flow when data must move. Simply pointing at an empty location can make the app appear to have lost history even though the old database is still elsewhere.
Osenpa Clipboard Manager
Create consistent local database backups and understand the safe choices shown if the app later detects database damage.