企业官网建设流程全解析

VictoriaMetrics vmbackup 备份工具完全指南：快照备份、增量备份与智能备份实战

【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics

vmbackup是 VictoriaMetrics 官方提供的备份工具，用于将单机版或集群版 VictoriaMetrics 的指标数据从即时快照（instant snapshot）备份到 GCS、S3、Azure Blob 或本地文件系统，以抵御硬件故障和意外数据丢失。读完本文，你将掌握 vmbackup 的完整命令行用法、完整/增量/智能备份三种策略的选型与部署方式、备份底层工作原理（含源码级证据），以及 Kubernetes 场景下的凭证注入与故障排查技巧。

概述：为什么备份必须基于即时快照

无论是单机版还是集群版 VictoriaMetrics，官方都推荐使用vmbackup定期从即时快照执行数据备份。原因在于：备份期间无需停止 VictoriaMetrics 服务，快照本身是对数据目录的瞬时一致性视图，且快照内所有文件都是不可变的（immutable）。关于快照的创建、列出与删除操作，详见 Single-server-VictoriaMetrics.md 的即时快照章节。

vmbackup的备份过程可以随时中断，使用相同参数重新启动后会自动从断点继续，无需人工干预。备份产生的数据由配套的 vmrestore 工具负责恢复。企业版用户还可以基于vmbackup使用 vmbackupmanager，它能自动创建按小时、按天、按周、按月的备份，并自动执行清理与保留策略。

从源码结构看，vmbackup的入口位于 app/vmbackup/main.go，其工作流程非常清晰：

1. 解析-snapshot.createURL，调用快照创建 HTTP 接口；
2. 以快照目录为源（srcFS）、-dst为目标（dstFS）、-origin为可选加速源（originFS），构造actions.Backup执行备份；
3. 备份完成后自动删除已创建的快照。

主流程中的关键实现参见 app/vmbackup/main.go（快照自动创建与删除）和 app/vmbackup/main.go（备份动作分发：普通备份或纯远程复制）。

支持的存储类型

vmbackup通过-dst参数指定备份目标，支持以下存储类型：

需要注意两点：

• 使用 S3 兼容存储（MinIO、Cloudian 等）时，-dst的 URL 中只写桶名，S3 服务的主机名必须通过-customS3Endpoint参数单独指定（见后文"自定义 S3 endpoint"一节）。
• vmbackup禁止将备份存储到-storageDataPath指向的目录。该目录只能由 VictoriaMetrics 或vmstorage管理。此限制在源码中有明确校验：app/vmbackup/main.go 会检查-dst是否指向数据目录，若指向则直接报错退出。

vmbackup对接不同远端存储的实现分散在 lib/backup 目录下：gcsremote/gcs.go、s3remote/s3.go、azremote/azblob.go、fsremote/fsremote.go，它们统一实现了 lib/backup/common/fs.go 中定义的RemoteFS接口，因此可以在不同存储之间无缝切换。

单节点备份

对单机版 VictoriaMetrics 做一次完整备份，只需一条命令：

./vmbackup -storageDataPath=</path/to/victoria-metrics-data> -snapshot.createURL=http://localhost:8428/snapshot/create -dst=gs://<bucket>/<path/to/new/backup>

各参数含义：

• -storageDataPath：VictoriaMetrics 数据目录路径，必须与单机版 VictoriaMetrics（或集群版vmstorage）启动时-storageDataPath保持一致。
• -snapshot.createURL：创建快照的 HTTP 接口地址。vmbackup会先请求该地址创建快照，备份完成后再自动删除快照。无需停止 VictoriaMetrics，因为备份基于不可变的即时快照进行。
• -dst：备份目标位置，<bucket>为已存在的存储桶名，<path/to/new/backup>为备份存放路径。

更详细的完整备份说明见下文"完整备份"一节。作为最佳实践，官方推荐使用下文介绍的智能备份（smart backups）策略。

集群备份

对 VictoriaMetrics 集群版做完整备份，需要在每个vmstorage节点上分别运行vmbackup，且各节点的备份必须放在远端存储的不同目录中，以避免节点间备份互相冲突。

例如，为 3 个vmstorage节点分别备份：

