本文档采用自动化机器翻译技术翻译。尽管我们力求提供准确的译文，但不对翻译内容的完整性、准确性或可靠性作出任何保证。若出现任何内容不一致情况，请以原始英文版本为准，且原始英文版本为权威文本。

Kubernetes 备份（遗留）

本页面描述了使用脚本的遗留备份方法。对于 SUSE® Observability v2.7.0 或更高版本，请使用新的备份 CLI。

v2.7.0 中的重大更改：

backup.enabled 被 global.backup.enabled 替代 - 如果 backup.enabled 设置为 true，则 Helm 部署将失败。
所有备份都通过单个值 global.backup.enabled 控制，而不是按数据存储启用。
*.restore.enabled 值已被移除。

概述

SUSE® Observability 具有内置的备份和恢复机制，可以配置为将备份存储到本地群集、AWS S3 或 Azure Blob 存储。

备份范围

以下数据可以自动备份：

存储在 StackGraph 中的*配置和拓扑数据*
存储在 SUSE Observability 的 Victoria Metrics 实例中的*指标*
存储在 SUSE Observability 的 Elasticsearch 实例中的*遥测数据*
存储在 SUSE Observability 的 ClickHouse 实例中的*OpenTelemetry 数据*

以下数据将不会被备份：

在 Kafka 中存储的传输拓扑和遥测更新 - 这些仅具有临时价值，在恢复备份时将无用。
存储在 ZooKeeper 中的主节点协商状态 - 此运行时状态在恢复时将不正确，并将在运行时自动确定。
Kubernetes 配置状态和原始持久卷状态 - 此状态可以通过重新安装 SUSE Observability 并恢复备份来重建。
Kubernetes 日志 - 这些是短暂的。

存储选项

备份会发送到一个https://min.io/[MinIO (min.io)]的实例，该实例由`suse-observability` Helm 图表在启用自动备份时自动启动。MinIO 是一个具有与 AWS S3 相同 API 的对象存储系统。它可以在本地存储数据，或作为通往https://docs.min.io/docs/minio-gateway-for-s3.html[AWS S3 (min.io)]、https://docs.min.io/docs/minio-gateway-for-azure.html[Azure Blob Storage (min.io)]和其他系统的网关。

内置的MinIO实例可以配置为在三个位置存储备份：

启用备份

AWS S3

加密

在加密存储备份的S3桶时，应使用Amazon S3管理的密钥（SSE-S3）。

⚠️ 不支持使用存储在AWS密钥管理服务中的AWS KMS密钥进行加密（SSE-KMS）。这将导致Elasticsearch日志中出现如下错误：

Caused by: org.elasticsearch.common.io.stream.NotSerializableExceptionWrapper: sdk_client_exception: Unable to verify integrity of data upload. Client calculated content hash (contentMD5: ZX4D/ZDUzZWRhNDUyZTI1MTc= in base 64) didn’t match hash (etag: c75faa31280154027542f6530c9e543e in hex) calculated by Amazon S3. You may need to delete the data stored in Amazon S3. (metadata.contentMD5: null, md5DigestStream: com.amazonaws.services.s3.internal.MD5DigestCalculatingInputStream@5481a656, bucketName: suse-observability-elasticsearch-backup, key: tests-UG34QIV9s32tTzQWdPsZL/master.dat)",

要启用定期备份到AWS S3桶，请将以下YAML片段添加到用于安装SUSE Observability的Helm `values.yaml`文件中：

global:
  backup:
    enabled: true
backup:
  stackGraph:
    bucketName: AWS_STACKGRAPH_BUCKET
  elasticsearch:
    bucketName: AWS_ELASTICSEARCH_BUCKET
  configuration:
    bucketName: AWS_CONFIGURATION_BUCKET
victoria-metrics-0:
  backup:
    bucketName: AWS_VICTORIA_METRICS_BUCKET
victoria-metrics-1:
  backup:
    bucketName: AWS_VICTORIA_METRICS_BUCKET
