k8s集群备份备份恢复迁移 Velero

k8s集群备份与恢复-Velero

十八岁2026-09-082026-09-08

k8s集群备份恢复

1.Velero介绍

Velero是一个专为Kubernetes设计的容灾工具，主要用于如下场景：
备份和恢复K8s集群的各类资源
灵活地迁移K8s中的数据
手动及周期性备份和最小范围恢复
对K8s集群进行灾难恢复

Velero核心组件：
服务端:负责处理备份和恢复操作，需要部署在K8s集群中，并且需要配置S3存储后端
客户端:负责与服务端交互，比如备份和恢复等，无需部署，只需要一个客户端工具

Velero核心资源介绍：

Backup:备份资源，用于执行一次性备份任务，可以基于Schedule资源或者自定义字段创建，备份资源可以指定需要备份或排除的空间、资源类型同时支持备份的保留时间等
Schedule:周期性备份，基于Cron表达式创建周期性的备份任务，包含Backup的所有字段
Restore:恢复资源，用于从某个备份中恢复资源，可以指定恢复的资源类型、空间等
BackupStorageLocation:备份存储位置，用于指定备份文件的存储位置比如aws、minio等，同时可以指定对象存储的bucket和prefix

Velero工作原理：还原过程

Velero工作原理：备份过程

2.Minio部署

Velero会把备份文件上传到对象存储中，如果在云上可以直接使用云平台提供的对象存储服务，如果没有也可以部署一个minio服务，作为后端存储，在此次演示中采用minio作为保存备份文件的地方。

我这里用的是Bitnami镜像，和官方镜像在配置上有点差异：

项目	官方镜像	Bitnami 镜像（你用的）
数据目录	`/data`	`/bitnami/minio/data`
运行用户	uid 1000	uid 1001
启动命令	需要手动写 `server /data --console-address ":9001"`	不需要（entrypoint 自动处理）
环境变量	`MINIO_ROOT_USER` / `MINIO_ROOT_PASSWORD`	相同，继续使用
默认 Console	需要显式指定	默认开启 9001

使用Docker部署一个minio服务端：

1
2
3

# 创建数据目录（生产强烈建议放在独立挂载的磁盘上，如 /data/minio）
sudo mkdir -p /data/minio
sudo chown -R 1001:1001 /data/minio #Bitnami镜像以uid 1001运行，MinIO官方容器默认以 uid 1000 运行，这里注意区分

启动minio服务：

docker run -d \
  --name minio \
  --restart=unless-stopped \
  -p 9000:9000 \
  -p 9001:9001 \
  -v /data/minio:/bitnami/minio/data \
  -e MINIO_ROOT_USER=admin \
  -e MINIO_ROOT_PASSWORD=asdqwe123@ \
  -e MINIO_BROWSER=on \
  -e MINIO_DEFAULT_BUCKETS=velerobackup \
  -e MINIO_SERVER_URL=http://192.168.0.89:9000 \
  -e MINIO_BROWSER_REDIRECT_URL=http://192.168.0.89:9001 \
  registry.cn-beijing.aliyuncs.com/dotbalo/minio:latest

访问测试minio：

3.Vleero部署

3.1版本确认及下载

部署 Velero 之前，需要找到适合的版本和插件的版本，对应关系是根据k8s的版本找到对应的velero版本，在根据velero的版本找到对应的插件版本：

Velero 版本选择: https://github.com/vmware-tanzu/velero?tab=readme-ovfile#velero-compatibility-matrix

我的k8s版本是1.31.4，所以选择velero的版本是1.16，镜像仓库地址velero/velero:v1.16.2

插件版本选择: https://github.com/velero-io/velero-plugin-for-aws?tab=readme-ov-file#compatibility

因为上面选择的velero的版本是1.16，所以插件版本要选择v1.12x，镜像仓库地址velero/velero-plugin-for-aws:v1.12.2

接下来下载对应版本呢的客户端工具：https://github.com/velero-io/velero/releases

选择合适的客户端版本下载即可：

3.2Velero客户端安装

将下载好的Velero客户端上传到服务器：

1
2
3

