支持OSS托管加密

2026-08-16 22:38:31 +08:00
parent 7b7d23c743
commit eb06ec3c5f
6 changed files with 20 additions and 19 deletions
@@ -40,7 +40,6 @@ BACKUP_DIR
 BACKUP_RESTORE_DIR
 BACKUP_OSS_URI
 BACKUP_PASSPHRASE
-BACKUP_KMS_KEY_ID
 BACKUP_MYSQL_PASSWORD
 ```

@@ -72,11 +71,11 @@ RAM 凭证只授予该 Bucket 的列举、读取、写入对象权限，不要

 ### 数据库在线备份与时间点恢复

-生产 MySQL 开启了 `ROW` 格式 binlog 和崩溃安全刷盘。备份期间业务持续读写：每日用 XtraBackup 做物理全量备份，每分钟轮转并归档已关闭的 binlog。备份对象先做客户端加密，再强制以 OSS KMS 加密上传；远端仅在 payload、checksum 和 manifest 都上传成功后写入 `complete.env`。
+生产 MySQL 开启了 `ROW` 格式 binlog 和崩溃安全刷盘。备份期间业务持续读写：每日用 XtraBackup 做物理全量备份，每分钟轮转并归档已关闭的 binlog。备份对象先做客户端加密，再由 Bucket 的服务器端加密保护；远端仅在 payload、checksum 和 manifest 都上传成功后写入 `complete.env`。

 部署脚本会创建或更新 `BACKUP_MYSQL_USER`，该用户只有 XtraBackup 所需的全局备份权限和业务库只读权限，不开放远程 root。

-备份 Bucket 必须独立于业务 Bucket，备份 RAM 身份仅授予该 Bucket 的列举、读写对象及指定 KMS Key 的加解密权限。推荐 Bucket 开启版本控制和不可变保留策略。
+备份 Bucket 必须独立于业务 Bucket，开启“OSS 完全托管”服务器端加密和版本控制。备份 RAM 身份仅授予该 Bucket 的列举、读写对象权限；若填写 `BACKUP_KMS_KEY_ID`，再授予该 Key 的加解密权限。推荐配置不可变保留策略。

 部署机需安装 `ossutil`、`openssl` 和 `flock`，并使用与 cron 相同的业务用户完成 `ossutil` 凭证配置；部署脚本会在启动服务前检查这些依赖。