解读

面试官想确认两点：

1. 你是否理解 Cloud SQL 内部两种备份的技术本质；
2. 能否把技术差异翻译成可落地的保留策略设计，并兼顾国内合规（等保、关保、数据出境）与成本。
   回答时先分层：技术目的 → 生命周期 → 恢复场景 → 成本/合规，再给出可量化的保留天数建议，体现“能干活”。

知识点

1. 全量备份（Backup on Demand / Automated Backup）

   • 触发方式：每日自动窗口或手动触发，整实例一致性快照。
   • 存储位置：同区域多可用区冗余，可选跨区域副本满足等保 3 级异地容灾。
   • 保留策略：Cloud SQL 默认7 天，上限365 天；国内金融客户通常30 天起步，核心系统90 天。
   • 恢复粒度：只能整实例按快照点恢复，无法细化到秒级。

2. 事务日志备份（Point-in-Time Recovery，PITR）

   • 触发方式：全量备份之后，连续归档 WAL/SQL Server Transaction Log。
   • 存储位置：与全量备份共用 Cloud Storage 桶，但文件更碎、更小，写入频次高。
   • 保留策略：Cloud SQL 默认比全量备份多 1 天（即 8 天），上限 35 天；国内互联网高并发场景常设7 天，金融核心因监管要求21 天。
   • 恢复粒度：可精确到秒级，用于“误删表”“批量更新错数据”等逻辑错误回滚。

3. 保留策略差异总结

   • 时间长度：全量可 365 天，日志最多 35 天；日志永远 ≤ 全量保留期 +1。
   • 成本权重：日志量随写入负载线性增长，SSD 高并发实例 7 天日志 ≈ 1 次全量大小；全量快照用差分存储，后续增量费用低。
   • 合规闭环：等保 2.0 要求至少 6 个月日志可被审计，但 Cloud SQL 的 PITR 日志最长 35 天，因此必须额外开启 Cloud Logging 或导出到自建 Coldline 桶，否则现场会被测评机构开不符合项。

答案

“在 Cloud SQL 中，全量备份与事务日志备份的保留策略差异体现在最大可保留天数、成本曲线与合规职责三方面。
第一，全量备份最长可设 365 天，而事务日志备份上限仅 35 天，且必须依赖最近一份全量快照才能解析，因此日志保留期永远**≤ 全量保留期 +1 天**。
第二，日志备份按写入量计费，高并发业务 7 天日志就可能等于一次全量容量，成本敏感型应用需把日志保留期压到 7 天以内；全量快照采用差分存储，后续增量费用更低，适合拉长保留期做季度级回溯。
第三，国内等保 2.0 和银保监会要求交易日志至少保存 6 个月，Cloud SQL 原生 PITR 无法满足，必须额外导出日志到自建 Coldline 存储桶，并配置IAM 细粒度权限与 KMS 加密，形成‘35 天内秒级恢复 + 6 个月冷日志审计’的两级策略，既满足监管又控制预算。”

拓展思考

1. 如果客户要求**“既能回溯 90 天，又能秒级恢复”，但预算有限，你会如何设计？
   思路：全量保留 35 天，每周再手动导出一次逻辑导出（gcloud sql export sql）到 Coldline，90 天后自动删除；同时把日志保留压到 5 天**，降低 WAL 存储费用。恢复时先用最近全量快照，再用逻辑导出补齐 35–90 天区间，牺牲部分 RTO 换取成本。

2. 跨区域双活场景下，主区域日志备份是否复制到灾备区域？
   Cloud SQL 的日志文件默认仅存主区域，灾备区域只复制全量快照；若需异地可秒级回溯，必须自建 Cloud Storage 跨区域复制规则，并验证网络出站费用与KMS 密钥区域权限，否则演练时会因“找不到日志”导致 RPO 超标。