vmstorage-1$ /vmbackup -storageDataPath=</path/to/vmstorage-data> -snapshot.createURL=http://vmstorage1:8482/snapshot/create -dst=gs://<bucket>/vmstorage-1 vmstorage-2$ /vmbackup -storageDataPath=</path/to/vmstorage-data> -snapshot.createURL=http://vmstorage2:8482/snapshot/create -dst=gs://<bucket>/vmstorage-2 vmstorage-3$ /vmbackup -storageDataPath=</path/to/vmstorage-data> -snapshot.createURL=http://vmstorage3:8482/snapshot/create -dst=gs://<bucket>/vmstorage-3

注意vmbackup需要能访问每个vmstorage节点的数据目录。对于 Kubernetes 部署，官方推荐使用sidecar 容器方式，让vmbackup与vmstorage运行在同一个 Pod 内，从而共享数据卷。

集群版的-snapshot.createURL应指向vmstorage的快照接口（默认端口 8482），例如http://vmstorage1:8482/snapshot/create。集群整体架构可参考 Cluster-VictoriaMetrics.md。

备份类型详解

vmbackup支持增量备份与完整备份两类：

• 增量备份：当-dst指向的目标路径中已存在上一次备份数据时自动启用，此时只上传发生变化的数据。
• 完整备份：当-dst指向空目录时执行全量备份。若通过-origin指向同一远端存储上已有的备份，vmbackup会对新旧备份间共享的数据执行服务器端复制（server-side copy），从而节省数据传输时间和成本。

以下命令均以单机版为例。集群版只需在每个vmstorage节点上执行同样的命令，并将-snapshot.createURL指向对应vmstorage节点即可：

./vmbackup -storageDataPath=</path/to/vmstorage-data> -snapshot.createURL=http://vmstorage1:8482/snapshot/create -dst=gs://<bucket>/vmstorage-1

完整备份（Full backup）

./vmbackup -storageDataPath=</path/to/victoria-metrics-data> -snapshot.createURL=http://localhost:8428/snapshot/create -dst=gs://<bucket>/<path/to/new/backup>

参数拆解：

• </path/to/victoria-metrics-data>：单机版 VictoriaMetrics 或集群版vmstorage中-storageDataPath指向的数据目录。备份基于即时快照进行，无需停止 VictoriaMetrics。
• http://victoriametrics:8428/snapshot/create：创建快照的 URL。vmbackup先通过该 URL 创建快照，执行备份，随后自动删除快照。
• <bucket>：已存在的 GCS 桶名。
• <path/to/new/backup>：新备份的目标路径。

借助已有备份的服务器端复制实现快速完整备份

若目标 GCS 桶中已在-origin路径存在上一次备份，可通过以下命令加速新备份：

./vmbackup -storageDataPath=</path/to/victoria-metrics-data> -snapshot.createURL=http://localhost:8428/snapshot/create -dst=gs://<bucket>/<path/to/new/backup> -origin=gs://<bucket>/<path/to/existing/backup>

其原理是：新旧备份共享的数据直接从-origin到-dst做服务器端复制，备份数据不会在远端存储与本地运行的vmbackup工具之间传输，从而同时节省时间与网络带宽成本。不同云存储厂商的服务器端复制行为存在差异，具体注意事项参见下文"服务器端复制已有备份"一节。

增量备份（Incremental backup）

当-dst指向已存在的备份时，vmbackup自动执行增量备份，仅向远端存储上传新增数据，在大数据量场景下显著节省时间和带宽：

./vmbackup -storageDataPath=</path/to/victoria-metrics-data> -snapshot.createURL=http://localhost:8428/snapshot/create -dst=gs://<bucket>/<path/to/existing/backup>

智能备份（Smart backups）

智能备份是一种将完整备份与增量备份结合、并按配置和可用存储空间高效管理备份数据的策略。在 VictoriaMetrics 中，智能备份的含义是：每日完整备份存放到YYYYMMDD目录，每小时增量备份存放到latest目录。

具体操作分两步：

1. 每小时执行（向latest写入增量备份）：

./vmbackup -storageDataPath=</path/to/victoria-metrics-data> -snapshot.createURL=http://localhost:8428/snapshot/create -dst=gs://<bucket>/latest

该命令创建即时快照并上传到gs://<bucket>/latest，只上传变化的数据（即增量备份），在大数据量备份场景下节省带宽与时间。

2. 每天执行一次（将latest服务器端复制为按日期命名的完整备份）：

./vmbackup -origin=gs://<bucket>/latest -dst=gs://<bucket>/<YYYYMMDD>

该命令将gs://<bucket>/latest中的备份服务器端复制到gs://<bucket>/<YYYYMMDD>，其中<YYYYMMDD>为当天日期，如20240125。

