生命周期概述

更新时间: 2025-08-01 15:26:39

随着时间的推移,存储在 OSS 中的数据访问热度通常会逐渐降低。若持续使用高成本的标准存储保存冷数据,或依赖人工清理大量日志、备份文件,既不经济,效率也低。生命周期管理功能允许您创建自动化规则,在文件满足特定条件(如创建超过30天)后,自动将其转换为成本更低的存储类型(如低频、归档),或直接删除,实现智能化、低成本的数据全生命周期管理。

工作原理

生命周期管理通过用户定义的规则,对存储空间(Bucket)内的文件(Object)进行自动化操作。生命周期规则创建后的24小时内,OSS会加载规则。规则加载完成后,OSS 会在固定的时间周期(通常是次日 UTC 时间 0点,即北京时间 8 点后)扫描并执行符合条件的规则。

一条生命周期规则主要由三部分构成:

  1. 控制对象: 定义规则对哪些文件生效,可基于文件前缀(Prefix)对象标签(Tag)、或文件大小(ObjectSize)来筛选目标文件。

    生命周期规则目前不支持通配符匹配、后缀匹配以及正则匹配。
  2. 执行动作: 定义对筛选出的文件做什么操作。主要包括:

    • 存储类型转换(Transition): 将文件转储到低频访问、归档、冷归档等更低成本的存储类型。

    • 过期删除(Expiration): 文件达到指定生命周期后将其删除。

    • 清理碎片(AbortMultipartUpload): 自动删除超过指定时间仍未合并的分片上传任务。

  3. 触发策略:定义对筛选出的文件基于什么条件触发:

    • 最后一次修改时间(Last-Modified-Time): 根据文件的最后修改时间为基准进行存储类型转换和删除,适用于日志、备份等生命周期明确的数据,可自动进行存储类型转换或删除以节省成本。

    • 最后一次访问时间(Last-Access-Time):启用访问跟踪功能后根据文件的最近访问时间智能切换存储类型,适合访问模式不确定的场景,如素材库。可在数据冷却时降级,访问时自动恢复。

可参考生命周期配置元素配置生命周期策略。

配置生命周期

自动清理过期的日志文件

服务器每天会生成大量日志并上传至指定目录。您可配置基于最后修改时间的生命周期规则,在达到指定天数后删除Bucket内的所有Object,释放存储空间、降低存储成本。

数据的冷热分层存储

对于访问频率不确定的数据(如网站图片、在线视频、文档等),建议启用访问跟踪功能,并使用最后一次访问时间的生命周期规则实现数据智能分层。系统将根据实际访问情况,自动将冷数据转入低频、归档或冷归档存储,实现智能分层与成本优化。

自动清理历史版本

开启版本控制后,针对数据的覆盖和删除操作将会以历史版本的形式保存下来。当Bucket累积了大量的历史版本或者过期删除标记时,可使用最后一次修改时间的生命周期规则结合版本控制降低存储成本,在文件达到指定时间后自动删除,从而减少存储成本并有效提升列举Object的性能。

自动清理上传时产生的碎片

在使用分片上传大文件过程中,若上传中断,系统会保留未合并的分片(Part),这些分片将持续计费。可配置生命周期规则自动清理超过指定时间的未完成分片,避免不必要的资源占用。

除上述场景外,如需实现更精细的数据管理策略,您可参考生命周期配置示例,根据业务需求组合不同规则,实现对 Bucket 中数据的精细化管理。

多条生命周期规则

为确保配置的多条生命周期规则按预期生效,需要理解两个核心机制:规则的执行优先级配置的覆盖机制

规则执行优先级

同一个Bucket可以配置多条生命周期规则,且规则之间互不影响。因此,同一个Object可能会命中多条规则,需根据所有规则的命中结果决定最终操作。

当多条规则同时匹配同一文件时,按以下优先级执行:删除 Object > 转为深度冷归档 > 转为冷归档 > 转为归档 > 转为低频访问 > 转为标准。

重要