[root@k8s-master01 42-velero]# ll
total 54112
-rw-r--r-- 1 root root 55406798 Sep  7 16:55 velero-v1.16.2-linux-amd64.tar.gz

解压并授予执行权限：

# 解压
[root@k8s-master01 42-velero]# tar -zxf velero-v1.16.2-linux-amd64.tar.gz
[root@k8s-master01 42-velero]# ll
total 54112
drwxr-xr-x 3 root root       51 Sep  7 16:59 velero-v1.16.2-linux-amd64
-rw-r--r-- 1 root root 55406798 Sep  7 16:55 velero-v1.16.2-linux-amd64.tar.gz

[root@k8s-master01 42-velero]# ll velero-v1.16.2-linux-amd64/
total 131524
drwxr-xr-x 4 root root        36 Sep  7 16:59 examples
-rw-r--r-- 1 root root     10255 Mar 31  2025 LICENSE
-rwxr-xr-x 1 root root 134667589 Jul 30  2025 velero

# 将解压好的二进制文件velero移动到/usr/local/bin/下
[root@k8s-master01 42-velero]# mv velero-v1.16.2-linux-amd64/velero /usr/local/bin/
[root@k8s-master01 42-velero]# ll /usr/local/bin/velero
-rwxr-xr-x 1 root root 134667589 Jul 30  2025 /usr/local/bin/velero

#如果没有执行权限执行下面命令
[root@k8s-master01 42-velero]# chmod +x /usr/local/bin/velero

查看版本号：

[root@k8s-master01 42-velero]# velero version
Client:
	Version: v1.16.2
	Git commit: a60808256d36a77a42e1ebc160ee8117477a83fa
<error getting server version: no matches for kind "ServerStatusRequest" in version "velero.io/v1">

准备一个认证文件，给 Velero 提供访问 MinIO（对象存储）的身份认证凭据。

# velero在上传下载备份数据时用
cat > user-minio << EOF
[default]
aws_access_key_id=admin
aws_secret_access_key=asdqwe123@
EOF

# [default] 是必填的固定字段
# admin 和 asdqwe123@ 只是示例，必须改成你自己实际在 MinIO 里创建的 Access Key 和 Secret Key

3.3Velero服务端安装

velero install \
--provider aws \
--plugins registry.cn-beijing.aliyuncs.com/k8s-liujunwei/velero-plugin-for-aws:v1.12.2 \
--image registry.cn-beijing.aliyuncs.com/k8s-liujunwei/velero:v1.16.2 \
--bucket velerobackup \
--secret-file ./user-minio \
--use-volume-snapshots=false \
--backup-location-config region=minio,s3ForcePathStyle="true",s3Url=http://192.168.0.89:9000 \
--namespace velero

参数	含义	如何根据实际情况修改
`--provider aws`	指定使用 AWS 插件（因为 MinIO 兼容 S3）	固定用 `aws` 即可
`--plugins`	指定插件镜像地址和版本	必须改成具体版本，推荐 `velero/velero-plugin-for-aws:v1.13.0` 或你私有仓库对应版本
`--image`	指定 Velero 服务端镜像	必须改成具体版本，推荐 `velero/velero:v1.17.1` 或私有仓库版本
`--bucket`	MinIO 中存放备份的桶名	改成你实际创建的桶名（课程中是 `velerobackup`）
`--secret-file`	凭据文件路径	指向你创建的 `user-minio` 文件
`--use-volume-snapshots=false`	禁用卷快照功能	如果你的存储支持 CSI 快照，可改为 `true` 并额外配置；纯 MinIO 文件系统备份时保持 `false`
`--backup-location-config`	备份存储位置详细配置	region=minio：随便填一个值即可（MinIO 不校验 region） s3ForcePathStyle=”true”：必须开启。MinIO 默认使用 path-style 访问，不开启会导致上传成功但下载失败 s3Url=http://192.168.0.89:9000：MinIO 的访问地址（集群内用 Service 名，集群外用 IP/域名）
`--namespace`	安装到哪个命名空间	默认 `velero`，生产建议保持或按公司规范修改

安装后提示如下：