clickhouse:
  backup:
    bucketName: AWS_CLICKHOUSE_BUCKET
minio:
  accessKey: YOUR_ACCESS_KEY
  secretKey: YOUR_SECRET_KEY
  s3gateway:
    enabled: true
    accessKey: AWS_ACCESS_KEY
    secretKey: AWS_SECRET_KEY

替换以下值：

`YOUR_ACCESS_KEY`和`YOUR_SECRET_KEY`是用于保护MinIO系统的凭据。这些凭据在MinIO系统上设置，并由自动备份作业和恢复作业使用。如果您想手动访问MinIO系统，这些凭据也是必需的。
- YOUR_ACCESS_KEY应包含5到20个字母数字字符。
- YOUR_SECRET_KEY应包含8到40个字母数字字符。
`AWS_ACCESS_KEY`和`AWS_SECRET_KEY`是具有访问存储备份的S3桶的IAM用户的AWS凭据。请参见下方需要附加到该用户的权限策略。
AWS_STACKGRAPH_BUCKET、AWS_CONFIGURATION_BUCKET、AWS_ELASTICSEARCH_BUCKET、AWS_VICTORIA_METRICS_BUCKET`和`AWS_CLICKHOUSE_BUCKET`是备份应存储的S3桶的名称。注意：AWS S3桶的名称在整个AWS中是全局的，因此默认名称的S3桶（`sts-elasticsearch-backup、sts-configuration-backup、sts-stackgraph-backup、sts-victoria-metrics-backup`和`sts-clickhouse-backup）可能不可用。

