Backup runs and incremental copies
Understand what starts a backup run, what run outcomes and per-volume results mean, when backups are full or incremental, and how recovery points expire.
A run is one execution of a backup plan. It backs up each volume that's assigned to the plan when the run starts, separately, and it records a result for each volume. Every successful backup becomes a recovery point.
What starts a run
| Trigger | What starts it |
|---|---|
SCHEDULED | The plan's schedule. |
MANUAL | Run now on the plan's page or in Backup Center. |
RETRY | A retry of the failed volumes of an earlier run. See Retry failed volumes. |
The plan's Runs tab shows each run's trigger, outcome, volume counts, and start and finish times.
A plan has at most one run in progress. While a run is in progress, another manual run or a retry is refused, and a scheduled run starts only after the current run finishes. A manual run doesn't move the schedule: for example, if you run a daily plan scheduled for 02:00 UTC at 14:00 UTC, it runs again at 02:00 UTC the next day.
Run outcomes
| Outcome | What it means |
|---|---|
| Queued, Running | The run is in progress. |
| Succeeded | Every volume in the run was backed up. |
| Partial | Some volumes were backed up, and the others failed or were skipped. |
| Failed | No volume was backed up. |
| Skipped | The plan had no volumes when the run started. |
For example, a run over five volumes where two volumes were in an error state ends as Partial, with three volumes backed up and two skipped. Backup Center counts a plan as failing when its last run is Failed or Partial.
Per-volume results
To see what happened to each volume, open the plan's Runs tab, and select Per-volume results on the run's row.
| Status | What it means |
|---|---|
| Queued | The volume's backup hasn't started. |
| Running | The platform is starting the volume's backup. |
| Waiting for provider | The backup service accepted the backup and is copying the volume's data. |
| Succeeded | The backup completed, and a recovery point was created. |
| Failed | The volume was sent to the backup service, and the service refused the backup or didn't complete it. |
| Skipped | The volume wasn't backed up because it no longer exists, it's in an error state, or the cloud hasn't created it yet. |
Each row also shows whether the backup was full or incremental, the number of attempts, the stored size of the recovery point, and the error, if any. An error that a retry can't fix, such as a volume that no longer exists, is marked (not retryable).
Retry failed volumes
On the plan's Runs tab, select Per-volume results on the run's row.
Select Retry NaN failed volumes.
The retry starts a new run with the trigger RETRY. It backs up only the failed and skipped volumes that can be retried, so the volumes that succeeded aren't backed up a second time. The original run and its results stay as they were. The action appears when the run has finished and at least one of its volumes can be retried.
Full and incremental backups
Take runs after a full base as deltas instead of full copies. A full backup and the incremental backups that follow it form a chain, in which every incremental backup depends on the one before it.
When Incremental backups is on, a run takes a full backup of a volume in these cases, and an incremental backup otherwise:
| A full backup is taken when | Why |
|---|---|
| The plan has no recovery point of the volume yet. | An incremental backup needs a backup to build on. |
| The volume's chain already has 7 recovery points. | Every point of a chain is kept until the whole chain can go, so chains stay short. |
| The chain's full backup is older than 7 days, or older than the retention window if that's shorter. | A chain shouldn't outlive the retention window. |
When Incremental backups is off, every backup is a full backup.
For example, a daily plan with a 30-day retention window takes a full backup of each volume every seven days, with six incremental backups in between.
For billing, every recovery point counts at the full size of its volume, whether it's a full or an incremental backup. See Billing.
Backups of attached volumes
A volume that's attached to an instance is backed up while it's in use. Its recovery point is marked crash-consistent: The volume was attached and running when this point was captured, so the image is crash-consistent rather than quiesced. A restored filesystem may replay its journal on first mount.
For example, the recovery point of a database volume that was in use captures the data as if the instance had stopped suddenly at that moment. A volume that's detached when its backup starts gives a recovery point without the mark.
Recovery points and retention
A recovery point expires when the plan's retention window has passed since it was captured. For example, with a 7-day window, a recovery point captured on March 1 at 02:00 UTC expires on March 8 at 02:00 UTC. The platform then deletes it automatically. This also happens for paused plans and for plans that you deleted.
| Status | What it means |
|---|---|
| Available | The recovery point can be restored. |
| Expiring | The recovery point expires within two days. |
| Retained | Past its retention window, but kept because a newer incremental backup depends on it. It is fully restorable and is released once its dependents expire. |
When you change a plan's retention window, the new window applies to the recovery points that the plan already holds, and the points that are past it are deleted. See Change a plan's schedule or retention.