## TL;DR
Borg's cache records what it believes the repository contains, and when that cache is damaged borg refuses to create rather than guess: rebuild the cache from the repository, which borg can do by deleting the local cache directory and letting the next command reconstruct it, after confirming the repository itself passes a check. The repository is the source of truth; the cache is a performance index, so rebuilding it loses nothing but time.

```text
borg create failed "Cache integrity data not available: cache is damaged"
```

## Use this when
- The job or restore fails with this symptom: borg create failed with Cache integrity data not available: cache is damaged.
- You are working on a borg create failing on damaged local cache data and the failure repeats on the same target or schedule.
- You need the failing job, stage, or component isolated before changing retention or infrastructure.

## Not for this skill when
- A damaged repository rather than cache, where borg check errors, not cache messages, lead and the fix is repository repair.
- The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Run borg's repository check in read-only fashion to confirm the repository itself is sound before touching the cache. Verify: repository integrity is established
2. Locate the cache directory borg uses for this repository from its environment or default path. Verify: the exact cache location is known
3. Remove or move aside the damaged cache directory so borg rebuilds it on the next run. Verify: the damaged cache is out of the way
4. Run a small create or extract and confirm borg reconstructs the cache and completes the operation. Verify: operations resume with a fresh cache

## Variant phrasings
### borg cache integrity data not available cache is damaged
The verbatim phrasing.
### borg create failed damaged cache rebuild fix
The rebuild phrasing.
### borg cache damaged delete cache repository check
The delete phrasing.

Compatibility: Borg backup repositories and local cache integrity

## Why it happens
The cache holds the chunk index borg uses to deduplicate quickly, and its integrity data lets borg detect when the cache no longer matches the repository. Damage from crashes or interrupted writes trips that detection, and borg stops rather than risk deduplicating against a false index.

## Edge cases / pitfalls
- A shared cache directory across machines guarantees this error; each borg client host keeps its own cache.
- Cache rebuilds on huge repositories take real time; schedule the first post-repair run inside a generous window.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JtULU9-nVdYSc8bfeP6XVQ