docs-v2/content/enterprise_influxdb/v1/administration/backup-and-restore.md

---
title: Back up and restore
description: >
  Back up and restore InfluxDB enterprise clusters to prevent data loss.
aliases:
    - /enterprise/v1.10/guides/backup-and-restore/
menu:
  enterprise_influxdb_v1:
    name: Back up and restore
    weight: 10
    parent: Administration
---

Use the InfluxDB Enterprise `backup`, `restore`, `export` and `import` utilities
to prevent unexpected data loss and preserve the ability to restore data if it
ever is lost.

You can use these tools in your back up and restore procedures to:

- Provide disaster recovery due to unexpected events
- Migrate data to new environments or servers
- Restore clusters to a consistent state
- Export and import data for debugging

Depending on the volume of data to be protected and your application requirements, InfluxDB Enterprise offers two methods, described below, for managing backups and restoring data:

- [Backup and restore utilities](#backup-and-restore-utilities): Use for most applications
- [Exporting and importing data](#exporting-and-importing-data): Use for very large datasets and to debug data

> [!Note]
> #### Back up and restore between InfluxDB Enterprise and OSS 
>
> Use the `backup` and `restore` utilities in
> [InfluxDB Enterprise](#backup-and-restore-utilities) and
> [InfluxDB OSS (version 1.5 and later)](/influxdb/v1/administration/backup-and-restore/) to:
>
> - Restore InfluxDB Enterprise backup files to InfluxDB OSS instances.
> - Back up InfluxDB OSS data that can be restored in InfluxDB Enterprise clusters.

## Backup and restore utilities

Use InfluxDB Enterprise back up and restore utilities to:

- Back up and restore multiple databases at a time.
- Back up specific time ranges.
- Create backup files compatible with InfluxDB OSS.

InfluxDB Enterprise supports backing up and restoring data in a cluster, 
a single database and retention policy, and single shards.
Most InfluxDB Enterprise applications can use the backup and restore utilities.

Use the `backup` and `restore` utilities to back up and restore between `influxd`
instances with the same versions or with only minor version differences.
For example, you can backup from {{< latest-patch version="1.10" >}} and restore on {{< latest-patch >}}.

- [Backup utility](#backup-utility)
  - [Examples](#examples)
- [Restore utility](#restore-utility)
- [Exporting and importing data](#exporting-and-importing-data)
  - [Exporting data](#exporting-data)
  - [Importing data](#importing-data)
  - [Example](#example)

### Backup utility

A backup creates a copy of the [metastore](/enterprise_influxdb/v1/concepts/glossary/#metastore) and [shard](/enterprise_influxdb/v1/concepts/glossary/#shard) data at that point in time and stores the copy in the specified directory.

To back up **only the cluster metastore**, use the `-strategy only-meta` backup option.
For more information, see how to [perform a metastore only backup](#perform-a-metastore-only-backup).

All backups include a manifest, a JSON file describing what was collected during the backup.
The filenames reflect the UTC timestamp of when the backup was created, for example:

- Metastore backup: `20060102T150405Z.meta` (includes usernames and passwords)
- Shard data backup: `20060102T150405Z.<shard_id>.tar.gz`
- Manifest: `20060102T150405Z.manifest`

Backups can be full, metastore only, or incremental, and they are incremental by default:

- **Full backup**: Creates a copy of the metastore and shard data.
- **Incremental backup**: Creates a copy of the metastore and shard data that have changed since the last backup (the most recent backup file in the specified directory).
  If no backups exist in the directory, then the system automatically performs a full backup.
- **Metastore only backup**: Creates a copy of the metastore data only.

Restoring different types of backups requires different syntax.
To prevent issues with [restore](#restore-utility), keep full backups, metastore only backups, and incremental backups in separate directories.

> [!Note]
> #### Backup and restore performance
> 
> The backup utility copies all data through the meta node that is used to execute the backup.
> As a result, backup and restore performance is typically limited by the network IO of the meta node.
> Increasing the resources available to this meta node (such as resizing the EC2 instance) can significantly improve backup and restore performance.

#### Syntax

```bash
influxd-ctl [global-options] backup [backup-options] <path-to-backup-directory>
```

If successful, the `influxd-ctl backup` command exits with `0` status;
otherwise, error (`1`) status and a message that you can use for troubleshooting.

##### Global flags

See the [`influxd-ctl` documentation](/enterprise_influxdb/v1/tools/influxd-ctl/#influxd-ctl-global-flags)
for a complete list of the global `influxd-ctl` flags.

##### Backup flags

- `-db <string>`: name of the single database to back up
- `-from <TCP-address>`: the data node TCP address to prefer when backing up
- `-strategy`: select the backup strategy to apply during backup
    - `incremental`: _**(Default)**_ backup data that is new or changed since the previous backup.
    - `full` perform a full backup. Same as `-full`
    - `only-meta` perform a backup for meta data only: users, roles,
      databases, continuous queries, retention policies. Shards are not exported.
- `-full`: perform a full backup. Deprecated in favour of `-strategy=full`
- `-rp <string>`: the name of the single retention policy to back up (must specify `-db` with `-rp`)
- `-shard <string>`: shard ID to back up (if `-rp` or `-db` flags are provided,
  the specified database or retention policy must match those in the shard)
- `-start <timestamp>`: Include all points starting with specified timestamp (RFC3339 format). Not compatible with `-since` or `-strategy full`.
- `-end <timestamp>`: Exclude all points after timestamp (RFC3339 format). Not compatible with `-since` or `-strategy full`.

### Examples

#### Back up a database and all retention policies

The following example stores incremental backups of the database
and all retention policies in the `./myfirstdb-allrp-backup` directory:

```bash
influxd-ctl backup -db myfirstdb ./myfirstdb-allrp-backup
```

#### Back up a database with a specific retention policy

The following example stores incremental backups in separate directories for the
specified database and retention policy combinations.

```bash
influxd-ctl backup -db myfirstdb -rp oneday ./myfirstdb-oneday-backup

influxd-ctl backup -db myfirstdb -rp autogen ./myfirstdb-autogen-backup
```

The output contains the status and backup file paths--for example:

```sh
backing up db=myfirstdb rp=oneday shard=8 to <USER_HOME>/myfirstdb-oneday-backup/myfirstdb.oneday.00008.00
backing up db=myfirstdb rp=autogen shard=10 to <USER_HOME>/myfirstdb-autogen-backup/myfirstdb.autogen.00010.00
```

#### Back up data from a specific time range

To back up data in a specific time range, use the `-start` and `-end` options:

```bash
influxd-ctl backup -db myfirstdb ./myfirstdb-jandata -start 2022-01-01T012:00:00Z -end 2022-01-31T011:59:00Z
```

#### Perform an incremental backup

The incremental backup strategy (default, `-strategy=incremental`) checks for existing backup files in the specified directory. 

- If a backup exists, `influxd-ctl` performs an incremental backup, saving only the data that has changed since the most recent backup file.
- If no backup exists, it creates a full backup of all data in InfluxDB.

The following example shows how to run an incremental backup stored in the current directory:

```bash
# Syntax
influxd-ctl backup .

# Example
$ influxd-ctl backup .
Backing up meta data... Done. 421 bytes transferred
Backing up node 7ba671c7644b:8088, db telegraf, rp autogen, shard 4... Done. Backed up in 903.539567ms, 307712 bytes transferred
Backing up node bf5a5f73bad8:8088, db _internal, rp monitor, shard 1... Done. Backed up in 138.694402ms, 53760 bytes transferred
Backing up node 9bf0fa0c302a:8088, db _internal, rp monitor, shard 2... Done. Backed up in 101.791148ms, 40448 bytes transferred
Backing up node 7ba671c7644b:8088, db _internal, rp monitor, shard 3... Done. Backed up in 144.477159ms, 39424 bytes transferred
Backed up to . in 1.293710883s, transferred 441765 bytes
$ ls
20160803T222310Z.manifest  20160803T222310Z.s1.tar.gz  20160803T222310Z.s3.tar.gz
20160803T222310Z.meta      20160803T222310Z.s2.tar.gz  20160803T222310Z.s4.tar.gz
```

#### Perform a full backup

The following example shows how to run a full backup stored in a specific directory.
The directory must already exist.

```bash
# Syntax
influxd-ctl backup -full <path-to-backup-directory>

# Example
$ influxd-ctl backup -full backup_dir
Backing up meta data... Done. 481 bytes transferred
Backing up node <hostname>:8088, db _internal, rp monitor, shard 1... Done. Backed up in 33.207375ms, 238080 bytes transferred
Backing up node <hostname>:8088, db telegraf, rp autogen, shard 2... Done. Backed up in 15.184391ms, 95232 bytes transferred
Backed up to backup_dir in 51.388233ms, transferred 333793 bytes
$ ls backup_dir
20170130T184058Z.manifest
20170130T184058Z.meta
20170130T184058Z.s1.tar.gz
20170130T184058Z.s2.tar.gz
```

#### Perform an incremental backup on a single database

Use the `-bind` option to specify a remote [meta node](/enterprise_influxdb/v1/concepts/glossary/#meta-node) to connect to.

The following example shows how to connect to a remote meta server and back up
a specific database into a given directory in the local system.
The directory must already exist.

```bash
# Syntax
influxd-ctl -bind <metahost>:8091 backup -db <db-name> <path-to-backup-directory>

# Example
$ influxd-ctl -bind 2a1b7a338184:8091 backup -db telegraf ./telegrafbackup
Backing up meta data... Done. 318 bytes transferred
Backing up node 7ba671c7644b:8088, db telegraf, rp autogen, shard 4... Done. Backed up in 997.168449ms, 399872 bytes transferred
Backed up to ./telegrafbackup in 1.002358077s, transferred 400190 bytes
$ ls ./telegrafbackup
20160803T222811Z.manifest  20160803T222811Z.meta  20160803T222811Z.s4.tar.gz
```

#### Perform a metadata only backup

The following example shows how to create and store a metadata-only backup
in a specific directory.
The directory must already exist.

```bash
# Syntax
influxd-ctl backup -strategy only-meta <path-to-backup-directory>

# Example
$ influxd-ctl backup -strategy only-meta backup_dir
Backing up meta data... Done. 481 bytes transferred
Backed up to backup_dir in 51.388233ms, transferred 481 bytes
~# ls backup_dir
20170130T184058Z.manifest
20170130T184058Z.meta
```

### Restore utility

> [!Note]
> #### Disable anti-entropy (AE) before restoring a backup
>
> Before restoring a backup, stop the anti-entropy (AE) service (if enabled) on **each data node in the cluster, one at a time**.
>
> 1. Stop the `influxd` service.
> 2. Set `[anti-entropy].enabled` to `false` in the influx configuration file (by default, influx.conf).
> 3. Restart the `influxd` service and wait for the data node to receive read and write requests and for the [hinted handoff queue](/enterprise_influxdb/v1/concepts/clustering/#hinted-handoff) to drain.
> 4. Once AE is disabled on all data nodes and each node returns to a healthy state, you're ready to restore the backup. For details on how to restore your backup, see examples below.
> 5. After restoring the backup, restart AE services on each data node.

##### Restore a backup

Restore a backup to an existing cluster or a new cluster.
By default, a restore writes to databases using the backed-up data's [replication factor](/enterprise_influxdb/v1/concepts/glossary/#replication-factor).
An alternate replication factor can be specified with the `-newrf` flag when restoring a single database.
Restore supports both `-full` backups and incremental backups; the syntax for
a restore differs depending on the backup type.

##### Restores from an existing cluster to a new cluster

Restores from an existing cluster to a new cluster restore the existing cluster's
[users](/enterprise_influxdb/v1/concepts/glossary/#user), roles,
[databases](/enterprise_influxdb/v1/concepts/glossary/#database), and
[continuous queries](/enterprise_influxdb/v1/concepts/glossary/#continuous-query-cq) to
the new cluster.

They do not restore Kapacitor [subscriptions](/enterprise_influxdb/v1/concepts/glossary/#subscription).
In addition, restores to a new cluster drop any data in the new cluster's
`_internal` database and begin writing to that database anew.
The restore does not write the existing cluster's `_internal` database to
the new cluster.

#### Syntax to restore from incremental and metadata backups

Use the syntax below to restore an incremental or metadata backup to a new cluster or an existing cluster.
**The existing cluster must contain no data in the affected databases.**
Performing a restore from an incremental backup requires the path to the incremental backup's directory.

```bash
influxd-ctl [global-options] restore [restore-options] <path-to-backup-directory>
```

{{% note %}}
The existing cluster can have data in the `_internal` database (the database InfluxDB creates if
[internal monitoring](/platform/monitoring/influxdata-platform/tools/measurements-internal) is enabled).
The system automatically drops the `_internal` database when it performs a complete restore.
{{% /note %}}

##### Global flags

See the [`influxd-ctl` documentation](/enterprise_influxdb/v1/tools/influxd-ctl/#influxd-ctl-global-flags)
for a complete list of the global `influxd-ctl` flags.

##### Restore flags

See the [`influxd-ctl` documentation](/enterprise_influxdb/v1/tools/influxd-ctl/restore/)
for a complete list of `influxd-ctl restore` flags.

- `-db <string>`: the name of the single database to restore
- `-list`: shows the contents of the backup
- `-newdb <string>`: the name of the new database to restore to (must specify with `-db`)
- `-newrf <int>`: the new replication factor to restore to (this is capped to the number of data nodes in the cluster)
- `-newrp <string>`: the name of the new retention policy to restore to (must specify with `-rp`)
- `-rp <string>`: the name of the single retention policy to restore
- `-shard <unit>`: the shard ID to restore

#### Syntax to restore from a full or manifest only backup

Use the syntax below to restore a full or manifest only backup to a new cluster or an existing cluster.
Note that the existing cluster must contain no data in the affected databases.*
Performing a restore requires the `-full` flag and the path to the backup's manifest file.

```bash
influxd-ctl [global-options] restore [options] -full <path-to-manifest-file>
```

\* The existing cluster can have data in the `_internal` database, the database
that the system creates by default.
The system automatically drops the `_internal` database when it performs a
complete restore.

##### Global flags

See the [`influxd-ctl` documentation](/enterprise_influxdb/v1/tools/influxd-ctl/#influxd-ctl-global-flags)
for a complete list of the global `influxd-ctl` flags.

##### Restore flags

See the [`influxd-ctl` documentation](/enterprise_influxdb/v1/tools/influxd-ctl/restore/)
for a complete list of `influxd-ctl restore` flags.

- `-db <string>`: the name of the single database to restore
- `-list`: shows the contents of the backup
- `-newdb <string>`: the name of the new database to restore to (must specify with `-db`)
- `-newrf <int>`: the new replication factor to restore to (this is capped to the number of data nodes in the cluster)
- `-newrp <string>`: the name of the new retention policy to restore to (must specify with `-rp`)
- `-rp <string>`: the name of the single retention policy to restore
- `-shard <unit>`: the shard ID to restore

#### Examples

##### Restore from an incremental backup

```bash
# Syntax
influxd-ctl restore <path-to-backup-directory>

# Example
$ influxd-ctl restore my-incremental-backup/
Using backup directory: my-incremental-backup/
Using meta backup: 20170130T231333Z.meta
Restoring meta data... Done. Restored in 21.373019ms, 1 shards mapped
Restoring db telegraf, rp autogen, shard 2 to shard 2...
Copying data to <hostname>:8088... Copying data to <hostname>:8088... Done. Restored shard 2 into shard 2 in 61.046571ms, 588800 bytes transferred
Restored from my-incremental-backup/ in 83.892591ms, transferred 588800 bytes
```

##### Restore from a metadata backup

In this example, the `restore` command restores a [metadata backup](#perform-a-metadata-only-backup)
stored in the `metadata-backup/` directory.

```bash
# Syntax
influxd-ctl restore <path-to-backup-directory>

# Example
$ influxd-ctl restore metadata-backup/
Using backup directory: metadata-backup/
Using meta backup: 20200101T000000Z.meta
Restoring meta data... Done. Restored in 21.373019ms, 1 shards mapped
Restored from my-incremental-backup/ in 19.2311ms, transferred 588 bytes
```

##### Restore from a `-full` backup

```bash
# Syntax
influxd-ctl restore -full <path-to-manifest-file>

# Example
$ influxd-ctl restore -full my-full-backup/20170131T020341Z.manifest
Using manifest: my-full-backup/20170131T020341Z.manifest
Restoring meta data... Done. Restored in 9.585639ms, 1 shards mapped
Restoring db telegraf, rp autogen, shard 2 to shard 2...
Copying data to <hostname>:8088... Copying data to <hostname>:8088... Done. Restored shard 2 into shard 2 in 48.095082ms, 569344 bytes transferred
Restored from my-full-backup in 58.58301ms, transferred 569344 bytes
```

##### Restore from an incremental backup for a single database and give the database a new name

```bash
# Syntax
influxd-ctl restore -db <src> -newdb <dest> <path-to-backup-directory>

# Example
$ influxd-ctl restore -db telegraf -newdb restored_telegraf my-incremental-backup/
Using backup directory: my-incremental-backup/
Using meta backup: 20170130T231333Z.meta
Restoring meta data... Done. Restored in 8.119655ms, 1 shards mapped
Restoring db telegraf, rp autogen, shard 2 to shard 4...
Copying data to <hostname>:8088... Copying data to <hostname>:8088... Done. Restored shard 2 into shard 4 in 57.89687ms, 588800 bytes transferred
Restored from my-incremental-backup/ in 66.715524ms, transferred 588800 bytes
```

##### Restore from an incremental backup for a database and merge that database into an existing database

Your `telegraf` database was mistakenly dropped, but you have a recent backup so you've only lost a small amount of data.

If Telegraf is still running, it will recreate the `telegraf` database shortly after the database is dropped.
You might try to directly restore your `telegraf` backup just to find that you can't restore:

```bash
$ influxd-ctl restore -db telegraf my-incremental-backup/
Using backup directory: my-incremental-backup/
Using meta backup: 20170130T231333Z.meta
Restoring meta data... Error.
restore: operation exited with error: problem setting snapshot: database already exists
```

To work around this, you can restore your telegraf backup into a new database by specifying the `-db` flag for the source and the `-newdb` flag for the new destination:

```bash
$ influxd-ctl restore -db telegraf -newdb restored_telegraf my-incremental-backup/
Using backup directory: my-incremental-backup/
Using meta backup: 20170130T231333Z.meta
Restoring meta data... Done. Restored in 19.915242ms, 1 shards mapped
Restoring db telegraf, rp autogen, shard 2 to shard 7...
Copying data to <hostname>:8088... Copying data to <hostname>:8088... Done. Restored shard 2 into shard 7 in 36.417682ms, 588800 bytes transferred
Restored from my-incremental-backup/ in 56.623615ms, transferred 588800 bytes
```

Then, in the [`influx` client](/enterprise_influxdb/v1/tools/influx-cli/use-influx/), use an [`INTO` query](/enterprise_influxdb/v1/query_language/explore-data/#the-into-clause) to copy the data from the new database into the existing `telegraf` database:

```bash
$ influx
> USE restored_telegraf
Using database restored_telegraf
> SELECT * INTO telegraf..:MEASUREMENT FROM /.*/ GROUP BY *
name: result
------------
time                  written
1970-01-01T00:00:00Z  471
```

##### Restore (overwrite) metadata from a full or incremental backup to fix damaged metadata

1. Identify a backup with uncorrupted metadata from which to restore.
2. Restore from backup with `-meta-only-overwrite-force`.

   {{% warn %}}
   Only use the `-meta-only-overwrite-force` flag to restore from backups of the target cluster.
   If you use this flag with metadata from a different cluster, you will lose data.
   (since metadata includes shard assignments to data nodes).
   {{% /warn %}}

   ```bash
   # Syntax
   influxd-ctl restore -meta-only-overwrite-force <path-to-backup-directory>

   # Example
   $ influxd-ctl restore -meta-only-overwrite-force my-incremental-backup/
   Using backup directory: my-incremental-backup/
   Using meta backup: 20200101T000000Z.meta
   Restoring meta data... Done. Restored in 21.373019ms, 1 shards mapped
   Restored from my-incremental-backup/ in 19.2311ms, transferred 588 bytes
   ```

#### Common issues with restore

##### Restore writes information not part of the original backup

If a [restore from an incremental backup](#syntax-to-restore-from-incremental-and-metadata-backups)
does not limit the restore to the same database, retention policy, and shard specified by the backup command,
the restore may appear to restore information that was not part of the original backup.
Backups consist of a shard data backup and a metastore backup.
The **shard data backup** contains the actual time series data: the measurements, tags, fields, and so on.
The **metastore backup** contains user information, database names, retention policy names, shard metadata, continuous queries, and subscriptions.

When the system creates a backup, the backup includes:

* the relevant shard data determined by the specified backup options
* all of the metastore information in the cluster regardless of the specified backup options

Because a backup always includes the complete metastore information, a restore that doesn't include the same options specified by the backup command may appear to restore data that were not targeted by the original backup.
The unintended data, however, include only the metastore information, not the shard data associated with that metastore information.

##### Restore a backup created prior to version 1.2.0

InfluxDB Enterprise introduced incremental backups in version 1.2.0.
To restore a backup created prior to version 1.2.0, be sure to follow the syntax
for [restoring from a full backup](#restore-from-a-full-backup).

## Exporting and importing data

For most InfluxDB Enterprise applications, the [backup and restore utilities](#backup-and-restore-utilities) provide the tools you need for your backup and restore strategy. However, in some cases, the standard backup and restore utilities might not adequately handle the volumes of data in your application.  

As an alternative to the standard backup and restore utilities, use the InfluxDB `influx_inspect export` and `influx -import` commands to create backup and restore procedures for your disaster recovery and backup strategy. These commands can be executed manually or included in shell scripts that run the export and import operations at scheduled intervals (example below).

- [Exporting data](#exporting-data)
- [Importing data](#importing-data)
- [Example: export and import for disaster recovery](#example-export-and-import-for-disaster-recovery)

### Exporting data

Use the [`influx_inspect export` command](/enterprise_influxdb/v1/tools/influx_inspect#export) to export data in line protocol format from your InfluxDB Enterprise cluster.
Options include the following:

- `-database`: Export all or specific databases
- `-start` and `-end`: Filter with starting and ending timestamps
- `-compress`: Use GNU zip (gzip) compression for smaller files and faster exports

The following example shows how to export data filtered to one day and compressed
for optimal speed and file size:

```bash
influx_inspect export \
  -database DATABASE_NAME \
  -compress \
  -start 2019-05-19T00:00:00.000Z \
  -end 2019-05-19T23:59:59.999Z
```

The exported file contains the following:

```sh
# DDL
CREATE DATABASE <DATABASE_NAME> WITH NAME <RETENTION_POLICY>
# DML
# CONTEXT-DATABASE:<DATABASE_NAME>
# CONTEXT-RETENTION-POLICY:<RETENTION_POLICY>

<LINE_PROTOCOL_DATA>
```

- `DDL`: an InfluxQL `CREATE` statement to create the target database when [importing the data](#importing-data)
- `DML`: Context metadata that specifies the target database and retention policy
  for [importing the data](#importing-data)
- the line protocol data

For details on optional settings and usage, see [`influx_inspect export` command](/enterprise_influxdb/v1/tools/influx_inspect#export).
 
### Importing data

To import line protocol data from a file, use the [`influx -import` CLI command](/enterprise_influxdb/v1/tools/influx-cli/use-influx-cli/#influx-arguments).

In your import file, include the following sections:

- _Optional_: **DDL (Data Definition Language)**: Contains the [InfluxQL commands](/enterprise_influxdb/v1/query_language/manage-database/) for creating the relevant [database](/enterprise_influxdb/v1/concepts/glossary/#database) and managing the [retention policy](/enterprise_influxdb/v1/concepts/glossary/#retention-policy-rp).
If your database and retention policy already exist, your file can skip this section.
- **DML (Data Manipulation Language)**: Context metadata that specifies the database and (if desired) retention policy for the import and contains the data in [line protocol](/enterprise_influxdb/v1/concepts/glossary/#influxdb-line-protocol).

In the following example, the compressed data file (in GNU zip format) is imported into the database
specified in the file's `DML` metadata.

```bash
influx -import -path -compressed
```

For details on using the `influx -import` command, see [Import data from a file](/enterprise_influxdb/v1/tools/influx-cli/use-influx-cli/#import-data-from-a-file).

### Example: export and import for disaster recovery

For an example of using the exporting and importing data approach for disaster recovery, see the presentation from Influxdays 2019 on ["Architecting for Disaster Recovery."](https://www.youtube.com/watch?v=LyQDhSdnm4A). In this presentation, Capital One discusses the following:

- Exporting data every 15 minutes from an active InfluxDB Enterprise cluster to an AWS S3 bucket.
- Replicating the export file in the S3 bucket using the AWS S3 copy command.
- Importing data every 15 minutes from the AWS S3 bucket to an InfluxDB Enterprise cluster available for disaster recovery.
- Advantages of the export-import approach over the standard backup and restore utilities for large volumes of data.
- Managing users and scheduled exports and imports with a custom administration tool.