Backup

当私有维护的服务器变多之后，以及考虑到服务器厂商的不稳定性（例如跑路），保障服务器上起码有一个备份策略是非常有必要的。 存储服务搭建 之前我的做法是通过 tailscale 把服务器上的关键文件夹打包 scp 回家庭服务器上，但是这种得控制权限（设置 ssh 相关的一些参数，后面如果有机会的话可以再分享)),以及每个服务器都得配置，也是挺麻烦的。而且我也担心这样一个服务器暴露在公网上面万一被人爆破了就什么数据都丢了（例如我其中某一台服务器被黑了那么我家庭环境下所有东西都没了）。因此借这次机会尝试一下别的方案，拍脑袋想了一个： 路由是通过端口转发来实现外网到内网端口的映射的。 Minio 是一个自建的 S3 服务，兼容 AWS S3 协议，所以市场上大部分语言的大部分 SDK 都可以直接请求，那么备份工具只要是支持 S3 的也就可以直接配置使用了。因为我有自己的 NAS 和 公网 IP，因此我的服务放在了家里，且因为我的 NAS 本身为了数据的冗余就做了两块盘的镜像，因此我只需要单实例的 Minio 容器即可，不用考虑冗余。 参考 https://min.io/docs/minio/container/index.html 部署即可 Docker compose 如下 version: "3.8" services: minio: image: quay.io/minio/minio container_name: minio networks: - my_network volumes: - /mnt/data/Minio:/data restart: unless-stopped command: - server - /data - --console-address - ":9001" env_file: - ./data/envs/minio.env caddy: image: iarekylew00t/caddy-cloudflare restart: unless-stopped container_name: caddy extra_hosts: - "host....

因为云计算的快速发展，K8s 早已经成为了现代服务的核心。而作为 K8s 的核心，etcd 集群自然有着至关重要的位置。如果使用的是云厂商托管的 K8s 那么相对简单一些，K8s 本身的升级和维护基本上云厂商都会负责，无需投入太多精力，只要定期安排好时间配合厂商做一下升级即可。但是如果是自建的 K8s 集群呢？ 做好 etcd 集群的备份和恢复方案是非常关键的，在真正的故障的时候是能起到决定性的作用。 就我们的经验而言，之前发生的几次集群故障都是出自于 ETCD 集群的故障，但我们没有做好足够的备份和恢复方案，因此每当发生这样的问题的时候最后的结果总是重新安装整个集群，然后就是漫长而枯燥而痛苦的集群恢复。耗费大量的人力和物力，也会造成非常恶劣的影响，从而就流失用户了。 我们线上集群是通过 Kubespray 安装的，基于 release-2.23 虽然 kubespray 在每次操作的时候都会备份当前的 etcd： https://github.com/kubernetes-sigs/kubespray/blob/master/roles/etcd/handlers/backup.yml 但我们并不能用 kubespray 的方式来备份，kubespary 的操作原则是非必要尽量不做操作。额外一提，kubepsray 也自带了 recover etcd 的方案： https://github.com/kubernetes-sigs/kubespray/blob/master/docs/recover-control-plane.md 真的遇到 control-plane 或者 etcd 节点故障的时候可以按照说明书进行操作。 脚本 考虑到备份的稳定性以及目前集群中并没有做一个多备份的存储工具，暂时选择直接在其中一个 etcd 的物理机上进行脚本备份，并上传到 Hetzner 的 StorageBox 中。 #!/usr/bin/env bash # # Etcd backup set -ex # kubespray 安装的 etcd 集群默认会把相关的配置放在 /etc/etcd.env 文件中 ETCD_ENV_FILE=/etc/etcd.env BACKUP_DIR=/data/scripts/etcd_backup/ # 保留 21 以内的所有备份 DAYS_RETAIN=21 DT=$(date +%Y%m%d....