Back Up and Recover Local Clipboard History

Choose the right kind of copy

1. 1. App backup

   The app creates a database backup and verifies its integrity. Locked Notes remain encrypted inside it; regular history remains unencrypted.

2. 2. JSON export

   Export JSON transfers supported text records, tags, Smart Collections and saved Stack Profiles for later import. Ordinary History images, rich payloads and file-snapshot bytes are omitted; Locked Notes are omitted too. Saved Stack Profiles can contain their own embedded content. There is no export privacy-selection dialog, so review the file and protect it like regular history.

3. 3. 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

1. 1. 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.

2. 2. 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.

3. 3. Create an immediate checkpoint

   Select Back Up Now. Wait for the Backup created message, then find the named, timestamped database in the selected folder. A saved schedule is not evidence that the first backup already exists. If the message reports a failure, check that the folder still exists, is writable and has free space, then retry and check the new message.

   

4. 4. 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. This shows a file was created; it does not by itself prove that every item can be recovered. Do not rename a random SQLite file to make it look like an app backup.

5. 5. 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.

1. 1. 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.

2. 2. Read every recovery choice

   Restore verified backup appears only when a usable backup was found. It uses the newest automatic backup that passes the database check, so copies made after that backup can be missing. Start empty creates a clean database; it does not recover history. Choose Exit safely if no usable backup is offered and you still need the old data. Keep the preserved files instead of replacing them by hand.

3. 3. 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. Make a database backup first. Import adds supported records and skips duplicates or unsupported records. A later error can leave earlier records imported, so check the reported counts, History, collections and profiles before deciding whether to retry.