这种"智能备份"策略的价值在于：

• 小时级备份是增量的，网络带宽开销小；
• 既能从最近一小时恢复（latest备份），也能从任意一天恢复（YYYYMMDD备份）。

使用注意事项：

• 执行每日备份时不应同时运行小时级备份，避免并发写入latest造成数据不一致；
• 备份不再需要时应及时清理，以节省存储成本；
• 如需自动化智能备份，可参考基于vmbackup构建的 vmbackupmanager 工具。

服务器端复制已有备份

有时需要纯粹地对已有备份做服务器端复制：通过-origin指定源备份路径、-dst指定目标路径即可，例如：

./vmbackup -origin=gs://bucket/foo -dst=gs://bucket/bar

约束与特性：

• -origin与-dst必须指向同一个对象存储桶或同一个文件系统；
• 服务器端复制通常比常规备份快得多，因为备份数据不经过本地vmbackup工具中转；
• 部分对象存储系统（如 S3 Glacier）在服务器端复制时会执行完整对象拷贝，速度慢且成本高，请先查阅所用存储厂商的文档确认具体行为；
• 若-dst中已有数据，其内容会与-origin数据做同步（sync），从而支持对备份做增量的服务器端复制。

从源码看，纯复制场景（-snapshotName为空、即未指定快照）会走actions.RemoteBackupCopy分支，实现在 lib/backup/actions/copy.go；跨不同类型存储（如 S3 → GCS）时，lib/backup/actions/backup.go 中的crossTypeCopy会通过io.Pipe流式下载-上传完成拷贝。

工作原理：备份算法逐步骤解析

vmbackup的备份算法分为以下 7 步：

1. 通过-snapshot.createURL创建快照；
2. 收集快照、-dst、-origin三处的文件信息；
3. 找出-dst中存在但快照中不存在的文件并删除——这些通常是被合并进更大文件的小文件；
4. 找出快照中存在但-dst中缺失的文件——通常是小体积的新文件和大体积的合并文件；
5. 将第 3 步结果中在-origin里存在的文件做服务器端复制（从-origin到-dst）——这些通常是最古老、体积最大、在多次备份间共享的文件；
6. 将第 3 步剩余的、不在-origin中的文件从快照上传到-dst；
7. 删除已创建的快照。

上述算法的源码实现位于 lib/backup/actions/backup.go 的runBackup函数，其中：

• 步骤 3 对应deleteDstParts（backup.go）；
• 步骤 5 对应copySrcParts中的dst.CopyPart服务器端复制（backup.go）；
• 步骤 6 对应并发上传srcCopyParts，并实时打印已上传字节数、百分比、速度与预计完成时间（ETA）。

此外，备份会生成两个特殊标记文件（定义见 lib/backup/backupnames/filenames.go）：

• backup_metadata.ignore：包含备份元数据（快照创建时间created_at与备份完成时间completed_at，RFC3339 格式），写入逻辑见 backup.go；
• backup_complete.ignore：备份成功完成后创建，vmrestore通过它判断备份是否完整。

1 GiB 分块机制

备份时，vmbackup会把源文件拆分为1 GiB大小的块（chunk），每个块作为备份中的独立文件存储。该常量定义在 lib/backup/common/part.go（MaxPartSize = 1024 * 1024 * 1024）。这种拆分在"备份文件数量"与"临时错误后的重传数据量"之间取得平衡：文件过大则单次网络错误重传成本高，文件过小则远端对象数量过多。

分块逻辑实现在 lib/backup/fslocal/fslocal.go 的ListParts中：对每个文件按MaxPartSize切分，生成带Path、FileSize、Offset、Size字段的Part列表；每个 Part 在远端以路径/文件名/FileSize_Offset_Size（十六进制）的命名方式存储（part.go）。值得注意的是，parts.json与appliedRetention.txt这类内容随时间变化的文件会被分配唯一 key，保证每次备份都会重新复制（part.go）。

快照属性是高效备份的前提

vmbackup的高效性依赖即时快照的以下性质：

• 快照内所有文件不可变（immutable）；
• 旧文件会周期性合并为新文件；
• 越小的文件被合并的概率越高；
• 连续两次快照之间共享大量相同文件。

正是这些性质，使增量备份和基于-origin的服务器端复制能够又快又省。如果这些性质被破坏（例如对非快照的可变文件执行备份），vmbackup可能无法正常工作或性能退化，这一点在源码注释中也有明确警示（lib/backup/actions/backup.go："the backup works only for VictoriaMetrics snapshots made via/snapshot/create"）。

