Local recovery

Back Up and Recover Local Clipboard History

Set up local clipboard backups, learn what each copy contains, and practice a restore before you need one.

By Osenpa Published Reviewed

Short answer

Automatic backup stays off until you choose a folder. You can save a database copy every 1 to 168 hours and keep 1 to 30 copies.

During a restore, the app checks the selected backup first and keeps a rollback copy. Store at least one backup on a different physical device, because several copies on one failing drive are still one point of failure.

When to use this method

This guide covers the app's local database backup and recovery workflow. It does not turn clipboard history into cloud sync, file backup or disaster recovery for the whole PC. Regular history is not encrypted, so protect the backup folder as carefully as the live database.

How we checked this guideDatabase consistency, restore safeguards and off-device risk.
What we reviewed
Reviewed opt-in backup directory, interval, retention pruning, SQLite backup, integrity verification, staged restore and pre-restore rollback behavior against the current Osenpa Osenpa Clipboard source.
What we confirmed
Automatic backup remains disabled until a directory is configured. Restore checks the database, stages the replacement 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

Database backup

This is the recovery copy used by the app. It is made through SQLite's consistent backup process and then checked for integrity. Locked Notes remains encrypted inside it; regular history remains regular unencrypted database data.

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 and select a folder outside the active application-data directory. 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 and keep 1 to 30 copies. The starting values are 24 hours and 7 copies, but both are adjustable. A shorter interval reduces potential history loss and creates more write activity. More generations give you more chances to reach a copy made before unnoticed corruption.

Create an immediate checkpoint

Select the manual backup action. 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.

Verify before restoration

Select the intended backup inside the recovery workflow and let the app verify it. A corrupt or incompatible database should be rejected without half-writing current data. Do not rename a random SQLite file to make it look like an app backup.

Restart and sample restored data

After a controlled test restore, reopen Osenpa Clipboard Manager and check harmless samples from History, Favorites, tags, Smart Collections and Stack Profiles. If Locked Notes is included, unlock one disposable test note. Keep rollback material until the restored data has passed these checks.

Respond to a database-health warning

The app checks database health weekly and after an unclean shutdown. If the live database is damaged, the safe goal is to preserve evidence before choosing recovery.

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.

Choose a verified backup or a clean database

A verified backup can recover earlier data. A clean database starts fresh and does not recover missing history. Read the choice carefully before continuing.

Import only after the app is stable

If you also have a JSON export, import it through the supported transaction after the active database opens normally. A corrupt import should not be allowed to leave half of its records behind.

A backup needs testing

Recovery gaps

  • Leaving the backup directory unset
  • Keeping every copy beside the live database
  • Restoring an unchecked file
  • Assuming retention protects against physical drive loss
Rehearse safely

Checkpoint: prove the backup

  • Confirm the destination differs from live storage.
  • Create and timestamp one manual backup.
  • Pass database integrity verification.
  • Retain the pre-restore rollback copy until sampled records open.
  • Test Locked Notes only with a disposable note and confirm it still requires the correct PIN or passphrase.

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 supported restore 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.

Clipboard history in Osenpa Clipboard Manager
Step by step

Osenpa Clipboard Manager

Create consistent local database backups, verify them before use and keep rollback material until restored data has been checked.