# store-not-empty

A restore needs an **empty database**, and an import one **without events**, but this one holds what it does not take.

- **Routes:** `restore-backup` and `import-events`
- **Descriptions:** `store is not empty: a backup can only be restored into an empty store`, for a restore, when the database holds events or schemas; `store is not empty: events can only be imported into a store without events`, for an import, when the database holds events
- **Details:** None; `details` is an empty object.

## Why It Happens

A **[restore](/docs/eventsourcingdb/backup-and-restore)** rebuilds a database from a backup, and the events of a backup keep their IDs and hashes, so it only goes into a database that holds **no events and no schemas**. EventSourcingDB checks this before it reads the first line of the backup, and **leaves the database as it is**.

A typical cause is to restore a full backup and its increments in **separate requests**: once the full backup is restored, the database is no longer empty, and the increments are refused. A restore takes the full backup and **all of its increments in one request**, one after the other in its body. Another cause is a schema that was registered in the new database before the restore.

An **[import](/docs/eventsourcingdb/api/import-events)** brings events from another system, which keep their IDs from `0` on, so it only goes into a database that holds **no events**. Schemas are welcome: an import brings none, so the schemas of its event types are registered before it, and its events are checked against them. EventSourcingDB checks this before it reads the first line of the events, also for a request with an empty body, and **leaves the database as it is**.

A typical cause is to import the events in **several requests**: once the first one has imported its events, the database is no longer without events, and the next one is refused. An import takes **all of its events in one request**.

## How to Fix It

For a restore, restore into a database that was started on an empty data directory, and send the full backup together with all of its increments. For an import, import into a database that holds no events, with the schemas you want registered beforehand, and send all of the events in one request. Resending the request to this database fails the same way, as long as it holds what the request does not take.

## Example

For a restore into a database that holds events, 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/store-not-empty",
    "description": "store is not empty: a backup can only be restored into an empty store",
    "details": {}
  }
}
```

For an import into a database that holds events, the description reads:

```json
{
  "type": "error",
  "data": {
    "code": "https://docs.eventsourcingdb.io/errors/store-not-empty",
    "description": "store is not empty: events can only be imported into a store without events",
    "details": {}
  }
}
```