备份和恢复
使用 InfluxDB 企业版 backup、restore、export 和 import 工具来防止意外的数据丢失，并保持在数据丢失时恢复数据的能力。
您可以在备份和恢复程序中使用这些工具来：
- 提供由于意外事件导致的灾难恢复
- 将数据迁移到新的环境或服务器
- 将集群恢复到一致状态
- 导出和导入用于调试的数据
根据要保护的数据量和您的应用程序要求，InfluxDB Enterprise 提供了两种方法，如下所述，用于管理备份和恢复数据：
在InfluxDB Enterprise和OSS之间备份和恢复
使用InfluxDB Enterprise和InfluxDB OSS (版本 1.5及更高版本)中的backup和restore工具来：
- 将InfluxDB Enterprise备份文件恢复到InfluxDB OSS实例。
- 备份可在InfluxDB Enterprise集群中恢复的InfluxDB OSS数据。
备份和恢复工具
使用 InfluxDB Enterprise 备份和恢复工具来：
- 同时备份和恢复多个数据库。
- 备份特定时间范围。
- 创建与 InfluxDB OSS 兼容的备份文件。
InfluxDB Enterprise 支持在集群中备份和恢复数据、单一数据库和保留策略，以及单个分片。大多数 InfluxDB Enterprise 应用程序可以使用备份和恢复工具。
使用 backup 和 restore 工具在版本相同或仅有小版本差异的 influxd 实例之间进行备份和恢复。 例如，您可以在 1.11.8 上进行备份和恢复。
备份工具
备份会在那个时间点创建metastore和shard数据的副本，并将副本存储在指定目录中。
要备份 仅集群元存储，请使用 -strategy only-meta 备份选项。有关更多信息，请参阅如何 执行元存储仅备份。
所有备份都包含一个清单，一个描述在备份过程中收集了什么的JSON文件。 文件名反映了备份创建时的UTC时间戳，例如：
- 元存储备份:
20060102T150405Z.meta(包括用户名和密码) - 分片数据备份:
20060102T150405Z..tar.gz - 清单:
20060102T150405Z.manifest
备份可以是完全备份、仅元存储或增量备份，默认为增量备份：
- 完整备份: 创建元存储和分片数据的副本。
- 增量备份: 创建自上次备份以来已更改的元存储和分片数据的副本（指定目录中最新的备份文件）。如果目录中不存在备份，则系统会自动执行完整备份。
- 仅元数据存储备份: 仅创建元数据存储数据的副本。
恢复不同类型的备份需要不同的语法。 为了防止与 restore 相关的问题，请将完整备份、仅元存储备份和增量备份保存在不同的目录中。
备份和恢复性能
备份工具通过用于执行备份的元节点复制所有数据。结果是，备份和恢复性能通常受到元节点网络IO的限制。增加可用的元节点资源（例如，调整EC2实例的大小）可以显著提高备份和恢复性能。
语法
influxd-ctl [global-options] backup [backup-options] <path-to-backup-directory>
如果成功，influxd-ctl backup 命令将以 0 状态退出；否则，将以错误 (1) 状态退出，并提供一条可用于故障排除的消息。
全局标志
请查看 influxd-ctl 文档 以获取全局 influxd-ctl 标志的完整列表。
备份标志
-db: 要备份的单一数据库名称-from: 备份时首选的数据节点TCP地址-strategy: 选择在备份过程中应用的备份策略incremental: (默认) 备份自上次备份以来的新数据或更改的数据。full执行完整备份。与-full相同only-meta仅执行元数据备份：用户、角色、数据库、连续查询、保留策略。分片不被导出。
-full: 执行完整备份。已被-strategy=full取代-rp: 要备份的单个保留策略的名称（必须与-rp一起指定-db）-shard: 要备份的 shard ID（如果提供了-rp或-db标志，指定的数据库或保留策略必须与 shard 中的匹配）-start: 包含所有从指定时间戳开始的点（RFC3339格式）。与-since或-strategy full不兼容。-end: 排除时间戳之后的所有点（RFC3339格式）。与-since或-strategy full不兼容。
示例
备份数据库及所有保留策略
以下示例将数据库的增量备份和所有保留策略存储在 ./myfirstdb-allrp-backup 目录中：
influxd-ctl backup -db myfirstdb ./myfirstdb-allrp-backup
使用特定保留策略备份数据库
以下示例将增量备份存储在指定数据库和保留策略组合的单独目录中。
influxd-ctl backup -db myfirstdb -rp oneday ./myfirstdb-oneday-backup
influxd-ctl backup -db myfirstdb -rp autogen ./myfirstdb-autogen-backup
输出包含状态和备份文件路径，例如：
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
从特定时间范围备份数据
要在特定时间范围内备份数据，请使用 -start 和 -end 选项：
influxd-ctl backup -db myfirstdb ./myfirstdb-jandata -start 2022-01-01T012:00:00Z -end 2022-01-31T011:59:00Z
执行增量备份
增量备份策略（默认，-strategy=incremental）会检查指定目录中是否存在备份文件。
- 如果存在备份，
influxd-ctl执行增量备份，只保存自最近备份文件以来发生变化的数据。 - 如果没有备份，它会创建InfluxDB中所有数据的完整备份。
以下示例显示如何运行存储在当前目录中的增量备份：
# 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
执行完整备份
以下示例展示了如何在特定目录中运行完整备份。目录必须已存在。
# 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
对单个数据库执行增量备份
使用 -bind 选项指定一个远程 meta node 进行连接。
以下示例演示了如何连接到远程元服务器并将特定数据库备份到本地系统中的指定目录。目录必须已经存在。
# 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
仅执行元数据备份
以下示例演示如何在特定目录中创建和存储仅包含元数据的备份。 目录必须已经存在。
# 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
恢复工具
在恢复备份之前禁用抗熵（AE）
在恢复备份之前，首先停止集群中每个数据节点的抗熵（AE）服务，逐个停止。
- 停止
influxd服务。 - 在 influx 配置文件 (默认是 influx.conf) 中将
[anti-entropy].enabled设置为false。 - 重启
influxd服务，并等待数据节点接收读写请求，以及 hinted handoff queue 清空。 - 一旦在所有数据节点上禁用了 AE，并且每个节点返回到健康状态，您就可以准备恢复备份。有关如何恢复备份的详细信息，请参见下面的示例。
- 在恢复备份后，重新启动每个数据节点上的AE服务。
恢复备份
将备份恢复到现有集群或新集群。 默认情况下，恢复使用备份数据的 复制因子 写入数据库。 在恢复单个数据库时，可以使用 -newrf 标志指定备用复制因子。 恢复支持 -full 备份和增量备份；恢复的语法根据备份类型而异。
从现有集群恢复到新集群
从现有集群恢复到新集群，恢复现有集群的 users、角色、 databases和 continuous queries到 新集群。
它们不恢复 Kapacitor subscriptions。此外，恢复到新的集群会丢弃新集群的 _internal 数据库中的任何数据，并开始向该数据库重新写入。恢复不会将现有集群的 _internal 数据库写入新集群。
从增量备份和元数据备份恢复的语法
使用下面的语法将增量或元数据备份恢复到新集群或现有集群。现有集群在受影响的数据库中必须不包含数据。从增量备份恢复需要增量备份目录的路径。
influxd-ctl [global-options] restore [restore-options] <path-to-backup-directory>
现有集群可以在 _internal 数据库中拥有数据（如果启用了 internal monitoring，InfluxDB 会创建该数据库）。系统在执行完全恢复时会自动删除 _internal 数据库。
全局标志
请查看 influxd-ctl 文档 以获取全局 influxd-ctl 标志的完整列表。
恢复标志
查看influxd-ctl 文档以获取influxd-ctl restore标志的完整列表。
-db: 要恢复的单一数据库的名称-list: 显示备份的内容-newdb: 要恢复的新数据库的名称（必须与-db一起指定）-newrf: 要恢复的新复制因子（这个值限制为集群中的数据节点数量）-newrp: 要恢复的新保留策略的名称（必须与-rp一起指定）-rp: 要恢复的单个保留策略的名称-shard: 要恢复的分片ID
从完整备份或仅清单备份恢复的语法
使用下面的语法将完整备份或仅清单备份恢复到新集群或现有集群。 注意，现有集群在受影响的数据库中不得包含任何数据。* 执行恢复需要 -full 标志和备份清单文件的路径。
influxd-ctl [global-options] restore [options] -full <path-to-manifest-file>
* 现有的集群可以在 _internal 数据库中存有数据，该数据库是系统默认创建的。
系统在执行完全恢复时会自动删除 _internal 数据库。
全局标志
请查看 influxd-ctl 文档 以获取全局 influxd-ctl 标志的完整列表。
恢复标志
请查看influxd-ctl 文档以获取influxd-ctl restore 标志的完整列表。
-db: 要恢复的单个数据库的名称-list: 显示备份的内容-newdb: 要恢复到的新数据库的名称（必须与-db一起指定）-newrf: 要恢复的新副本因子（这个值限制为集群中的数据节点数量）-newrp: 需要恢复的新保留策略的名称（必须与-rp一起指定）-rp <string>: 要恢复的单个保留策略的名称-shard: 要恢复的分片 ID
示例
从增量备份恢复
# 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命令恢复存储在元数据备份中的备份，位于metadata-backup/目录中。
# 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
从 -full 备份恢复
# 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
从增量备份恢复单个数据库并为数据库赋予新名称
# 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
从增量备份恢复数据库并将该数据库合并到现有数据库中
您的 telegraf 数据库被错误地删除了，但您有最近的备份，所以您只丢失了一小部分数据。
如果 Telegraf 仍在运行，它将在数据库被删除后不久重新创建 telegraf 数据库。您可能会尝试直接恢复您的 telegraf 备份，却发现您无法恢复：
$ 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
为了解决这个问题，您可以通过为源指定 -db 标志和为新目标指定 -newdb 标志，将您的 telegraf 备份还原到一个新数据库中：
$ 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
然后，在influx客户端中，使用INTO查询将数据从新数据库复制到现有的telegraf数据库中：
$ 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
从完整或增量备份恢复（覆盖）元数据以修复损坏的元数据
识别一个具有未损坏元数据的备份以进行恢复。
使用
-meta-only-overwrite-force从备份恢复。仅使用
-meta-only-overwrite-force标志从目标集群的备份中恢复。 如果您将此标志与来自不同集群的元数据一起使用，您将丢失数据。 （因为元数据包括对数据节点的分片分配）。# 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
恢复的常见问题
恢复写入的信息不是原始备份的一部分
如果从增量备份恢复没有限制恢复到与备份命令指定的相同数据库、保留策略和分片，恢复可能会显示恢复了原始备份中没有的部分信息。备份包括分片数据备份和元存储备份。分片数据备份包含实际的时间序列数据：测量、标签、字段等等。元存储备份包含用户信息、数据库名称、保留策略名称、分片元数据、持续查询和订阅。
当系统创建备份时，备份包括：
- 由指定备份选项确定的相关分片数据
- 集群中所有的元存储信息，无论指定的备份选项如何
因为备份总是包括完整的元存储信息，所以一个不包括与备份命令指定的相同选项的恢复可能看起来会恢复未被原始备份针对的数据。 然而，意外的数据仅包括元存储信息，而不包括与该元存储信息相关的分片数据。
恢复版本1.2.0之前创建的备份
InfluxDB Enterprise 在1.2.0版本中引入了增量备份。 要恢复在1.2.0版本之前创建的备份，请务必遵循 从完整备份恢复 的语法。
导出和导入数据
对于大多数 InfluxDB Enterprise 应用程序，备份和恢复工具 提供了您所需的备份和恢复策略工具。然而，在某些情况下，标准的备份和恢复工具可能无法充分处理您应用程序中的数据量。
作为标准备份和恢复工具的替代方案，可以使用 InfluxDB influx_inspect export 和 influx -import 命令来创建灾难恢复和备份策略的备份和恢复程序。这些命令可以手动执行，也可以包含在定期运行导出和导入操作的 shell 脚本中（以下是示例）。
导出数据
使用influx_inspect export命令从您的InfluxDB Enterprise集群中以行协议格式导出数据。选项包括以下内容：
-database: 导出所有或特定数据库-start和-end: 使用起始和结束时间戳进行过滤-compress: 使用GNU zip (gzip)压缩以获得更小的文件和更快的导出
以下示例演示了如何导出过滤到一天的数据并进行压缩，以实现最佳速度和文件大小：
influx_inspect export \
-database DATABASE_NAME \
-compress \
-start 2019-05-19T00:00:00.000Z \
-end 2019-05-19T23:59:59.999Z
导出的文件包含以下内容：
# DDL
CREATE DATABASE <DATABASE_NAME> WITH NAME <RETENTION_POLICY>
# DML
# CONTEXT-DATABASE:<DATABASE_NAME>
# CONTEXT-RETENTION-POLICY:<RETENTION_POLICY>
<LINE_PROTOCOL_DATA>
有关可选设置和用法的详细信息，请参见 influx_inspect export 命令。
导入数据
要从文件导入线协议数据，请使用influx -import CLI命令。
在您的导入文件中，包含以下部分：
- 可选: DDL（数据定义语言）: 包含用于创建相关 数据库 和管理 保留策略 的 InfluxQL 命令。 如果您的数据库和保留策略已经存在，您的文件可以跳过此部分。
- DML (数据操纵语言): 上下文元数据，指定数据库和（如有需要）导入的保留策略，并包含行协议中的数据。
在下面的示例中，压缩的数据文件（以GNU zip格式）被导入到文件的 DML 元数据指定的数据库中。
influx -import -path -compressed
有关使用 influx -import 命令的详细信息，请参见 从文件导入数据。
示例：灾难恢复的导出和导入
有关使用导出和导入数据方法进行灾难恢复的示例，请参见 Influxdays 2019 上的 “Architecting for Disaster Recovery.” 演示。在此演示中，Capital One 讨论了以下内容：
- 每15分钟从一个活跃的InfluxDB企业集群导出数据到AWS S3桶。
- 使用AWS S3复制命令复制S3桶中的导出文件。
- 每15分钟从AWS S3桶导入数据到可用于灾难恢复的InfluxDB企业集群。
- 出口-进口方法相对于标准备份和恢复工具在处理大量数据时的优势。
- 使用自定义管理工具管理用户和定期导入导出。