# backup-increment-disconnected

An increment **does not follow on the part before it**.

- **Route:** `restore-backup`
- **Description:** `backup increment is disconnected: it follows on another event than the one the part before it ended at`
- **Details:** **`part`**, the place of the increment in the backup, counting from 0, with the full backup as part 0.

## Why It Happens

A **[restore](/docs/eventsourcingdb/backup-and-restore)** takes a full backup followed by its increments, one after the other in one request body. Each increment begins with a `backup` item, whose **`lastBackedUpEvent`** names the event it follows on. That has to be the event **the part before it ended at**: its last event, or, for a part without events, the event that part followed on. EventSourcingDB compares the two by ID and hash, and refuses an increment that follows on another event, since events would be **missing or doubled** between the two parts.

Typical causes are an increment that is **missing** in between, increments **in the wrong order**, the same increment **twice**, and a second full backup after one that holds events.

## How to Fix It

Send every increment exactly once, in the order in which they were created, each right after the part it follows on. EventSourcingDB has removed what it restored so far, so the database is empty again. Resending the request unchanged fails the same way.

## Example

For a restore whose third part, part `2`, is the same increment as the part before it, EventSourcingDB answers with this error, as a line of the stream, and then ends the stream with its `end` item:

```json
{
  "type": "error",
  "data": {
    "code": "https://docs.eventsourcingdb.io/errors/backup-increment-disconnected",
    "description": "backup increment is disconnected: it follows on another event than the one the part before it ended at",
    "details": {
      "part": 2
    }
  }
}
```