## TL;DR
Detonation VMs live on snapshots: a clean base, restored per sample. Restore failures come from a corrupted snapshot, a broken differencing chain, storage pressure, or a base image changed mid-chain. Stop intake, check the hypervisor errors and disk space, rebuild the snapshot from the base image if needed, and drain the queue in controlled batches so a day of samples does not stampede the repaired system.

```text
the detonation agent's VM snapshot restore failed and its sample queue backed up
```

## Use this when
- Sandbox workers report restore failures and the sample queue grows.
- New samples receive no detonation start events.

## Not for this skill when
- The queue grows because submission volume spiked. That is capacity, not restore failure.
- The sandbox is vendor-hosted. Open a vendor case with the queue evidence instead of repairing VMs.

## Steps
1. Pause new submissions or divert them to an alternate verdict path so the backlog stops growing. Verify: intake is paused and the queue count is frozen in the log.
2. Read hypervisor and sandbox logs for the restore error and check host storage and snapshot chain integrity. Verify: the restore failure cause is identified.
3. Repair the image: discard a corrupt snapshot, rebuild from the base, and snapshot a verified clean state. Verify: a manual restore and boot succeed.
4. Detonate one known test sample end to end before reopening intake. Verify: a full clean verdict cycle completes.
5. Drain the backlog in batches ordered by campaign relevance, monitoring restore health as load rises. Verify: the queue returns to normal depth without new restore failures.

## Variant phrasings
### sandbox vm snapshot restore failed detonation queue
The snapshot failure variant.
### detonation backlog drain after vm repair
The backlog variant.

Compatibility: Self-hosted detonation platforms on common hypervisors, sandbox worker management.

## Why it happens
Snapshot chains are fragile state: every sample depends on the whole chain being exactly right, and a single corrupt link fails every restore while looking like random flakiness until someone reads the hypervisor log.

## Edge cases / pitfalls
- Keep the base image build scripted so a rebuild is an hour, not an archaeology project.
- Monitor snapshot age; very old clean states miss the software versions attackers target.
- Test restores on a schedule. Discovering restore failure during an incident is the worst timing.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Pg1Fgs5N1XvBfmu4kG0AVg