存储账单上的数字不会说谎：你在OSS控制台删除了一个文件，界面里已经看不到了，但月底的账单项下，存储费用非但没降，甚至还在缓慢增长。这种“删除未删”的错觉，根源正是OSS版本控制机制下的DeleteMarker。所谓“阿里云OSS DeleteMarker清理”，本质上是在和一套隐匿在版本链中的历史快照打交道——它不是一次普通删除就能了结的操作，而是一套需要理解版本语义、定位标记、再按版本ID定向清除的系统性动作。以下从基础概念拆解开始，逐步演示完整的清理与恢复路径。
一、版本控制与DeleteMarker基础概念
1. 什么是版本控制
版本控制是OSS提供的数据保护机制，一旦在Bucket级别开启，你对对象的每一次上传、覆盖和删除操作都不会真正抹去旧数据，而是以“版本”的形式全部保留在存储空间中。这意味着，即使你上传了10次同名文件，OSS也会保存全部10个历史版本。注意，这并非免费功能——所有版本（包括后续提到的DeleteMarker）都会占用存储空间并计入费用。很多用户只在“数据误删保护”的场景下理解版本控制，却忽视了它的成本属性：存储量会随操作频率线性增长，且关闭版本控制并不会追溯清理已存在的版本，只会停止生成新版本。
2. DeleteMarker：删除动作生成的“占位符”
DeleteMarker是版本控制开启后，执行普通删除操作时系统生成的特殊版本标记。它的本质是一个“隐藏指令”：将对象从当前版本列表中隐藏，使其不可见、不可访问，但对象的历史版本和DeleteMarker本身仍物理存储在OSS中。换句话说，你在控制台执行的删除动作，并非清除了文件，而是往版本链的顶端插入了一条标记。一个直观的理解是：DeleteMarker本身可以被删除，而删除DeleteMarker的后果，恰恰是让被隐藏的对象重新可见——这就是“恢复”方向的操作路径。实际运维中，大量用户困惑的“存储空间明明没释放，文件却看不到了”，正是DeleteMarker在起作用。
3. 为什么文件无法彻底删除
根本原因在于版本控制开启后，删除操作被重新定义：它从“物理擦除”变更为“逻辑隐藏”。普通删除仅追加一个DeleteMarker，对象的数据部分原封不动躺在存储池里，既占用空间，也继续产生费用，而且不会随DeleteMarker的可见性变化而消失。“彻底删除”必须指向两个层面：其一，删除DeleteMarker本身；其二，删除全部历史版本，且必须指定版本ID进行永久删除操作。这里有一个常见的反直觉点：关闭版本控制并不能让文件“彻底消失”——关闭只是止住了后续版本的新增，已存在的版本和标记依然占用存储，需要生命周期规则或手动指定版本ID逐一清理。
二、开启版本控制后的删除行为详解
在阿里云OSS中，DeleteMarker清理之所以困难，根源在于“删除”行为被设计成追加标记，而不是移除数据。不少用户会遇到一个现象：文件在控制台消失了，存储费用却照常扣，甚至因为版本累积而更高。要解决阿里云OSS DeleteMarker清理问题，必须先理解这个机制。
1. 普通删除如何变为标记
未开启版本控制时，删除对象就是直接移除数据。但启用版本控制后，普通删除（不指定版本ID）会被 OSS 转译为一个特殊版本——DeleteMarker。该标记不包含实际数据，只携带一个版本 ID，并成为对象的“当前版本”。
举例来说，你上传 test.txt 并覆盖了两次，产生 v1、v2 两个版本。此时执行不带版本号的删除，OSS 会生成一个 DeleteMarker 作为 v3，并将其置为当前版本。原本的 v1、v2 退居为历史版本。从控制台看，test.txt 消失了，但数据仍然存储在 OSS 节点上，照常计费。
关键点在于：普通删除永远只能“隐藏”数据，不能释放存储空间。要真正删除某个数据版本，必须显式指定版本 ID 做永久删除。这也是为什么清理任务通常需要依赖 ossutil 或生命周期规则——控制台上的删除按钮只是在版本链上再叠加一个标记。
2. DeleteMarker如何隐藏对象
DeleteMarker 的设计初衷是防止误删，所以在用户视角里它表现得像个“幽灵”。通过默认 API 或控制台访问该对象时，OSS 返回 404 Not Found，看起来数据已经不存在。但如果你在请求中带上某个历史版本的 ID，数据仍然可以被读取。
一个容易忽略的细节是：DeleteMarker 本身也属于“版本”，即便内容长度为 0，也会占用元数据存储空间。在版本控制状态下，对象每修改一次、每删除一次，都会产生新的版本。经过一段时间后，历史版本和 DeleteMarker 的数量可能膨胀到百万级，账单上的存储费用则按所有版本的数据总量持续统计。
所以，如果删除文件后存储容量没有下降，不用怀疑 OSS 的统计有误——真实情况就是数据没有消失。此时需要做的不是继续“删除”，而是去检查版本列表里到底积累了多少历史版本和 DeleteMarker。
3. 恢复与覆盖的依赖关系
DeleteMarker 的存在让“恢复”和“覆盖”变成一对容易混淆的操作。恢复一个被标记删除的对象，最直接的办法是删除对应的 DeleteMarker。该动作会让之前的历史版本重新成为当前版本，对象恢复可见，整个过程不会产生新的数据版本，也不会改动历史版本的内容。
另一种恢复方式是复制历史版本作为当前版本，但这种方式实际上是“覆盖”操作。当执行复制时，OSS 会生成一个新版本并置为当前版本，原先的 DeleteMarker 或数据版本则退居历史。这会导致一个陷阱：如果当前版本不是 DeleteMarker，而是一份旧数据，复制操作会用新版本覆盖它，旧数据虽然仍保留在历史版本中，但后续访问结果可能与你预期完全不同。
对于日常运维，恢复误删文件的优先级应高于覆盖。不要在紧急情况下盲目复制历史版本，建议先通过控制台开启“显示历史版本”，确认当前版本到底是 DeleteMarker 还是普通数据版本，再决定是删除标记还是复制恢复。这个判断一旦出错，可能让数据恢复变得比删除前更混乱。
三、查看DeleteMarker和版本状态
在动手清理之前，先定位DeleteMarker。很多人删完文件后发现账单没降，就是因为只看到了控制台里“文件没了”的表象，没有意识到自己看到的只是版本列表的“当前版本”那一层。只有当你能完整列出对象的每一个版本和DeleteMarker，后续的彻底删除操作才有依据。
这一部分分两个动作：先在控制台确认对象状态，再用ossutil命令把隐藏的标记和版本全部列出来核对一遍。两个动作分别解决“看到问题”和“拿到精确版本ID”这两件事，后者是后续调API或写生命周期规则时的必要信息。
1. 控制台如何查看版本
进入OSS控制台的Bucket管理页面，在“文件管理”列表里，默认视图下看不到任何已删除的对象——这类对象已经被DeleteMarker“覆盖”成了当前版本，列表里只会显示一条标记为“删除标记”的灰色条目，文件名和原对象一致，但大小显示为0，且操作列只有“彻底删除”，没有“下载”或“设置权限”的选项。
要看到完整的版本历史，点击列表右上角的“显示历史版本”开关。开启后，同一个文件名下会列出所有历史版本，每条记录旁边标注了版本ID、最后修改时间和“当前版本”或“非当前版本”的标识。DeleteMarker在列表里显示为单独一行，版本ID是一串长字符串，双击即可复制。这一步的主要目的是确认两个事实：第一，你要清理的对象确实是以DeleteMarker形式存在的；第二，这个标记的版本ID到底长什么样，因为后面用命令行精确删除时必须用到这个ID，复制错了就删到别的版本上了。
控制台里无法批量勾选删除多个DeleteMarker，只能一个个点“彻底删除”。少量标记可以用这种方法处理，但如果你发现列表里翻了几页还没到底，就别继续手工点了，直接跳到下面的命令方式。
2. 使用OSS命令列出标记
控制台适合“看一眼”和“删一两条”，但生产环境里的DeleteMarker往往是成百上千条，不可能靠肉眼翻页。这里用ossutil工具来做批量核对。安装并配置好AK/SK后，执行以下命令列出Bucket内所有版本：
ossutil ls oss:// --all-versions
命令输出会返回每个对象的版本ID、最后修改时间、大小以及是否为DeleteMarker。如果你想限制范围到某个目录或前缀，在Bucket后面加上路径：
ossutil ls oss:/// --all-versions
输出结果里，DeleteMarker区别于普通版本的地方是：它没有大小字段（显示为空或0），且版本类型标注为DeleteMarker。把输出内容重定向到本地文本文件，方便后续按文件名和版本ID逐条核对：
ossutil ls oss:/// --all-versions > versions.txt
有一种更快的定位方式：只列出标记。用--delete-marker参数可以过滤出Bucket内所有的DeleteMarker，避免输出里混入大量正常历史版本干扰判断：
ossutil ls oss:/// --all-versions --delete-marker
执行这条命令后，你会得到一个纯粹的DeleteMarker清单，每条包含对象名和版本ID。对比一下控制台里的显示结果，你会发现两者完全一致——但命令行方式能直接拿到全部清单，不必控制台一页一页翻。
清单拿到后，你就能明确区分哪些是当前版本（带current标识）、哪些是历史版本、哪些是DeleteMarker。区分清楚的意义在于：当前版本是用户正在访问的数据，不能随便删；历史版本是误删覆盖后的恢复依据；只有DeleteMarker才是“文件明明删了但还在收费”的元凶。后面的清理操作，目标锁定在清单里标记为DeleteMarker的那些条目上，而不是把整个版本列表清空。
四、彻底删除DeleteMarker的两种方式
很多用户以为在控制台勾选“删除”就能释放存储，但开启版本控制的Bucket里，普通删除只是给对象盖了一个DeleteMarker的“墓碑”。数据仍然躺在OSS里，账单照扣。要真正腾出空间，只有两条路：手动指定版本ID删除，或者让生命周期规则替你做脏活。
1. 手动删除指定版本
这是最直接、也最容易被误操作的方式。前提是你必须拿到目标对象的版本ID——没有版本ID，OSS无法识别你要永久删除的是哪一个历史版本，普通删除只会再叠加一层DeleteMarker。
操作路径：OSS控制台 → Bucket → 文件管理 → 勾选“显示历史版本” → 找到带DeleteMarker标记的版本 → 选中 → “彻底删除”。
如果你管理的对象数量上千，控制台就不可用了。推荐用ossutil命令行，先列出所有版本：
ossutil ls oss://bucket-name/ --all-versions --marker delete-marker
输出会带出VersionId和IsDeleteMarker字段。确认要清理的标记后，逐条执行指定版本删除：
ossutil delete oss://bucket-name/object-name --version-id "版本ID"
效果：该DeleteMarker被移除，如果底层还有历史版本，对象会“复活”并显示出来；如果你把该对象的所有版本和DeleteMarker都删光了，存储空间才会真正释放。注意，这个动作不可逆，执行前建议先用list-versions导出清单留底。
2. 通过生命周期自动清理
手动删除在规模面前是灾难。生产环境动辄百万级DeleteMarker，人力根本清不完。更合理的做法是配置生命周期规则，让OSS按你的策略自动过滤并清理过期标记。
控制台配置路径：Bucket → 生命周期 → 创建规则 → 选择“清理过期删除标记”或“清理历史版本”。
这里的关键是规则粒度。一个常见策略是：对整个Bucket启用“删除当前版本为非最新版本的过期对象”规则，并将过期天数设为1天。这意味着任何被覆盖或删除的旧版本，在次日就会被系统彻底清除。对于DeleteMarker，可以单独配置“过期删除标记”规则，当当前版本是DeleteMarker且早于你设定的天数（比如30天），OSS会自动摘除这层“墓碑”。
Clean-DeleteMarker-30d
Enabled
true
效果：存储成本按规则持续收敛，账单中的“版本控制存储量”会下降，且整个过程无需人工干预。需要注意两点：第一，生命周期规则生效有延迟，通常每小时左右执行一轮，不会秒级删除；第二，如果你只想清理DeleteMarker但保留历史版本，务必把规则拆成两条——一条处理删除标记，一条处理旧版本，避免误删可恢复数据。从实际经验看，制造业和金融客户倾向于保留历史版本90天以上，而WEB3项目方则大多选择7天内自动清理，因为链上数据快照本身就能重建对象，磁盘上的旧版本只是临时冗余。根据场景设定保留周期，才能让生命周期规则真正变成省钱工具，而不是疯狂加成本的黑洞。
五、删除后如何恢复被覆盖的文件
开启版本控制的 Bucket 里，普通删除只是给对象“盖”了一个 DeleteMarker，底层数据原封不动。所以被覆盖或“删除”的文件，都有机会恢复。关键是搞清楚版本 ID 和当前版本的关系。
1. 恢复历史版本到当前
操作路径：控制台 → Bucket → 文件管理 → 显示历史版本
- 登录 OSS 控制台，进入目标 Bucket，点击「文件管理」。
- 右上角打开「显示历史版本」开关，列表会展示同一 object 的所有版本，包括带有 “DeleteMarker” 标记的版本。
- 找到你想恢复的那个历史版本，点击右侧「更多」→「复制到当前版本」。系统会将该版本复制一份并设置为当前版本，原历史版本保留。
效果说明： 对象立即恢复为可访问状态，访问 URL 返回的是你选定的历史内容。因为复制会产生一次新的写入，这个操作会新增一个版本，并产生一次 PUT 请求费用。注意，这不是“物理回滚”，而是生成一个新的当前版本，所以如果你还想保留原当前版本（比如误覆盖前的错误数据），它依然留在历史版本列表里，可以随时再次切换。
另一种更轻量的方式：删除 DeleteMarker
如果只是误删（没有覆盖），最简单的方法不是复制，而是直接删除那个 DeleteMarker。用 ossutil：
# 先列出所有版本，找到 DeleteMarker 对应的 versionId
ossutil ls oss://my-bucket/data/file.txt --all-versions
# 删除指定的 DeleteMarker 版本
ossutil rm oss://my-bucket/data/file.txt --version-id 4321 # 示例 versionId
删除 DeleteMarker 后，对象会自动“恢复”到被删前的状态，因为底层那个版本还在。这个方法不会产生新版本，也不产生额外存储费用，适合纯删场景。
2. 利用版本回退的场景限制
版本回退不是万能的，有几个限制必须提前知道：
- 只对“开启版本控制后”的变更有效。如果你之前从未开启过版本控制，那么覆盖或删除就是物理性的，无法通过历史版本恢复。版本控制默认关闭，需要提前开启。
- 生命周期规则会永久删除过期版本。如果你配置了生命周期自动清理过期版本或 DeleteMarker，那些被清理掉的历史数据就再也找不回来了。恢复时效取决于你的生命周期过期时间。
- 关闭版本控制不会让历史版本消失。关闭只是停止生成新版本，已存在的历史版本和 DeleteMarker 依然占有空间并计费，也不会让你可以“直接恢复”某个版本，因为控制台的版本展示入口仍然存在，只是不再新增。
- “永久删除指定版本”不可逆。如果有人在控制台或 API 里直接指定 versionId 执行了永久删除，那部分数据就真的没了，任何恢复操作都无效。
实际操作中，最常见的误区是：以为关闭版本控制就能清理所有版本，于是去关闭，结果历史版本还在，存储费用也没有降。正确的做法是先用生命周期规则清理，再考虑关闭。
3. 误删后快速恢复操作指南
如果一个生产环境的重要文件被误删，别慌，按下面几步走：
- 确认版本控制状态：打开 Bucket 的「版本控制」页签，确认状态是“开启”。如果是“未开启”，只能找备份或联系售后，无法通过版本恢复。
- 定位 DeleteMarker：进入文件管理，开启“显示历史版本”，找到列表顶部带有 “DeleteMarker” 标记的记录，记下它的版本 ID。
- 删除该 DeleteMarker：在控制台上直接点“删除”，或者在 ossutil 里按上面命令执行
rm --version-id。删除时注意不要勾选“永久删除”其他版本。 - 验证恢复结果：刷新控制台，对象就会重新出现在当前版本中，点击文件确认内容无误。
效果说明： 整个恢复过程通常只需要几秒，不产生额外的存储费用，但会涉及 DELETE 请求的费用（极低）。对比恢复前，你无需重新上传数据，也无需修改任何业务代码，只动了版本管理层面。
一个更高效的推荐组合：对于关键目录，建议开启版本控制后，再配置一条生命周期规则——保留最近 30 天的历史版本，过期自动清理。这样既控制存储成本，又留住了“后悔窗口”。阿里云控制台在「生命周期管理」里可以按前缀设置，没什么技术门槛。
六、最佳实践与风险规避建议
DeleteMarker清理之所以让不少团队头疼，根源在于这是一个"不可逆操作"与"易错操作"并存的过程。结合我们在制造业、金融、医疗等行业的迁移与运维经验，以下三方面值得提前规划，避免为了一次清理引入新的故障。
1. 权限控制避免误删
清理DeleteMarker意味着执行"永久删除指定版本"操作，这是OSS权限体系里高危动作，一旦执行，对应版本的数据将无法恢复。
建议采用最小权限原则做权限切分：
- 运维/开发人员：仅授予
oss:ListObjectVersions和oss:GetObjectVersion权限，用于查看和核对历史版本列表，但无删除权限。 - 安全/审计人员：单独持有
oss:DeleteObjectVersion（指定版本删除）权限，负责执行最终清理。 - 核心管理员：保管根账号或高权限RAM子账号，非紧急情况不直接操作控制台。
操作说明：在RAM控制台创建两个自定义策略，参考如下：
// 只读策略：允许查看版本列表
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": [
"oss:ListObjectVersions",
"oss:GetObjectVersion"
],
"Resource": "*"
}
]
}
// 清理策略：仅允许指定版本删除
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": "oss:DeleteObjectVersion",
"Resource": "*"
}
]
}
效果说明：将普通删除（生成DeleteMarker）和彻底删除（按版本ID删除）权限分离后，即便开发人员的AccessKey泄露，攻击者充其量只能做"普通删除"，所有数据仍可通过删除DeleteMarker找回，损失被控制在一个可恢复的范围内。我们在服务某制造业客户时，就借助这套权限模型有效隔离了开发环境与生产环境的操作边界。
2. 生命周期策略怎么配置
与其等DeleteMarker堆积后再人工清理，不如让生命周期规则自动处理。正确配置生命周期，能同时解决"存储成本持续增长"和"DeleteMarker清理"两个问题。
操作说明：
在OSS控制台进入Bucket的「生命周期管理」配置页面，新建规则时重点关注以下三个配置项：
- 清理过期DeleteMarker：指定"当前版本为DeleteMarker且早于N天"的对象将被清除。N建议设置为30天，给误删恢复留出时间窗口。
- 清理历史版本：对非当前版本（包括历史版本和DeleteMarker），按保留天数自动删除。可结合业务对数据保留周期的要求设置，如金融行业建议180天，制造业MES数据建议保留90天，WEB3项目因其链上数据不可变性，存储于OSS的链下补充数据往往需要长期保留，可酌情延长至365天。
- 过滤规则：建议按目录前缀（Prefix）或标签（Tag）圈定范围，避免将需要长期归档的数据一并清理。
示例规则配置如下：
Clean-Expired-DeleteMarker
logs/ Enabled
true
10
30
效果说明：配置生效后，无需人工介入即可自动清理过期标记和历史版本。需要注意的是，生命周期规则创建后，最快需要24小时才会开始生效，且是按天粒度执行，并非实时删除。如果业务对存储成本敏感，建议在产品上线早期就规划好规则，而不是等到账单翻倍之后才补救。
3. 清理前需注意哪些事项
执行DeleteMarker清理前，请务必检查以下三点，避免操作失误导致数据不可恢复：
- 确认当前版本状态：先在控制台开启"显示历史版本"功能，核对目标对象的当前版本是否是DeleteMarker。如果当前版本是正常数据，但你强行按版本ID删除了它，等于把最新数据永久删除了。操作前务必先导出版本列表核对一遍，可用以下命令：
ossutil list-versions oss://your-bucket-name/ --max-keys 100
- 恢复操作优先于清理操作：如果是想找回被覆盖或误删的文件，优先尝试删除对应的DeleteMarker（把被隐藏的旧版本恢复为当前版本），而不要直接对历史版本做永久删除——后者会把唯一一份完整数据销毁，前者的风险更低。执行删除时，请务必使用"指定版本ID删除"的API或命令，不要用普通删除命令：
ossutil rm oss://bucket/object --version-id "版本ID" --permanent
- 评估潜在的开销与失败影响：对于海量对象（例如百万级以上DeleteMarker）的清理，建议分批次小范围执行，通过清单功能（Inventory）导出对象列表，先跑通流程再逐步推广。同时预留脚本执行失败后的回滚方案，例如在夜间低峰期操作，并在操作前确认目标Bucket未开启跨区域复制——复制规则会在清理时产生额外的DELETE同步记录，增加排查复杂度。
综上，DeleteMarker清理的最佳路径是：先做好权限隔离，再配置生命周期兜底，最后在清理前做好核对与评估。这套组合操作能最大程度降低误删风险，同时有效控制存储成本。
本篇关联内容：如需回顾DeleteMarker的生成原理与手动清理步骤，可翻看前文相关章节。本系列文章至此完结。