Secret/cloud-credentials: attempting to create resource client
Secret/cloud-credentials: created
BackupStorageLocation/default: attempting to create resource
BackupStorageLocation/default: attempting to create resource client
BackupStorageLocation/default: created
Deployment/velero: attempting to create resource
Deployment/velero: attempting to create resource client
Deployment/velero: created
Velero is installed! ⛵ Use 'kubectl logs deployment/velero -n velero' to view the status.

查看服务状态：

[root@k8s-master01 42-velero]# kubectl get po -n velero
NAME                     READY   STATUS            RESTARTS   AGE
velero-75865ccf9-558hr   0/1     PodInitializing   0          27s
[root@k8s-master01 42-velero]# kubectl get po -n velero
NAME                     READY   STATUS    RESTARTS   AGE
velero-75865ccf9-558hr   1/1     Running   0          98s

# BackupStorageLocation状态是Available可用的就没问题
[root@k8s-master01 42-velero]# kubectl get  BackupStorageLocation -n velero
NAME      PHASE       LAST VALIDATED   AGE     DEFAULT
default   Available   42s              2m21s   true

BackupStorageLocation状态是Available就可以正常备份集群了！

3.4配置velero的tab补全功能

先确认自己的 Shell：

1	echo $SHELL

输出 /bin/bash → 用 Bash 方式
输出 /bin/zsh → 用 Zsh 方式

bash补全：

1
2
3

# 推荐方式（写入当前用户配置）
echo 'source <(velero completion bash)' >> ~/.bashrc
source ~/.bashrc

然后重新打开终端，或执行 source ~/.bashrc。

Zsh 补全：

1 2	# Zsh echo 'source <(velero completion zsh)' >> ~/.zshrc && source ~/.zshrc

重新打开终端，或执行 source ~/.zshrc。

4.Velero初体验

4.1备份整个集群：

velero backup create test-backup
# velero 主命令，Velero CLI 工具的入口，用于管理 Kubernetes 集群的备份与恢复
# backup 子命令组，指定操作对象为"备份"资源（其他还有 restore、schedule、plugin 等）
# create 动作，创建一个新的备份任务
# test-backup 备份的名称，你可以自定义任意合法字符串。后续查询、恢复、删除该备份时都用这个名字引用它
# 运行后，Velero 会：
# 在 Velero 命名空间中创建一个名为 test-backup 的 Backup CRD 资源
# 默认备份当前集群中所有命名空间的所有资源 
# 将备份数据存储到之前搭建的 MinIO存储桶中

1
2
3

[root@k8s-master01 42-velero]# velero backup create test-backup
Backup request "test-backup" submitted successfully.
Run `velero backup describe test-backup` or `velero backup logs test-backup` for more details.

velero backup create test-backup \
  --include-namespaces=prod,staging      # 只备份指定命名空间
  --exclude-namespaces=kube-system       # 排除某些命名空间
  --include-resources=deployments,services  # 只备份指定资源类型
  --selector app=nginx                   # 按标签选择器过滤
  --ttl 720h                             # 备份保留时间（默认30天）
  --wait                                 # 等待备份完成再返回（默认异步）

查看备份进度：

1
2
3

[root@k8s-master01 42-velero]# velero backup get
NAME          STATUS      ERRORS   WARNINGS   CREATED                         EXPIRES   STORAGE LOCATION   SELECTOR
test-backup   Completed   0        2          2026-09-07 21:11:31 +0800 CST   29d       default            <none>

列名	含义	你示例中的值解释
NAME	备份的名称	`test-backup`：你创建备份时指定的名字
STATUS	备份当前状态	`Completed`：备份已成功完成
ERRORS	备份过程中出现的错误数量	`0`：没有错误
WARNINGS	备份过程中出现的警告数量	`2`：有 2 个警告（不影响整体成功，但建议查看详情）
CREATED	备份创建的时间	`2026-09-07 21:11:31 +0800 CST`
EXPIRES	备份还剩多久过期（根据 TTL 计算）	`29d`：还剩约 29 天过期（默认 TTL 通常是 30 天）
STORAGE LOCATION	备份存储到的 BackupStorageLocation 名称	`default`：使用默认的存储位置（指向你的 MinIO）
SELECTOR	创建备份时使用的标签选择器	`<none>`：没有使用标签过滤，备份了所有匹配的资源

