deleted a dsh session? 3 places to recover it

Whether a deleted session is recoverable depends on which layer you deleted: registry state, files on disk, or context inside the session. The three layers have different recovery sources.

Identify the layer first

"Deleted" has three meanings and three recovery paths.

Gone from the list but still on disk is usually archive. Only the registry changed; recovery does not touch files.

A missing directory is real deletion. Files do not go to a trash bin; recovery depends on a backup or snapshot made earlier.

A shorter history is cleared context. Logs often remain; what you recover is display, not files.

Source one: the archive view

If the session was archived, recovery takes two steps.

1. Open the session list on desktop or web and enter the archive view.
2. Find the session and unarchive it.
3. Refresh and confirm it reappears.
4. Open it and check message completeness; missing messages mean more than archive.

Both clients read the same registry. Unarchiving on desktop is visible on web after refresh, and vice versa. Different machines are independent.

If the archive view does not contain it, it is not archive. Move to disk checks instead of refreshing the UI.

Source two: backup and snapshot

After a directory deletion, a backup is the only reliable source.

1. Stop the service immediately to avoid overwriting recoverable data.
2. Locate backups: full-directory copies, sync-drive copies, or filesystem snapshots; prefer the most recent.
3. Restore to the original path: keep the directory structure and restore logs and indexes together.
4. Start and verify: check the list, open the session, and confirm messages and search.

Snapshots are more reliable than file copies. Copying while running can capture a half-written state; a snapshot is point-in-time consistent.

Restoring to the original path is safer. Session indexes relate to paths or IDs; moving paths can produce "listed but will not open."

Do not delete the backup immediately. Keep it until the restored data runs stably; otherwise a second failure has no fallback.

Source three: logs and index residue

When only some files were deleted, residue may recover part of the session.

1. Preserve the original files and avoid repeated starts or rebuilds that overwrite residue.
2. Compare logs and index: logs present with a missing index can be rebuilt; index present with missing logs recovers metadata only.
3. Fill gaps from backup rather than replacing the whole directory.
4. Verify completeness: messages, order, attachments, and search; record breaks and stop writing.

Partial recovery aims for readable, not complete. Missing a few messages beats not opening at all, but do not mistake it for full recovery.

Index rebuild is risky. It overwrites the current index; copy it first and, without a backup, ask before acting.

Recovery order: stop first

Every recovery follows stop, back up, replace, start, verify.

1. Stop DeepSeek Harness and related services; confirm nothing is writing.
2. Copy the current residue to a temporary location as a rollback point.
3. Restore the target directory from backup or snapshot, keeping the path.
4. Start the service and check the list, then open the session.
5. Verify messages, attachments, and search; if anything fails, return to the temporary copy.

Back up before replacing. Without a rollback point, a second failed attempt is final.

Verification must be specific. Not just "it opens," but message count, attachment readability, and search hits.

Three unrecoverable cases

Some deletions cannot be recovered; knowing early is better.

1. Directory deleted with no backup and no snapshot. Filesystems have no trash bin; recovery probability is very low.
2. Heavy writing after deletion. New data may overwrite the original blocks.
3. Both index and logs missing. No metadata and no content means nothing to rebuild from.

When these occur, stop rather than salvage. Stop writing, preserve the state, and assess impact; do not scan repeatedly with unknown tools.

If recovery is impossible, rebuild. Collect conclusions, attachments, and links into a new session; it produces more than chasing old files.

Prevention: backup strategy

The best recovery is a backup, not a technique.

1. Regular full-directory backup: copy DSH_HOME including configuration, sessions, and plugins; partial backups leave gaps.
2. Copy before deletion: duplicate the target session directory; cheap and high value.
3. Filesystem snapshots: enable daily snapshots where possible to cover deletion and modification.

Verify backups are readable. A backup never opened is not a backup; periodically inspect directory structure and files.

Store backups separately. On the same disk, a disk failure loses both; keep at least one copy elsewhere.

Next steps

Identify the layer, then choose a source. For the conceptual difference, read Archive vs delete session. For three-client deletion, read Deleting sessions across desktop, web, and CLI. For cleanup instead of recovery, read What remains after uninstalling.

Sources: DeepSeek Harness docs, dsh CLI README, deepseek-harness repository