删除操作始终优先于存储转换。建议将删除规则的时间设置得比转储规则更长,避免文件在转储完成前被删除。

执行示例

假设指定了以下两条生命周期规则,且两条规则均命中相同的Object。

  • 规则1:指定将最后一次修改时间超过365天的Object转为低频访问类型。

  • 规则2:指定将最后一次修改时间超过365天的Object删除。

执行结果:规则命中的Object将在距离其最后一次修改时间超过365天后删除。

配置的覆盖机制

在使用控制台时,无需关心配置覆盖问题。每次新增、修改规则时,控制台会自动读取当前配置并合并后提交,避免误操作导致原有规则丢失。但在使用 ossutil、SDK或直接调用 API 的方式配置生命周期规则时,需格外注意:每次调用 PutBucketLifecycle 都会完全覆盖当前 Bucket 的所有生命周期配置,若只提交新规则而未包含原有规则,将导致原有规则被删除并失效。

示例说明

如果您希望在已有规则的基础上新增一条规则,需按以下步骤操作:

  1. 获取 当前已生效的所有生命周期规则(例如规则1)

  2. 添加 新规则(例如规则2)

  3. 重新提交 包含全部规则(规则1 + 规则2)的完整配置

注意:如果仅提交包含新规则(规则2)的配置,而未包含原有规则(规则1),则规则1会被删除,不再生效。

应用于生产环境

为确保在生产环境中安全、高效地使用生命周期管理,建议:

  • 先测试,后部署: 强烈建议先在测试 Bucket 中创建规则,验证其行为完全符合预期后,再应用到生产环境的 Bucket。

  • 谨慎使用删除规则: 对配置了过期删除的规则,务必精确设置前缀,避免规则范围扩大导致重要数据被意外删除。

  • 开启版本控制作为保障: 对于关键业务数据,建议开启 Bucket 的版本控制功能。这样,即使当前版本文件被生命周期规则误删,仍有机会从历史版本中恢复数据。

  • 阶梯式转换避免额外费用: 在设计存储类型转换策略时,确保后一阶段的触发时间晚于前一阶段的触发时间与该存储类型最低存储时长之和,以避免提前转换带来的费用。

    • 错误示例: 标准存储 30天 -> 低频存储 40天 -> 归档存储。此配置会导致低频文件仅存储10天(< 30天)就被转走,从而产生费用。

    • 正确示例: 标准存储 30天 -> 低频存储 90天 -> 归档存储。(30天转为低频,再经过60天满足归档最低要求,共90天)。

计费说明

配置生命周期规则本身不收费。费用产生于规则被执行时以及执行后带来的存储状态变化。

  1. 请求费用:当生命周期规则执行存储类型转换、删除Object或删除Part操作时,系统会发起 Put类型请求调用,并按请求次数收取请求费用,计费规则可参考生命周期费用说明

    对于包含海量小文件的 Bucket,此费用可能较为显著,请在配置前进行评估。
  2. 存储费用:文件转换到新存储类型后,将按新类型的单价计费。

    重要

    低频、归档、冷归档等存储类型有最低存储时长要求(如低频为30天,归档为60天)。如果生命周期规则在文件存满最低时长之前就将其删除或再次转换,需要支付剩余天数的存储费用作为补偿。为避免产生转储或者删除产生的不足规定时长容量费用(条件),可参考如何避免产生存储不足规定时长容量费用?,确保满足其最低存储时长后再进行转储或者删除。

  3. 数据取回费用:生命周期规则本身不会产生数据取回费用。但文件被转换为低频、归档等类型后,在访问这些文件时,会产生相应的数据取回费用。

常见问题

基于最后一次修改时间和最后一次访问时间的生命周期规则有什么区别?

基于最后一次修改时间以及最后一次访问时间策略的区别说明如下:

策略

基于最后一次修改时间

基于最后一次访问时间

适用场景

适用于访问模式较固定或者可以准确预估访问模式的数据场景。

适用于访问模式不固定或者无法预估访问模式的数据场景。

是否支持删除Object

支持。

不支持。

Object删除后是否可以恢复

  • 未开启版本控制时,Object删除后无法恢复。

  • 版本控制,基于最后一次修改时间的生命周期规则删除当前版本Object可以恢复,删除历史版本Object不能恢复。

基于最后一次访问时间的策略不涉及Object删除后的恢复问题。

Object存储类型转换后是否可逆

不可逆。例如,将Object从标准存储类型转换为低频访问类型后,不能再自动转回标准存储类型。更多信息,请参见转换存储类型

当Object被转换为低频访问、归档、冷归档或者深度冷归档存储类型后,涉及最小计量空间、最短存储时长、数据取回费用等问题。更多信息,请参见转换存储类型

可逆。将Object从标准存储类型自动转换为低频访问类型时,您还可以在Object被访问时选择重新返回标准存储类型。

重要

Object被访问仅指通过GetObject接口访问Object,不包含其他接口。

该场景同样涉及最小计量空间、最短存储时长、数据取回费用等问题。更多信息,请参见基于最后一次访问时间的生命周期规则

为什么我设置的生命周期规则没有生效?

请按以下步骤排查:

  1. 生效时间: 规则是否已创建超过 24 小时?新规则需要时间加载。

  2. 前缀匹配: 规则中设置的前缀是否正确?例如,目录应为 logs/ 而非 logs

  3. 时间条件: 文件的最后修改/访问时间是否真的满足设置的天数条件?

  4. 功能前提: 如果使用基于“最后访问时间”的规则,是否已为 Bucket 开通了“访问跟踪”功能?

开启版本控制后,文件删除了,为什么存储空间没有减少?

因为开启版本控制后,删除操作只是创建了一个“删除标记(Delete Marker)”,原始文件变成了“历史版本”并继续占用存储空间。必须额外创建一条针对“历史版本”的生命周期规则来清理它们。

删除规则后已转换的文件会恢复吗?

不会。删除规则不会影响已经执行的操作结果,已转换的文件需要手动恢复到原存储类型。

开启版本控制后删除文件为什么还占用空间?

开启版本控制后,删除操作会产生删除标记,原文件成为历史版本继续占用空间。需要配置历史版本删除规则。

报错Set bucket lifecycle error, InvalidArgument, Days in the Transition action for StorageClass Archive must be more than the Transition action for StorageClass IA怎么办?

出现该报错是因为不同存储类型的转储时间不满足要求。Bucket配置的转换周期必须满足:低频访问 < 归档 < 冷归档 < 深度冷归档。

OSS生命周期功能是否可以针对文件后缀匹配进行数据沉降或删除动作?

当前生命周期功能不直接支持基于文件后缀(如 .png)的匹配。但可通过以下两种方式实现类似的数据沉降或删除操作:

方法一:存储至特定前缀目录

建议在业务侧将特定后缀的文件(如 .png 文件)统一存储在指定的前缀目录中(例如 images/)。配置生命周期规则时,可将匹配前缀设置为 images/,并制定相应的转换或删除策略,从而实现对该类文件的生命周期管理。

方法二:结合标签功能

可为指定后缀的文件(如 .png 文件)统一打上固定标签(例如 image:png)。配置生命周期规则时,启用标签匹配功能,并针对包含该标签的 Object 应用相应策略。详细可参考对象标签

生命周期规则是否作用于Bucket内已有的存量Object?

生命周期规则同时作用于配置前的存量Object和配置后新上传Object。例如,10月07日配置规则,指定30天后删除,则10月5日上传的Object在11月6日删除,10月08日上传的Object在11月09日删除。

如何修改其中一条或多条生命周期规则配置?

假设您的Bucket配置了两条生命周期规则,分别为Rule1和Rule2,您希望修改Rule1的某个配置项,您需要执行以下操作。

  1. 调用GetBucketLifecycle接口获取当前Bucket配置的所有生命周期规则,即Rule1和Rule2。

  2. 修改Rule1生命周期规则的配置项。

  3. 调用PutBucketLifecycle接口更新生命周期规则为Rule1+Rule2。

通过生命周期规则进行的类型转换、过期删除操作,是否有日志记录?

所有成功通过生命周期规则进行的类型转换、过期删除操作都会有日志记录,日志记录字段如下:

  • Operation

    • CommitTransition:转换存储类型。

    • ExpireObject:删除过期Object。

  • Sync Request

    lifecycle:触发的转换和删除操作。

关于OSS日志字段的更多信息,请参见日志字段详情。关于日志查询的费用说明,请参见计费说明

是否支持创建一条生命周期规则同时清理对象删除标记和当前版本对象?

不支持。您可以先创建规则清理对象删除标记,再创建规则删除当前版本对象。

如何通过生命周期快速清理Bucket下的所有文件

Bucket未开启版本控制

对于未开启版本控制的Bucket,只需要配置一条生命周期规则,即可自动快速清理所有文件和碎片(Multipart Upload产生的未合并碎片)。

  1. 登录OSS管理控制台的Bucket列表页面,找到目标Bucket。

  2. 在左侧导航栏,选择数据安全 > 版本控制,确认Bucket未开启版本控制。

    未开启版本控制

  3. 在左侧导航栏,选择数据管理 > 生命周期,设置生命周期规则,指定Bucket内所有文件在最后一次修改后1天自动删除,同时对生成时间早于1天的文件碎片,自动执行清理操作。

    screenshot_2025-07-01_17-59-32

Bucket已开启版本控制

Bucket开启版本控制后,会产生当前版本文件、历史版本文件、碎片文件和删除标记。只需要配置一条生命周期规则,即可自动快速清理这些文件。

  1. 登录OSS管理控制台的Bucket列表页面,找到目标Bucket。

  2. 在左侧导航栏,选择数据安全 > 版本控制,确认Bucket已开启版本控制。

    screenshot_2025-07-02_10-58-23

  3. 在左侧导航栏,选择数据管理 > 生命周期,设置生命周期规则,指定Bucket内所有当前版本、历史版本文件在最后一次修改后1天自动删除,同时对生成时间早于1天的文件碎片,自动执行清理操作。该规则会同步清理删除标记。

    screenshot_2025-07-02_10-58-23

如果针对Bucket内相同前缀的Object创建了两条生命周期规则,其中一条规则基于最后一次修改时间,另外一条规则基于最后一次访问时间,最终执行效果会怎么样?

例如,针对目标存储空间examplebucket创建了两条生命周期规则,规则一指定该Bucket内所有前缀为doc的Object在距离最后一次修改时间30天后删除,规则二指定该Bucket内所有前缀为doc的Object在距离最后一次访问时间30天后转低频访问类型。

由于OSS执行生命周期规则时遵循以用户较低开销为原则,因此仅规则一生效。原因是规则一中指定30天后直接删除与前缀匹配的Object,此后将不再产生费用。而规则二转为低频访问类型仍会收取相关存储费用或者数据取回费用等。

已配置的生命周期规则变更后何时生效,原有规则命中的数据如何处理?

例如,您已经针对前缀为er的Object配置了距离最后一次访问时间30天后转低频、又过了30天后当Object被访问时选择将其转为标准存储类型的生命周期规则。但是在距离最后一次访问时间的35天后,您将生命周期指定的前缀er变更为re,此时原有Object仅转存为低频访问类型,转存为标准存储类型的行为不生效。变更规则命中Object的最后一次访问时间也是从Bucket开启访问跟踪时开始统计。

在已开启版本控制的Bucket内开启智能分层,Bucket内不同版本的Object存储层级如何分布?

在已开启版本控制Bucket内的每一个Object都有唯一的版本ID,且不同版本ID的Object相互独立。因此可能会出现历史版本Object为低频访问类型,但是最新版本Object为标准存储类型的情况。

上一篇: 为什么存储类型转换后,源Object存储类型容量保持不变? 下一篇: 生命周期费用说明
阿里云首页 对象存储 相关技术圈