快照的生命周期管理

vmbackup通过-snapshot.createURL自动创建快照，流程为：

• 发起 POST 请求到快照创建接口，解析 JSON 响应中的快照名称（实现见 lib/snapshot/snapshot.go）；
• 快照名称格式为YYYYMMDDhhmmss-十六进制序号，校验规则见 lib/snapshot/snapshotutil/snapshotutil.go；
• 若未显式指定-snapshot.deleteURL，则会从-snapshot.createURL自动推导（将/create替换为/delete），备份结束后自动删除快照（app/vmbackup/main.go）。

数据恢复：vmrestore

备份数据由vmrestore工具恢复，恢复时要求 VictoriaMetrics已停止。vmrestore的用法：

./vmrestore -src=gs://<bucket>/<path/to/backup> -storageDataPath=<path/to/restored/data>

-storageDataPath目录可以非空，恢复时其内容会与-src内容同步（类似rsync --delete），实现增量恢复；-src为备份源路径，支持的存储类型与-dst一致。相关 flag 定义见 app/vmrestore/main.go。

故障排查

• 备份速度慢：尝试调大-concurrency，提高并发上传 worker 数量。
• vmbackup占满网络带宽或 CPU：调低-concurrency，或调低-maxBytesPerSecond限制上传速度。
• 大核数机器上vmbackup占满 CPU：尝试使用-filestream.disableFadvise参数禁用fadvise()系统调用。该调用用于防止后台合并和备份期间最近访问的数据被挤出 OS 页缓存，但在某些罕见场景下会消耗过多 CPU。
• 备份因临时错误中断：直接用相同参数重启vmbackup，它会自动从断点继续。备份成功结束后，记得清理失败尝试期间遗留的旧快照。
• 单机版与集群版备份不可互用：从单机版 VictoriaMetrics 创建的备份不能恢复到集群版 VictoriaMetrics，反之亦然。
• 快照磁盘占用：关于快照如何占用磁盘空间及清理建议，参见 Single-server-VictoriaMetrics.md 的快照故障排查章节。

高级用法

以文件形式提供凭证

关于从凭证文件、环境变量、云厂商 metadata 服务或 Kubernetes Secret / IAM 角色获取凭证的完整说明，参见 connecting-vm-components-to-cloud-storage 指南。下面给出各存储厂商最常见的认证方式示例。

S3（AWS 及 S3 兼容存储）——通过-credsFilePath指定凭证文件：

vmbackup \ -storageDataPath=/data \ -snapshot.createURL=http://localhost:8428/snapshot/create \ -dst=s3://victoriametrics-backup/backup01 \ -credsFilePath=/etc/credentials

Google Cloud Storage（GCS）——同样使用-credsFilePath：

vmbackup \ -storageDataPath=/data \ -snapshot.createURL=http://localhost:8428/snapshot/create \ -dst=gs://victoriametrics-backup/backup01 \ -credsFilePath=/etc/credentials

Azure Blob Storage——通过环境变量注入账号名与密钥：

export AZURE_STORAGE_ACCOUNT_NAME=mystorageaccount export AZURE_STORAGE_ACCOUNT_KEY=myaccountkey vmbackup \ -storageDataPath=/data \ -snapshot.createURL=http://localhost:8428/snapshot/create \ -dst=azblob://victoriametrics-backup/backup01

在 Kubernetes 中提供凭证

最简方式是利用 KubernetesSecret，通过环境变量注入 Pod。例如创建如下 Secret 存放 AWS S3 凭证：

apiVersion: v1 kind: Secret metadata: name: vmbackup-credentials data: access_key: <base64-encoded-key> secret_key: <base64-encoded-secret>

然后在 Pod 中通过secretKeyRef注入环境变量：

env: - name: AWS_ACCESS_KEY_ID valueFrom: secretKeyRef: key: access_key name: vmbackup-credentials - name: AWS_SECRET_ACCESS_KEY valueFrom: secretKeyRef: key: secret_key name: vmbackup-credentials

更安全的方式是使用IAM 角色为 Pod 提供令牌，避免手动管理凭证：

• AWS 部署：需配置 EKS 的 IAM roles for service accounts。为vmbackup/vmbackupmanager创建带 IAM 角色映射注解的 ServiceAccount：

