---
metadata:
  - name: generator
    content: Diplodoc Platform v5.62.0
alternate:
  - https://ydb.tech/docs/en/concepts/backup.md?version=main
  - https://ydb.tech/docs/ru/concepts/backup.md?version=main
  - href: https://ydb.tech/docs/en/concepts/backup.md?version=main
    type: text/markdown
    title: Markdown version
  - href: https://ydb.tech/docs/en/llms.txt?revision=5f9509b7856960211eefd47b7217d87c71bdf904&version=main
    rel: describedby
sourcePath: en/core/concepts/backup.md
---
> **Documentation Index:** Fetch the complete configuration index at https://ydb.tech/docs/en/llms.txt?revision=5f9509b7856960211eefd47b7217d87c71bdf904&version=main

# Backup concepts

YDB ensures data safety during hardware failures through [replication and fault tolerance](https://ydb.tech/docs/en/concepts/topology.md?version=main#cluster-config). However, replication does not protect against **logical errors**: an accidental `DROP TABLE`, an erroneous mass `UPDATE`, or `DELETE` will be replicated to all replicas. To protect against such scenarios, **backup** is required — a separate copy of data that can be restored from.

## Full backup {#full-backup}

A full backup is a snapshot of table data at a specific point in time. YDB provides several ways to create full backups, from simple to more functional.

### Copying tables within a cluster {#copy-table}

The simplest way is to create a copy of a table (or several tables) within the same cluster using the [`ydb tools copy`](https://ydb.tech/docs/en/reference/ydb-cli/tools-copy.md?version=main) command. The copy is created atomically from a consistent snapshot and uses a copy-on-write mechanism, so the operation is fast.

Suitable for:

- Quickly creating a safety copy before a dangerous operation.
- Cloning data for testing.

{% note warning %}

The copy is stored in the same cluster as the original data. It protects against logical errors but not against cluster loss.

{% endnote %}

### Dump to file system {#dump}

The [`ydb tools dump`](https://ydb.tech/docs/en/reference/ydb-cli/export-import/tools-dump.md?version=main) and [`ydb tools restore`](https://ydb.tech/docs/en/reference/ydb-cli/export-import/tools-restore.md?version=main) commands allow you to dump data to a local file system and restore it back.

Suitable for:

- Local development and testing.
- Small databases.
- Creating a copy on a separate medium.

### Export to S3-compatible storage {#s3}

The [`ydb export s3`](https://ydb.tech/docs/en/reference/ydb-cli/export-import/export-s3.md?version=main) and [`ydb import s3`](https://ydb.tech/docs/en/reference/ydb-cli/export-import/import-s3.md?version=main) commands allow you to export and import data to an external S3-compatible storage.

Suitable for:

- Disaster recovery (data is stored outside the cluster).
- Data migration between clusters.
- Long-term archiving.

### Export to NFS {#nfs}

The [`ydb export nfs`](https://ydb.tech/docs/en/reference/ydb-cli/export-import/export-nfs.md?version=main) and [`ydb import nfs`](https://ydb.tech/docs/en/reference/ydb-cli/export-import/import-nfs.md?version=main) commands allow you to export and import data to a network file system (NFS) mounted on all hosts of the YDB cluster. Unlike [dump to file system](#dump), the export is performed on the server side and does not require data transfer via CLI.

Suitable for:

- Disaster recovery (data is stored outside the cluster).
- Data migration between clusters.
- Long-term archiving.

For more details on configuring NFS for backup and recovery, see the recipe [Backup and recovery via NFS](https://ydb.tech/docs/en/recipes/backup/nfs-backup/nfs-backup.md?version=main).

## Incremental backup {#incremental-backup}

When working with large tables, repeatedly creating full backups can be too costly. Incremental backup solves this problem: after an initial full copy, each subsequent increment captures only the changes (inserts, updates, deletes) that occurred since the previous backup.

Incremental backups are organized into a **chain**:


```text
Full backup → Increment₁ → Increment₂ → ... → Incrementₙ
```


To restore, the entire chain is needed: first the full copy is applied, then all increments sequentially. Restoration is performed to the state at the time of the last increment in the chain.

Incremental backup is implemented using [backup collections](https://ydb.tech/docs/en/concepts/datamodel/backup-collection.md?version=main).

{% note info %}

Currently, only [row tables](https://ydb.tech/docs/en/concepts/datamodel/table.md?version=main#row-oriented-tables) are supported.

{% endnote %}

## Backup of system tablets {#system-tablet-backup}

{% note info %}

Currently, only backup of cluster system tablets is supported. Backup of database system tablets is not supported.

{% endnote %}

The system tablet backup mechanism provides incremental copying of cluster metadata — such as [Hive](https://ydb.tech/docs/en/concepts/glossary.md?version=main#hive), [BSController](https://ydb.tech/docs/en/concepts/glossary.md?version=main#ds-controller), and [SchemeShard](https://ydb.tech/docs/en/concepts/glossary.md?version=main#scheme-shard) — to the local file system of cluster hosts.

This mechanism is used to restore cluster metadata when [restoring from database backups](#full-backup) is technically possible but not suitable in terms of time or effort. A typical scenario is when the total volume of databases in the cluster is large due to their number, the size of individual databases, or a combination of both; a full `import/restore` of all data into a new cluster in such a case leads to prolonged downtime. In this scenario, you can restore system tablets and bring the cluster back to a working state without performing a bulk restore of user data on the new cluster.

If the volume of databases allows for a standard restore, use [export/import](#s3) or [dump/restore](#dump) first. System tablet backup should be used as a special mechanism for situations where you need to restore cluster metadata and reduce the volume of restore operations.

{% note info %}

For practical instructions on enabling and restoring, see [recipes for system tablet backup](https://ydb.tech/docs/en/recipes/backup/system-tablet-backup/index.md?version=main).

{% endnote %}

{% note warning %}

Backups of different system tablets are created independently of each other and are not consistent with each other. After restoration, the state of tablets may be inconsistent, which may negatively affect cluster operation.

{% endnote %}

### How it works {#system-tablet-backup-how-it-works}

Backup consists of two components:

- **State snapshot** — at each start, the tablet scans all its tables and writes its full state to a backup, including the data schema. The scan is based on a state snapshot and does not block tablet operation.
- **Change log** — with each change to data or schema, the tablet asynchronously writes the change to the log in parallel with writing to the distributed storage. When the log size exceeds the snapshot size, the tablet automatically creates a new snapshot.

{% note warning %}

Due to asynchronous writing, the latest changes that did not make it into the backup before the failure may be lost.

{% endnote %}

Backups are created **locally on the host where the tablet is currently running**. Therefore, the most recent copy is on the host where the tablet was running just before the failure.

The number of stored backups on a host is limited in the [configuration](https://ydb.tech/docs/en/reference/configuration/system_tablet_backup_config.md?version=main). After a successful snapshot, the oldest copy is automatically deleted when the limit is exceeded. Incomplete copies (without a fully written snapshot) are deleted when a new backup is created.

## Comparison of approaches {#comparison}

| **Method** | **Storage location** | **Incremental** | **Use cases** |
| --- | --- | --- | --- |
| [Copying tables within a cluster](#copy-table) | Within the cluster | No | Quick copy before a dangerous operation |
| [Dump to file system](#dump) | File system | No | Development, testing, small databases |
| [Export to S3-compatible storage](#s3) | S3-compatible storage | No | Disaster recovery, migration, archiving |
| [Export to NFS](#nfs) | Network File System (NFS) | No | Disaster recovery, migration, archiving |
| [Incremental backup](#incremental-backup) | Within the cluster ( [exported](datamodel/backup-collection.md#external-storage) to S3 or file system) | Yes | Regular backups of large production databases |
| [System tablet backup](#system-tablet-backup) | Local file system of cluster hosts | Yes | Restoring cluster metadata in emergency situations |

## See also

- [Backup and restore](https://ydb.tech/docs/en/devops/backup-and-recovery/index.md?version=main) — practical guide
- [Backup collections](https://ydb.tech/docs/en/concepts/datamodel/backup-collection.md?version=main) — architecture and limitations
- [Recipes for system tablet backup](https://ydb.tech/docs/en/recipes/backup/system-tablet-backup/index.md?version=main) — enabling and restoring
- [Backup and restore](https://ydb.tech/docs/en/devops/backup-and-recovery/index.md?version=main) — practical guide
- [Export/import reference](https://ydb.tech/docs/en/reference/ydb-cli/export-import/index.md?version=main) — CLI commands
- YQL reference:

  - [`CREATE BACKUP COLLECTION`](https://ydb.tech/docs/en/yql/reference/syntax/create-backup-collection.md?version=main)
  - [`BACKUP`](https://ydb.tech/docs/en/yql/reference/syntax/backup.md?version=main)
  - [`RESTORE`](https://ydb.tech/docs/en/yql/reference/syntax/restore-backup-collection.md?version=main)
  - [`DROP BACKUP COLLECTION`](https://ydb.tech/docs/en/yql/reference/syntax/drop-backup-collection.md?version=main)