## TL;DR
A server busy response that retries forever points at the server side or the schedule, not the device: check Druva's service status and the organisation's backup window congestion, then look at the device's own pattern, a backup that never finishes keeps re-entering the busy state because it restarts instead of resuming. Stagger the affected devices' schedules, confirm the client resumes progress between attempts, and escalate with the job's identifiers if the busy state persists across a full day.

```text
Druva backup failed "server is busy, backup will be retried" loop never completes
```

## Use this when
- The job or restore fails with this symptom: Druva backup failed with server is busy, backup will be retried, looping without completing.
- You are working on a Druva backup stuck in a server busy retry loop 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 single device whose backup is so large it never completes inside its window, where the fix is seeding or windowing rather than server health.
- The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Check the Druva service status and any maintenance notices covering the loop's timeframe. Verify: server-side health is established
2. Read the device's backup history: how far each attempt gets and whether progress accumulates or restarts. Verify: resume behaviour is known
3. Move the device to a less congested window and reduce concurrent devices in its group if the pattern is fleet-wide. Verify: the schedule change is applied
4. Watch one full cycle: the backup should progress past previous attempts and complete, or the case goes to support with logs attached. Verify: completion or a support-ready evidence pack results

## Variant phrasings
### druva backup server is busy will be retried loop
The verbatim phrasing.
### druva backup never completes busy retry staggered schedule
The schedule phrasing.
### druva server busy loop progress restarts fix support
The progress phrasing.

Compatibility: Druva inSync or Phoenix backups with server-side throttling responses

## Why it happens
Retry loops hide two different diseases with one message: a server that keeps deferring, and a client that restarts from zero so deferral never ends. Progress behaviour across attempts separates them, and only the second is fixable from the device side.

## Edge cases / pitfalls
- First backups of large devices often need a seeding approach; a week of busy retries is the signal, not patience.
- Fleet-wide loops after a policy push usually mean the push concentrated the windows; review the schedule change history.

## Provenance

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