STATUS 常见值：

New：刚创建，还没开始处理
InProgress：正在备份中
Completed：成功完成
Failed：备份失败
PartiallyFailed：部分失败

如果通过velero backup get查看备份进度时，提示有WARNINGS状态的，可以使用以下命令查询：

# 只看警告
velero backup logs test-backup | grep -i "level=warning"

# 或者更宽松一点（包含 warning / warn）
velero backup logs test-backup | grep -iE "warning|warn"

在minio的web端查看：

也可以通过 kubectl 查看备份详情：

[root@k8s-master01 42-velero]# kubectl get backup -n velero test-backup -oyaml
apiVersion: velero.io/v1
kind: Backup
metadata:
  annotations:
    velero.io/resource-timeout: 10m0s
    velero.io/source-cluster-k8s-gitversion: v1.31.4
    velero.io/source-cluster-k8s-major-version: "1"
    velero.io/source-cluster-k8s-minor-version: "31"
  creationTimestamp: "2026-09-07T13:11:31Z"
  generation: 11
  labels:
    velero.io/storage-location: default
  name: test-backup
  namespace: velero
  resourceVersion: "93933730"
  uid: f1341226-6eea-4dd3-8cd7-80696a80b29d
spec:
  csiSnapshotTimeout: 10m0s
  defaultVolumesToFsBackup: false
  hooks: {}
  includedNamespaces:
  - '*'
  itemOperationTimeout: 4h0m0s
  metadata: {}
  snapshotMoveData: false
  storageLocation: default
  ttl: 720h0m0s
status:
  completionTimestamp: "2026-09-07T13:11:42Z"
  expiration: "2026-10-07T13:11:31Z"
  formatVersion: 1.1.0
  hookStatus: {}
  phase: Completed
  progress:
    itemsBackedUp: 1217
    totalItems: 1217
  startTimestamp: "2026-09-07T13:11:31Z"
  version: 1
  warnings: 2

4.2删除krm命名空间的资源

模拟误删除，然后利用备份恢复资源

删除krm命名空间的资源：

# krm空间下的资源
[root@k8s-master01 42-velero]# kubectl get all -n krm
NAME                                READY   STATUS    RESTARTS       AGE
pod/krm-backend-f4f5c95f9-zdxmw     1/1     Running   148 (8h ago)   631d
pod/krm-frontend-856b4fb57b-6t77z   1/1     Running   2 (8h ago)     2d5h

NAME                   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
service/krm-backend    ClusterIP   10.96.252.180   <none>        8080/TCP       631d
service/krm-frontend   NodePort    10.96.17.251    <none>        80:31740/TCP   631d

NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/krm-backend    1/1     1            1           631d
deployment.apps/krm-frontend   1/1     1            1           631d

NAME                                      DESIRED   CURRENT   READY   AGE
replicaset.apps/krm-backend-f4f5c95f9     1         1         1       631d
replicaset.apps/krm-frontend-856b4fb57b   1         1         1       631d

# 删除整个命名空间的资源，包括krm命名空间
# Kubernetes 会自动级联删除该命名空间下的所有资源（Deployment、Service、ConfigMap、PVC、Pod 等）
# 命名空间本身也会被删除
[root@k8s-master01 42-velero]# kubectl delete namespace krm 
namespace "krm" deleted

4.3利用备份恢复krm空间资源

使用 Velero 恢复数据：

# 这里只还原了krm一个命名空间，如果要还原多个使用,分割
velero restore create test-restore --from-backup test-backup --include-namespaces krm
 