apiVersion: v1 kind: ServiceAccount metadata: name: monitoring-backups annotations: eks.amazonaws.com/role-arn: arn:aws:iam::{ACCOUNT_ID}:role/{ROLE_NAME}

随后将 Pod 配置为使用该 ServiceAccount，vmbackup/vmbackupmanager会自动通过 IAM role for service account 获取凭证。

• GCP 部署：需配置 Workload Identity。创建带 Workload Identity 注解的 ServiceAccount：

--- apiVersion: v1 kind: ServiceAccount metadata: name: monitoring-backups annotations: iam.gke.io/gcp-service-account: {sa_name}@{project_name}.iam.gserviceaccount.com

配置 Pod 使用该 ServiceAccount 后，vmbackup/vmbackupmanager会自动通过 Workload Identity 获取凭证。

使用自定义 S3 endpoint

vmbackup支持与 MinIO、Cloudian 等 S3 兼容存储配合使用，只需通过-customS3Endpoint指定自定义 endpoint：

• MinIO 示例：

-customS3Endpoint=http://localhost:9000

• AWS Gov 区域示例：

-customS3Endpoint=https://s3-fips.us-gov-west-1.amazonaws.com

S3 兼容存储上对象的永久删除

vmbackup与vmbackupmanager在执行增量备份时，对 S3 兼容对象存储使用标准的 delete 操作，该操作只删除对象的当前版本，大多数场景下够用。

若需要删除对象的所有历史版本，可传入-deleteAllObjectVersions命令行参数：

./vmbackup -storageDataPath=... -snapshot.createURL=... -dst=s3://bucket/path -deleteAllObjectVersions

此外，也可以使用对象存储的**生命周期规则（lifecycle rules）**自动清理非当前版本对象，具体请参阅所用存储厂商的文档。

命令行参数详解

运行vmbackup -help可查看全部可用参数。核心参数整理如下：

关键参数的源码定义参见 app/vmbackup/main.go（httpListenAddr、storageDataPath、snapshotName、snapshot.createURL、snapshot.deleteURL、dst、origin、concurrency、maxBytesPerSecond）与 lib/snapshot/snapshot.go（snapshot.tls*系列参数）。

补充说明几个细节参数：

• -envflag.enable：允许从环境变量读取命令行参数（环境变量值优先级低于命令行 flag），-envflag.prefix可为环境变量指定前缀；
• -objectMetadata string：为上传对象设置元数据，JSON 格式，本地文件系统目标不支持；
• -loggerLevel/-loggerFormat/-loggerOutput：控制日志级别（INFO/WARN/ERROR 等）、格式（default或json）与输出（stderr或stdout）；
• -pushmetrics.*：将/metrics页面的指标推送到远端监控系统；
• -license/-licenseFile：企业版 License 配置（仅企业版二进制可用）。

从源码构建

官方推荐直接使用发布页vmutils-*压缩包中的预编译二进制（该压缩包由根目录 Makefile 的release-vmutils-*系列目标生成，其中即包含vmbackup）。

开发构建

1. 安装 Go；
2. 在仓库根目录执行make vmbackup，生成的vmbackup二进制位于bin目录。

生产构建

1. 安装 Docker；
2. 在仓库根目录执行make vmbackup-prod，生成vmbackup-prod二进制到bin目录。

构建 Docker 镜像

执行make package-vmbackup构建victoriametrics/vmbackup:<PKG_TAG>镜像，<PKG_TAG>为根据源码自动生成的镜像标签，也可通过PKG_TAG=foobar make package-vmbackup手动指定。

基础镜像默认为 alpine，可通过<ROOT_IMAGE>环境变量替换为任意基础镜像。例如构建基于 scratch 的镜像：

ROOT_IMAGE=scratch make package-vmbackup

小结

vmbackup以即时快照为基础，为 VictoriaMetrics 提供了可随时中断、断点续传的备份能力，并覆盖 GCS、S3、Azure Blob、S3 兼容存储与本地文件系统等多种目标。完整备份、增量备份与"每日YYYYMMDD完整备份 + 每小时latest增量备份"的智能备份策略，配合-origin服务器端复制加速，可在大数据量场景下显著降低时间与带宽成本。结合本文的源码级原理（1 GiB 分块、Part 差集/交集计算、backup_complete.ignore完成标记、快照自动创建与删除）与故障排查建议，你可以在生产环境可靠地落地 VictoriaMetrics 的数据保护方案，并在必要时通过vmrestore快速恢复数据。

【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics