给对象存储做冷热分层：用 OBS 生命周期规则与 Python SDK 实现低成本备份

做备份最容易犯的错误，不是没备份，而是所有数据都用同一档存储、同一个保留策略。热数据、温数据、冷数据混在一个桶里按标准存储计费，时间一长，账单里有一大半都是几乎不会再被读取的历史文件。这篇文章记录我用华为云 OBS 生命周期规则加 Python SDK，给备份数据做冷热分层的完整做法。

一、先想清楚：数据有多“热”

动手之前，先按访问频率把数据分成三类：

• 热数据：最近 30 天内经常被读取，比如正在进行的项目备份、最近的日志；
• 温数据：30 到 90 天偶尔需要，比如上季度的报表、已归档的项目资料；
• 冷数据：90 天以上几乎不再读取，只为合规或灾备保留，比如年度审计材料。

分层的意义在于，存储单价和取回成本是反向的：越“冷”的存储越便宜，但取回越慢、越贵。所以规则不能拍脑袋定，要结合真实的访问记录。

二、用生命周期规则让分层自动发生

OBS 的生命周期规则可以按对象名前缀和创建时间，自动做三件事：转换存储类别、过期删除、清理历史版本。我的做法是按前缀划分：

• backup/daily/：每天增量备份，保留 30 天后转低频访问存储，90 天后转归档存储，180 天后删除；
• backup/monthly/：每月全量备份，直接保留在低频访问存储，365 天后转归档存储；
• logs/：应用日志只保留 30 天，到期直接过期删除，不进归档。

在控制台创建规则时有几个要点：规则状态必须设为启用；同一条规则里转换和删除可以叠加；如果桶开启了版本控制，还要单独给非当前版本配规则，否则历史版本会一直按标准存储计费。

三、用 Python SDK 把备份和规则都写成代码

控制台点几下能完成的事，换一台机器、换一个桶又要重做一遍，所以我把关键步骤写成了脚本，备份上传和生命周期配置都用代码管起来。

import os
from obs import ObsClient

# 密钥只从环境变量读取，不要写进代码或提交到仓库
AK = os.environ["OBS_AK"]
SK = os.environ["OBS_SK"]
SERVER = "https://obs.cn-north-4.myhuaweicloud.com"
BUCKET = "my-backup-bucket"

client = ObsClient(access_key_id=AK, secret_access_key=SK, server=SERVER)

def upload_backup(local_path, object_key):
    resp = client.putFile(BUCKET, object_key, local_path)
    if resp.status < 300:
        print(f"上传成功：{object_key}")
    else:
        print(f"上传失败：{resp.errorMessage}")

def set_lifecycle():
    rule = {
        "Rules": [{
            "ID": "daily-backup-tiering",
            "Prefix": "backup/daily/",
            "Status": "Enabled",
            "Transitions": [
                {"Days": 30, "StorageClass": "WARM"},
                {"Days": 90, "StorageClass": "COLD"},
            ],
            "Expiration": {"Days": 180},
            "NoncurrentVersionTransitions": [
                {"NoncurrentDays": 30, "StorageClass": "WARM"},
            ],
            "NoncurrentVersionExpiration": {"NoncurrentDays": 90},
        }]
    }
    resp = client.setBucketLifecycleConfiguration(BUCKET, rule)
    print("生命周期配置成功" if resp.status < 300 else resp.errorMessage)

if __name__ == "__main__":
    upload_backup("/data/backup-20261110.tar.gz", "backup/daily/backup-20261110.tar.gz")
    set_lifecycle()
    client.close()

把这个脚本放进定时任务，每天凌晨跑一次，上传当天的备份；生命周期规则只需要配一次，之后 OBS 会按天自动执行。

四、三个真实踩过的坑

第一，归档存储的对象不能直接下载。取回之前要先发起恢复请求，等恢复完成、并在恢复有效期内才能下载，习惯了标准存储的随取随用，第一次很容易在这里卡住。

第二，生命周期按对象创建时间加天数计算，不是按最后访问时间。刚上传就被反复读取的文件，不会因为“经常被访问”就延后转冷；真正的高频文件要单独放在不设转冷规则的前缀下。

第三，删除开了版本控制的桶之前，要先清空所有版本。只删当前版本、留下历史版本，桶删不掉，费用也还在跑。

五、效果和下一步

按这个策略跑了一个月，备份类支出的大头从标准存储挪到了低频和归档，整体存储费用下降了约四成，取回次数几乎没有变化，因为需要取回的基本都是 30 天内的热数据。

下一步我打算再做两件事：一是给不同前缀的取回次数做月度统计，验证分层阈值定得是否合理；二是把脚本接入告警，上传失败或规则配置失败时第一时间收到通知，而不是等到需要恢复时才发现备份断了。

冷热分层的核心从来不是省钱本身，而是让每一份数据的存储成本配得上它的访问价值。规则定一次、代码跑起来，后面基本不用再操心，这正是自动化的意义所在。