# 参数解读 
# velero 主命令	Velero CLI 工具的入口
# restore 子命令组	指定操作对象为"恢复"资源（对应 `backup`、`schedule` 等）
# create 动作	创建一个新的恢复任务
# test-restore 位置参数（NAME）	**本次恢复任务的名称**，自定义字符串。后续查询恢复进度、查看日志时通过这个名字引用它
# --from-backup test-backup 标志参数	指定**数据来源**，即从名为 `test-backup` 的已有备份中进行恢复。该备份必须已存在且状态为 `Completed`
# --include-namespaces test 过滤参数	指定**只恢复**名为 `krm` 的命名空间中的资源。即使 `test-backup` 备份了整个集群的所有命名空间，执行此参数后也只会把 `test` 命名空间里的内容还原出来

1
2
3

[root@k8s-master01 42-velero]# velero restore create test-restore --from-backup test-backup --include-namespaces krm
Restore request "test-restore" submitted successfully.
Run `velero restore describe test-restore` or `velero restore logs test-restore` for more details.

查看恢复状态：

1 2	#上述状态中有两个警告，执行下面命令查看，可以将返回信息提供给大模型分析错误是否有影响 velero restore logs test-restore \| grep -i "level=warning"

恢复完整后kem资源已经全部创建：

[root@k8s-master01 42-velero]# kubectl get all -n krm
NAME                                READY   STATUS    RESTARTS   AGE
pod/krm-backend-f4f5c95f9-zdxmw     1/1     Running   0          29s
pod/krm-frontend-856b4fb57b-6t77z   1/1     Running   0          29s

NAME                   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
service/krm-backend    ClusterIP   10.96.87.193    <none>        8080/TCP       29s
service/krm-frontend   NodePort    10.96.239.125   <none>        80:31848/TCP   29s

NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/krm-backend    1/1     1            1           29s
deployment.apps/krm-frontend   1/1     1            1           29s

NAME                                      DESIRED   CURRENT   READY   AGE
replicaset.apps/krm-backend-f4f5c95f9     1         1         1       29s
replicaset.apps/krm-frontend-856b4fb57b   1         1         1       29s

5.Velero企业实战

5.1周期性备份

公司的集群推荐每天备份一次，可以在每天凌晨执行备份任务：

# 创建一个周期性备份任务，创建一个名为 day-cluster-backup 的定时备份任务，每天执行一次，备份除velero、kube-system 之外的 Namespace，每份备份保留 30 天。
velero schedule create day-cluster-backup \
  --schedule="0 13 * * *" \
  --include-namespaces="*" \
  --exclude-namespaces="velero,kube-system" \
  --ttl=720h0m0s
  
#cron 使用的是 UTC 时间，请根据你的时区换算。
# 如果希望明确使用北京时间，建议写： --schedule="CRON_TZ=Asia/Shanghai 0 2 * * *"
velero schedule create day-cluster-backup \
  --schedule="CRON_TZ=Asia/Shanghai 15 14 * * *" \
  --include-namespaces="*" \
  --exclude-namespaces="velero,kube-system" \
  --ttl=720h0m0s

参数	作用	你当前的值	如何根据实际情况配置
`velero schedule create`	创建一个定时备份任务	固定写法	不需要修改
`day-cluster-backup`	Schedule 名称	每日集群备份	自定义，见名知意即可
`--schedule`#–schedule=”CRON_TZ=Asia/Shanghai 0 2 * * *”	定义备份执行时间，使用 Cron 表达式	`分时日月周`	根据自己业务低峰期设置
`--include-namespaces`	指定需要备份的 Namespace	`*`，表示全部	如果只备份生产环境，可写 `prod,logging,mysql`
`--exclude-namespaces`	从备份范围中排除 Namespace	`velero,kube-system`	按恢复策略决定哪些系统 Namespace 不需要备份
`--ttl`	每份 Backup 的保留时间	`720h0m0s` = 30 天	根据恢复周期和 MinIO 容量调整

这条 Schedule 主要决定“什么时候备份、备份哪些资源、保留多久”，并不能单独保证 PVC 中的真实数据已经备份。 PVC 数据还要结合 CSI Snapshot 或 File System Backup/node-agent 等机制。

# 查看所有计划
velero schedule get

# 查看计划详情
velero schedule describe day-cluster-backup

# 手动触发一次该计划的备份（测试用）
velero backup create --from-schedule day-cluster-backup

# 查看备份列表
velero backup get

查看备份任务：

# 查看所有的备份计划 
velero schedule get
 
# 查看备份 
velero backup get

暂停备份任务：

1
2
3

# day-cluster-backup是备份任务的名字
[root@k8s-master01 ~]# velero schedule pause day-cluster-backup
Schedule day-cluster-backup paused successfully

通过velero schedule get指令查看备份任务，PAUSED字段是true表示该任务已经暂停

恢复备份任务：

1 2	[root@k8s-master01 ~]# velero schedule unpause day-cluster-backup Schedule day-cluster-backup unpaused successfully

基于 schedule 立即创建备份任务：

# 这条命令的作用可以一句话理解：不等 Schedule 到预定时间，而是立刻按照这个 Schedule 已经定义好的备份规则，手动创建一次 Backup。
# 官方说明也是这样：--from-schedule 会立即基于指定 Schedule 的模板创建一个新的 Backup，而且不会影响原来的定时计划，后续到了原定时间仍然会正常再执行一次

velero backup create --from-schedule day-cluster-backup

应用场景：
①：创建Schedule后马上测试验证备份是否正常，不用等到备份任务指定的时间
②：重大变更或者升级前做一次备份，原本每天凌晨 2 点备份一次。但现在下午 4 点要升级，凌晨 2 点的备份已经过去 14 个小时，此时可以基于备份任务做一次手动备份。

5.2保留NodePort端口号

Velero 恢复数据时，Service 的 NodePort 端口会重新分配，如果用到了 Service 的 NodePort 会造成一些故障，此时可以使用 --preserve-nodeports 参数保留原端口（生产环境建议每次还原都使用该端口）。

# 通过krm命名空间演示
[root@k8s-master01 ~]# kubectl get svc -n krm
NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
krm-backend    ClusterIP   10.96.87.193    <none>        8080/TCP       19h
krm-frontend   NodePort    10.96.239.125   <none>        80:31848/TCP   19h

#可以看到krm空间有NodePort类型的Service，端口号是31848

创建备份：

1	[root@k8s-master01 ~]# velero backup create krm-backup --include-namespaces=krm --wait

查看备份：

1	velero backup get

接下来删除krm空间中的资源：

# 直接删除命名空间会把该空间下的所有资源一并删除
[root@k8s-master01 ~]# kubectl delete ns krm
namespace "krm" deleted

[root@k8s-master01 ~]# kubectl get ns krm
Error from server (NotFound): namespaces "krm" not found

利用krm-backup备份还原，并指定--preserve-nodeports参数，还原成功后检查Service的NodePort端口号：

[root@k8s-master01 ~]# velero restore create krm-restore --from-backup krm-backup --preserve-nodeports
Restore request "krm-restore" submitted successfully.
Run `velero restore describe krm-restore` or `velero restore logs krm-restore` for more details.

#查看NodePort端口，之前的端口是31848
[root@k8s-master01 ~]# kubectl get svc -n krm
NAME           TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
krm-backend    ClusterIP   10.96.44.159   <none>        8080/TCP       74s
krm-frontend   NodePort    10.96.8.148    <none>        80:31848/TCP   74s
# 还原后还是原来的端口，如果在这个过程中，NodePort端口被占用了就需要人工手动介入了，是修改占用的svc还是还原时随机分配，根据实际情况决定。

5.3误删资源如何恢复

背景：假设由于误操作不小心删除了pord空间中名字是auth的deployment服务，利用备份进行恢复。

# 假设最新一次的备份是 day-cluster-backup-20260908072559
# 恢复指令是
velero restore create restore-pord-auth-deploy \
--from-backup day-cluster-backup-20260908072559 \
--include-namespaces=prod \
--include-resources=deployments

参数	含义
`restore create restore-pord-auth-deploy`	创建一个名为 `restore-pord-auth-deploy` 的还原任务
`--from-backup day-cluster-backup-20260908072559`	从`day-cluster-backup-20260908072559`这个备份还原
`--include-namespaces=prod`	只还原 `prod` 命名空间的资源
`--include-resources=deployments`	只还原 Deployment 资源，注意要是复数

Velero 还原时默认是非破坏性（non-destructive）的，也就是说它不会覆盖已经有的资源：

情况	行为
资源已经存在（其他没删的 Deployment）	跳过，不做任何修改
资源不存在（被删掉的 system Deployment）	创建，把它还原回来

如果要恢复多个资源参考下列写法：

velero restore create restore-pord-auth-deploy \
  --from-backup day-cluster-backup-20260908072559 \
  --include-namespaces=prod \
  --include-resources=deployments,services \
  --preserve-nodeports
  
# restore-pord-auth-deploy是还原任务的名字
# 从day-cluster-backup-20260908072559备份进行还原
# --include-namespaces=prod指定要还原的命名空间
# --include-resources=deployments,services 要还原的资源，多个用,分割
# --preserve-nodeports 如果要保留原来的NodePort需要加该参数

5.4重大上线变更提前备份

如果要对一个项目进行非常大的更新，建议在变更之前提前对某个项目进行全量备份，如果变更失败，可以一键回滚资源。

# ==================== 变更前 ====================
# 1. 做备份
BACKUP_NAME="pre-change-$(date +%Y%m%d-%H%M%S)"
velero backup create $BACKUP_NAME \
  --include-namespaces=test \
  --include-cluster-resources=true \
  --ttl=168h0m0s \
  --wait

# 2. 验证备份
velero backup describe $BACKUP_NAME
echo "备份名称：$BACKUP_NAME  ← 请记录这个名字"

# ==================== 变更失败后 ====================
# 3. 执行恢复
velero restore create rollback-$(date +%Y%m%d-%H%M%S) \
  --from-backup $BACKUP_NAME \
  --include-namespaces=test \
  --preserve-nodeports \
  --wait

# 4. 检查恢复结果
velero restore get
kubectl get all -n test

–include-cluster-resources=true 的含义：这个参数用来控制是否备份（或还原）集群级别（Cluster-scoped）资源。

Kubernetes 资源分成两类:

类型	说明	常见例子
Namespace-scoped	属于某个命名空间	Deployment、Service、Pod、ConfigMap、Secret、PVC
Cluster-scoped	不属于任何命名空间，全局生效	PersistentVolume (PV)、StorageClass、ClusterRole、ClusterRoleBinding、CRD、Namespace、Node

5.5多集群备份

针对不同的集群备份时，不建议备份到同一个位置，可以采用如下方式进行隔离：

不同的 Minio
同一个 Minio，不同的 Bucket（推荐）
同一个 Bucket，不同的目录(不推荐)

velero客户端和服务端安装参考上述笔记即可，备份操作也参考上述笔记。

5.6跨集群恢复/数据迁移

Velero 支持把数据恢复到不同的集群，通常用于创建新环境、迁移和数据恢复，只需要能看到备份文件即可，例如A集群中的资源迁移到B集群。

核心思路很简单：

把A集群中的备份文件迁移至B集群的minio中，让B集群中的velero能读取到A集群的备份文件即可，如果两个集群用的是同一个minio服务，那么只需要将A集群的备份拷贝一份到B集群的Bucket中即可

minio中的数据迁移有两种方式可以参考：

方式一：通过minio的web端下载上传数据，找到自己的备份，先将文件下载到本地，然后在上传到B集群备份所用的minio中，提前在B集群中配置好Velero的客户端和服务端，以及minio的bucket，假设B集群用的bucket名字是bj-k8s-velero，那么文件上传的问位置是bj-k8s-velero/backups/

方式二：通过mc命令拷贝

# 当前的备份路径是：local/velerobackup/backups/day-cluster-backup-20260908061504/


# 源 MinIO（你现在已经有的）
mc alias set source http://源MinIO地址:9000 ACCESS_KEY SECRET_KEY

# 目标 MinIO
mc alias set target http://目标MinIO地址:9000 ACCESS_KEY SECRET_KEY

拷贝整个备份目录：

# 复制单个备份
mc cp --recursive \
  source/velerobackup/backups/day-cluster-backup-20260908061504 \
  target/bj-k8s-velero/backups/

然后在用velero恢复即可。