由`AWS_ACCESS_KEY`和`AWS_SECRET_KEY`标识的IAM用户必须配置以下权限策略以访问S3桶：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowListMinioBackupBuckets",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": [
                "arn:aws:s3:::AWS_STACKGRAPH_BUCKET",
                "arn:aws:s3:::AWS_ELASTICSEARCH_BUCKET",
                "arn:aws:s3:::AWS_VICTORIA_METRICS_BUCKET",
                "arn:aws:s3:::AWS_CLICKHOUSE_BUCKET",
                "arn:aws:s3:::AWS_CONFIGURATION_BUCKET"
            ]
        },
        {
            "Sid": "AllowWriteMinioBackupBuckets",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::AWS_STACKGRAPH_BUCKET/*",
                "arn:aws:s3:::AWS_ELASTICSEARCH_BUCKET/*",
                "arn:aws:s3:::AWS_VICTORIA_METRICS_BUCKET/*",
                "arn:aws:s3:::AWS_CLICKHOUSE_BUCKET/*",
                "arn:aws:s3:::AWS_CONFIGURATION_BUCKET"
            ]
        }
    ]
}

Azure Blob存储

要启用备份到Azure Blob存储帐户，请将以下YAML片段添加到用于安装SUSE Observability的Helm `values.yaml`文件中：

global:
  backup:
    enabled: true
minio:
  accessKey: AZURE_STORAGE_ACCOUNT_NAME
  secretKey: AZURE_STORAGE_ACCOUNT_KEY
  azuregateway:
    enabled: true

替换以下值：

AZURE_STORAGE_ACCOUNT_NAME - Azure 存储帐户名称 (learn.microsoft.com)
AZURE_STORAGE_ACCOUNT_KEY - Azure 存储帐户密钥 (learn.microsoft.com)，备份应存储在此处。

StackGraph、Elasticsearch和Victoria Metrics的备份分别存储在名为`sts-stackgraph-backup`、sts-configuration-backup、sts-elasticsearch-backup、sts-victoria-metrics-backup、sts-clickhouse-backup`的容器中。可以通过分别设置 Helm 值`backup.stackGraph.bucketName、backup.elasticsearch.bucketName、victoria-metrics-0.backup.bucketName、`victoria-metrics-1.backup.bucketName`和`clickhouse.backup.bucketName`来更改这些名称。

Kubernetes存储

如果MinIO配置为在Kubernetes存储中存储其数据，则使用PersistentVolumeClaim（PVC）从Kubernetes集群请求存储。分配的存储类型取决于集群的配置。

建议在 Amazon AWS 上运行的集群使用 AWS S3，在 Azure 上运行的集群使用 Azure Blob 存储，原因如下：

在云提供商中运行的Kubernetes集群通常将PVC映射到块存储，例如AWS的弹性块存储或Azure的块存储。块存储成本高，尤其是对于大数据量。
当创建它们的集群被销毁时，持久卷将被销毁。这意味着（意外）删除集群也会销毁存储在持久卷中的所有备份。
持久卷无法从另一个集群访问。这意味着无法从在另一个集群上进行的备份中恢复SUSE Observability。

要启用备份到集群本地存储，请通过将以下YAML片段添加到用于安装SUSE Observability的Helm `values.yaml`文件中来启用MinIO：

global:
  backup:
    enabled: true
minio:
  accessKey: YOUR_ACCESS_KEY
  secretKey: YOUR_SECRET_KEY
  persistence:
    enabled: true

替换以下值：

YOUR_ACCESS_KEY 和 YOUR_SECRET_KEY - 用于保护 MinIO 系统的凭据。自动备份作业和恢复作业将使用它们。它们还需要手动访问 MinIO 存储。YOUR_ACCESS_KEY 应包含 5 到 20 个字母数字字符，YOUR_SECRET_KEY 应包含 8 到 40 个字母数字字符。

配置和拓扑数据（StackGraph）

配置和拓扑数据（StackGraph）备份是完整备份，存储在扩展名为 .graph 的单个文件中。每个文件包含一个完整备份，可以根据需要移动、复制或删除。

备份计划

默认情况下，StackGraph 备份每天在服务器时间的凌晨 03:00 创建。

备份计划可以使用 Helm 值 backup.stackGraph.scheduled.schedule 配置，指定在 Kubernetes cron 调度语法 (kubernetes.io) 中。

备份保留

默认情况下，StackGraph 备份保留 30 天。由于 StackGraph 备份是完整备份，这可能需要大量存储。

备份保留增量可以使用 Helm 值 backup.stackGraph.scheduled.backupRetentionTimeDelta 配置，格式为 GNU 日期 --date 参数。例如，默认值是 30 days ago。有关更多示例，请参见日期字符串中的相对项。

禁用计划备份

要禁用计划的 StackGraph 备份，请使用 Helm 值 backup.stackGraph.scheduled.schedule 将备份计划设置为一个很久以前的日期：

backup:
  stackGraph:
    scheduled:
      schedule: '0 0 1 1 1970'  # January 1, 1970 (epoch start)

指标（Victoria Metrics）

Victoria Metrics 使用增量备份而不对存储桶进行版本控制，这意味着新的备份 完全替换之前的备份。

如果您遇到以下情况之一：

将空卷挂载到 Victoria Metrics 实例的 /storage 目录
删除 Victoria Metrics 实例中的 /storage 目录或其中的文件

下一个创建的（空）备份将标记为新版本，而在卷被清空之前的备份将被保留。从那时起，这两个备份将被列为可恢复。

指标（Victoria Metrics）使用即时快照以增量备份的方式存储数据。多个 Victoria Metrics 实例可以将备份存储到同一个存储桶中，每个备份将存储在单独的目录中。目录中的所有文件应视为一个整体，只能作为一个整体进行移动、复制或删除。

高可用部署应使用两个 Victoria Metrics 实例进行部署。备份是为每个实例独立启用/配置的。

以下代码片段/命令适用于 Victoria Metrics 的第一个实例`victoria-metrics-0`。要备份/配置第二个实例，您应使用`victoria-metrics-1`

备份计划

默认情况下，Victoria Metrics 的备份每小时创建一次：

victoria-metrics-0 - 每小时的25分钟
victoria-metrics-1 - 每小时的35分钟

备份计划可以使用Helm值`victoria-metrics-0.backup.scheduled.schedule`根据https://github.com/aptible/supercronic/tree/master/cronexpr[cronexpr格式]进行配置。

禁用计划备份

要禁用计划的 Victoria Metrics 备份，请将两个实例的备份计划设置为一个很久以前的日期：

victoria-metrics-0:
  backup:
    scheduled:
      schedule: '0 0 1 1 1970'  # January 1, 1970 (epoch start)
victoria-metrics-1:
  backup:
    scheduled:
      schedule: '0 0 1 1 1970'  # January 1, 1970 (epoch start)

OpenTelemetry（ClickHouse）

ClickHouse 使用增量备份和完整备份。默认情况下，完整备份每天在凌晨00:45执行，增量备份每小时执行。每个备份创建一个新目录，旧备份（目录）会自动删除。位于备份目录中的所有文件被视为一个整体，只能作为一个整体进行移动、复制或删除。建议使用在`clickhouse-backup` Pod上可用的`suse-observability-clickhouse-shard0-0`工具来管理备份。

备份计划

默认情况下，ClickHouse 备份会创建：

完整备份 - 每天00:45
增量备份 - 每小时的45分钟（从凌晨3点到午夜12点）

备份在并行执行时会遇到困难。如果第二个备份在第一个备份完成之前开始，它将干扰第一个备份。因此，避免并行执行至关重要。例如，第一个增量备份应在完整备份后三小时执行。

备份计划可以使用 Helm 值`clickhouse.backup.scheduled.full_schedule`和 clickhouse.backup.scheduled.incremental_schedule，按照 cronexpr 格式进行配置。

备份保留

默认情况下，工具保留最后 308 个备份（完整和增量），相当于约 14 天。

备份保留可以使用 Helm 值`clickhouse.backup.config.keep_remote`进行配置。

禁用计划备份

要禁用计划的 ClickHouse 备份，请将完整和增量备份计划设置为一个很久以前的日期：

clickhouse:
  backup:
    scheduled:
      full_schedule: '0 0 1 1 1970'         # January 1, 1970 (epoch start)
      incremental_schedule: '0 0 1 1 1970'  # January 1, 1970 (epoch start)

遥测数据（Elasticsearch）

遥测数据（Elasticsearch）快照是增量的，并存储在扩展名为`.dat`的文件中。Elasticsearch 备份存储位置中的文件应视为一个整体，只能作为一个整体进行移动、复制或删除。

在启用备份部分提供的配置片段将启用每日 Elasticsearch 快照。

禁用计划快照

要禁用计划的 Elasticsearch 快照，请使用 Helm 值 backup.elasticsearch.scheduled.schedule 将快照计划设置为一个很久以前的日期：

backup:
  elasticsearch:
    scheduled:
      schedule: '0 0 1 1 1970'  # January 1, 1970 (epoch start)

快照计划

默认情况下，Elasticsearch 快照每天在服务器时间的凌晨 03:00 创建。

备份计划可以使用 Helm 值 backup.elasticsearch.scheduled.schedule 配置，该值在 Elasticsearch cron 调度语法 (elastic.co) 中指定。

快照保留

默认情况下，Elasticsearch 快照保留 30 天，最少保留 5 个快照，最多保留 30 个快照。

保留时间和保留的快照数量可以使用以下 Helm 值配置：

backup.elasticsearch.scheduled.snapshotRetentionExpireAfter，在 Elasticsearch 时间单位 (elastic.co) 中指定。
backup.elasticsearch.scheduled.snapshotRetentionMinCount
backup.elasticsearch.scheduled.snapshotRetentionMaxCount

默认情况下，保留任务本身每天在 UTC 时间凌晨 1:30 运行 (elastic.co)。如果您设置快照的过期时间快于一天，例如出于测试目的，您需要更改保留任务的计划。

快照索引

默认情况下，为名称以 sts 开头的 Elasticsearch 索引创建快照。

为其创建快照的索引可以使用 Helm 值 backup.elasticsearch.scheduled.indices 配置，该值在 JSON 数组格式 (w3schools.com) 中指定。

恢复备份和快照

列出和恢复备份和快照的脚本可以从最新的 SUSE Observability Helm chart 版本下载。下载并提取 backup-scripts-<version>.tar.gz 以开始使用。

在使用脚本之前，请确保：

已安装并配置 kubectl 二进制文件以连接到：
1. 已安装 SUSE Observability 的 Kubernetes 集群。
2. 在该集群中已安装 SUSE Observability 的名称空间。
Helm 值 global.backup.enabled 设置为 true。

列出 StackGraph 备份

要列出 StackGraph 备份，请执行以下命令：

./restore/list-stackgraph-backups.sh

输出应如下所示：

job.batch/stackgraph-list-backups-20210222t111942 created
Waiting for job to start...
=== Listing StackGraph backups in bucket "sts-stackgraph-backup"...
sts-backup-20210215-0300.graph
sts-backup-20210216-0300.graph
sts-backup-20210217-0300.graph
sts-backup-20210218-0300.graph
sts-backup-20210219-0300.graph
sts-backup-20210220-0300.graph
sts-backup-20210221-0300.graph
sts-backup-20210222-0300.graph
===
job.batch "stackgraph-list-backups-20210222t111942" deleted

备份创建时的时间戳是备份名称的一部分。

输出中以 Error from server (BadRequest): 开头的行是预期的。当脚本等待 pod 启动时，它们会出现。

恢复 StackGraph 备份

为了避免意外丢失现有数据，默认情况下备份只能在干净的环境中恢复。 如果您完全确定任何现有数据可以被覆盖，您可以使用命令 -force 来覆盖此安全功能。只有在您确定要恢复备份时才执行恢复命令。

要在干净的环境中恢复 StackGraph 备份，请选择一个备份名称并将其作为以下命令中的第一个参数传递：

./restore/restore-stackgraph-backup.sh sts-backup-20210216-0300.graph

要在 存在数据的环境 中恢复 StackGraph 备份，请选择一个备份名称并将其作为以下命令中的第一个参数，旁边是第二个参数 -force：

请注意，恢复备份时现有数据将被覆盖。

只有在您完全确定任何现有数据可以被覆盖时才这样做。

./restore/restore-stackgraph-backup.sh sts-backup-20210216-0300.graph -force

输出应如下所示：

job.batch/stackgraph-restore-20210222t112142 created
Waiting for job to start...
=== Downloading StackGraph backup "sts-backup-20210216-0300.graph" from bucket "sts-stackgraph-backup"...
download: s3://sts-stackgraph-backup/sts-backup-20210216-1252.graph to ../../tmp/sts-backup-20210216-0300.graph
=== Importing StackGraph data from "sts-backup-20210216-0300.graph"...
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.codehaus.groovy.vmplugin.v7.Java7$1 (file:/opt/docker/lib/org.codehaus.groovy.groovy-2.5.4.jar) to constructor java.lang.invoke.MethodHandles$Lookup(java.lang.Class,int)
WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.vmplugin.v7.Java7$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
===
job.batch "stackgraph-restore-20210222t112142" deleted

如果您在非空数据库上运行缺少 -force 标志的恢复命令，输出将包含如下错误：

ERROR com.stackvista.graph.migration.Restore - Restore isn't possible in a non empty.

以 WARNING: 开头的行是预期的。它们是由在 JDK 11 中运行的 Groovy 生成的，可以忽略。

列出 Victoria Metrics 备份

要列出 Victoria Metrics 备份，请执行以下命令：

./restore/list-victoria-metrics-backups.sh

输出应如下所示：

job.batch/victoria-metrics-list-backups-20231016t125557 created
Waiting for job to start...
Waiting for job to start...
=== Fetching timestamps of last completed incremental backups
victoria-metrics-0 victoria-metrics-0-20231128160000 "Wed, 29 Nov 2023 07:36:00 GMT"
victoria-metrics-0 victoria-metrics-0-20231129092200 "Wed, 29 Nov 2023 10:56:00 GMT"

===
job.batch "victoria-metrics-list-backups-20231016t125557" deleted

您可以看到 Victoria Metrics 实例、特定备份版本和最后一次完成备份的时间。

恢复 Victoria Metrics 备份

恢复功能始终会覆盖数据。您必须小心以避免意外丢失现有数据。

恢复功能要求在恢复过程中停止 Victoria Metrics 的实例。

在恢复过程中，所有新的度量将由`vmagent`缓存，请确保`vmagent`有足够的内存来缓存度量。

要恢复 Victoria Metrics 备份，请选择一个实例名称和一个备份版本，并将它们作为参数传递到以下命令中：

./restore/restore-victoria-metrics-backup.sh victoria-metrics-0 victoria-metrics-0-20231128160000

输出应如下所示：

=== Scaling down the Victoria Metrics instance
statefulset.apps/suse-observability-victoria-metrics-0 scaled
=== Allowing pods to terminate
=== Starting restore job
job.batch/victoria-metrics-restore-backup-20231017t092607 created
=== Restore job started. Follow the logs with the following command:
kubectl logs --follow job/victoria-metrics-restore-backup-20231017t092607
=== After the job has completed clean up the job and scale up the Victoria Metrics instance pods again with the following commands:
kubectl delete job victoria-metrics-restore-backup-20231017t092607
kubectl scale statefulsets suse-observability-victoria-metrics-0 --replicas=1

然后查看日志以检查作业状态

2023-10-17T07:26:42.564Z    info    VictoriaMetrics/lib/backup/actions/restore.go:194    restored 53072307269 bytes from backup in 0.445 seconds; deleted 639118752 bytes; downloaded 1204539 bytes
2023-10-17T07:26:42.564Z    info    VictoriaMetrics/app/vmrestore/main.go:64    gracefully shutting down http server for metrics at ":8421"
2023-10-17T07:26:42.564Z    info    VictoriaMetrics/app/vmrestore/main.go:68    successfully shut down http server for metrics in 0.000 seconds

完成后（确保备份已成功恢复），需要执行之前命令打印的命令：

删除恢复作业
扩容 Victoria Metrics 实例

列出 ClickHouse 备份

以下脚本需要执行`kubectl exec`命令的权限。

要列出 ClickHouse 备份，请执行以下命令：

./restore/list-clickhouse-backups.sh

输出应如下所示：

full_2024-06-17T18-50-00          34.41KiB   17/06/2024 18:50:00   remote                                      tar, regular
incremental_2024-06-17T18-51-00   7.29KiB    17/06/2024 18:51:00   remote   +full_2024-06-17T18-50-00          tar, regular
incremental_2024-06-17T18-54-00   7.29KiB    17/06/2024 18:54:00   remote   +incremental_2024-06-17T18-51-00   tar, regular
incremental_2024-06-17T18-57-00   7.29KiB    17/06/2024 18:57:00   remote   +incremental_2024-06-17T18-54-00   tar, regular
full_2024-06-17T19-00-00          26.41KiB   17/06/2024 19:00:00   remote                                      tar, regular
incremental_2024-06-17T19-00-00   6.52KiB    17/06/2024 19:00:00   remote   +incremental_2024-06-17T18-57-00   tar, regular
incremental_2024-06-17T19-03-00   25.37KiB   17/06/2024 19:03:00   remote   +incremental_2024-06-17T19-00-00   tar, regular
incremental_2024-06-17T19-06-00   7.29KiB    17/06/2024 19:06:00   remote   +incremental_2024-06-17T19-03-00   tar, regular

打印内容为：

名称，以 full_ 开头的名称表示完整备份，incremental_ 表示增量备份
大小，
创建日期，
remote - 备份被上传到远程存储，例如 S3
父备份 - 被增量备份使用
格式和压缩

恢复 ClickHouse 备份

恢复功能会覆盖数据。`otel`数据库中的所有表都会被删除并从备份中恢复。请注意避免意外的数据丢失。

以下脚本需要执行 kubectl exec 命令的权限。

恢复功能需要停止所有生产者（如OpenTelemetry导出器）。该脚本在备份前缩减工作负载，并在备份完成后增加工作负载。

要恢复 ClickHouse 备份，请选择一个备份版本并将其作为参数传递到以下命令中：

./restore/restore-clickhouse-backup.sh incremental_2024-06-17T18-57-00

输出应如下所示：

...
2024/06/17 19:14:19.509498  info download object_disks start backup=incremental_2024-06-17T19-06-00 operation=restore_data table=otel.otel_traces_trace_id_ts_mv
2024/06/17 19:14:19.509530  info download object_disks finish backup=incremental_2024-06-17T19-06-00 duration=0s operation=restore_data size=0B table=otel.otel_traces_trace_id_ts_mv
2024/06/17 19:14:19.509549  info done                      backup=incremental_2024-06-17T19-06-00 duration=0s operation=restore_data progress=12/12 table=otel.otel_traces_trace_id_ts_mv
2024/06/17 19:14:19.509574  info done                      backup=incremental_2024-06-17T19-06-00 duration=66ms operation=restore_data
2024/06/17 19:14:19.509591  info done                      backup=incremental_2024-06-17T19-06-00 duration=167ms operation=restore version=2.5.13
2024/06/17 19:14:19.509684  info clickhouse connection closed logger=clickhouse
Data restored

列出 Elasticsearch 快照

要列出 Elasticsearch 快照，请执行以下命令：

./restore/list-elasticsearch-snapshots.sh

输出应如下所示：

job.batch/elasticsearch-list-snapshots-20210224t133115 created
Waiting for job to start...
Waiting for job to start...
=== Listing Elasticsearch snapshots in snapshot repository "sts-backup" in bucket "sts-elasticsearch-backup"...
sts-backup-20210219-0300-mref7yrvrswxa02aqq213w
sts-backup-20210220-0300-yrn6qexkrdgh3pummsrj7e
sts-backup-20210221-0300-p481sih8s5jhre9zy4yw2o
sts-backup-20210222-0300-611kxendsvh4hhkoosr4b7
sts-backup-20210223-0300-ppss8nx40ykppss8nx40yk
===
job.batch "elasticsearch-list-snapshots-20210224t133115" deleted

备份创建时的时间戳是备份名称的一部分。

删除 Elasticsearch 索引

您可以在恢复脚本中使用`--delete-all-indices`标志以便在恢复之前自动删除所有索引。有关更多信息，请参见恢复 Elasticsearch 快照。

要手动删除现有的Elasticsearch索引并恢复快照，请按照以下步骤操作：

停止索引 - 将所有使用Elasticsearch的部署缩容至0：

kubectl scale --replicas=0 deployment -l observability.suse.com/scalable-during-es-restore="true"

打开Elasticsearch主节点的端口转发：

kubectl port-forward service/suse-observability-elasticsearch-master 9200:9200

获取所有索引的列表：

curl "http://localhost:9200/_cat/indices?v=true"

输出应如下所示：

health status index                              uuid                   pri rep docs.count docs.deleted store.size pri.store.size dataset.size
green  open   .ds-sts_k8s_logs-2025.09.28-004619 9p7RZwNCR-aQwInTMr5Bow   3   1   24511032            0        6gb            3gb          3gb
green  open   sts_topology_events-2025.10.01     86I2JZIeRzqWkK1dolHzhg   1   1    1576132            0    111.6mb         55.8mb       55.8mb
green  open   sts_topology_events-2025.10.02     T-bcrok_S1uVPLusQuCMxw   1   1     999748            0     75.2mb         37.6mb       37.6mb
green  open   .ds-sts_k8s_logs-2025.09.30-004653 rwlcAr0sTPe9NaImtJLIiw   3   1   24387607            0        6gb            3gb          3gb
green  open   sts_topology_events-2025.09.10     T0x-qvyUR2-dg4fyvdZIaQ   1   1    1746143            0    131.6mb         65.8mb       65.8mb

使用以下命令删除一个索引：

curl -X DELETE "http://localhost:9200/INDEX_NAME?pretty"

将`INDEX_NAME`替换为要删除的索引的名称，例如：

curl -X DELETE "http://localhost:9200/sts_internal_events-2021.02.19?pretty"

输出应为：
```
{
"acknowledged" : true
}
```

恢复Elasticsearch快照

当快照被恢复时，现有索引不会被覆盖。

您可以使用`--delete-all-indices`标志通过恢复脚本自动删除所有索引，或按照删除Elasticsearch索引中的描述手动删除它们。

如果Elasticsearch `PersistentVolumes`被重新创建（例如，由于意外删除和随后的pod重启），您必须使用以下两种方法之一重新创建Elasticsearch备份配置：

使用与初始安装相同的配置重新安装SUSE Observability Helm图表（或）

手动触发备份初始化CronJob：

kubectl create job --from=cronjob.batch/suse-observability-backup-init "suse-observability-backup-init-$(date +%s)"

要恢复Elasticsearch快照，请选择一个快照名称并将其作为第一个参数传递。您可以选择性地指定：

要恢复的索引的逗号分隔列表。如果未指定，将恢复与Helm值`backup.elasticsearch.scheduled.indices`匹配的所有索引。默认值为`"sts*"`)。
在版本`2.6.1`中引入，您可以使用"--delete-all-indices"标志在恢复之前自动删除所有现有索引。

基本恢复

./restore/restore-elasticsearch-snapshot.sh \
  sts-backup-20210223-0300-ppss8nx40ykppss8nx40yk

恢复特定索引

./restore/restore-elasticsearch-snapshot.sh \
  sts-backup-20210223-0300-ppss8nx40ykppss8nx40yk \
  "<INDEX_TO_RESTORE>,<INDEX_TO_RESTORE>"

恢复时自动删除索引

./restore/restore-elasticsearch-snapshot.sh \
  sts-backup-20210223-0300-ppss8nx40ykppss8nx40yk \
  --delete-all-indices

使用`--delete-all-indices`标志时，请在提示中确认以继续该操作：

WARNING: All indices will be deleted before restore!
Are you sure you want to continue? (yes/no): yes
=== Starting restore job
job.batch/elasticsearch-restore-20251003t115746 created
=== Restore job started. Follow the logs and clean up the job with the following commands:
kubectl logs --follow job/elasticsearch-restore-20251003t115746
kubectl delete job/elasticsearch-restore-20251003t115746

查看日志以查看删除和恢复进度：

kubectl logs --follow job/elasticsearch-restore-20251003t115746

=== Deleting all indices matching pattern "sts*"...
Found indices to delete:
.ds-sts_k8s_logs-2025.10.03-000007
.ds-sts_k8s_logs-2025.10.03-000004
sts_topology_events-2025.10.02
sts_topology_events-2025.10.03
...
=== All indices deleted successfully
=== Restoring ElasticSearch snapshot "sts-backup-20251003-0925-aby7d1tgs9whvbm6qj04ug" (indices = "sts*") from snapshot repository "sts-backup" in bucket "sts-elasticsearch-backup"...
{
  "snapshot" : {
    "snapshot" : "sts-backup-20251003-0925-aby7d1tgs9whvbm6qj04ug",
    "indices" : [
      ".ds-sts_k8s_logs-2025.10.02-000003",
      "sts_topology_events-2025.10.02",
      "sts_topology_events-2025.10.03"
    ],
    "shards" : {
      "total" : 15,
      "failed" : 0,
      "successful" : 15
    }
  }
}
===

在索引恢复后，扩容所有使用Elasticsearch的部署：

kubectl scale --replicas=1 deployment -l observability.suse.com/scalable-during-es-restore="true"