未开启版本控制的S3存储桶如何识别被boto3上传覆盖的原有文件？

因为存储桶未开启版本控制、事前也没导出原文件清单，没法直接从S3控制台回溯历史文件的具体内容，完全可以通过留存的操作日志交叉比对完成排查，不需要靠猜测。

优先利用CloudTrail日志做精准溯源 #

这是准确度最高的排查路径，不受是否提前做文件备份的限制：

• 先锁定本次boto3批量上传的准确时间窗口，即脚本启动到运行结束的精确起止时间，尽量压缩检索范围减少无效日志
• 从对应区域的CloudTrail日志中筛选两类核心记录：
  • 首先提取本次上传操作用到的IAM身份（运行boto3脚本的角色/用户ARN）发起的所有PutObject事件，把返回200成功的对象键全量导出，形成本次上传的2000个文件的完整列表
  • 再以这个列表为检索条件，匹配时间早于本次上传开始时间的所有同对象键的PutObject事件——只要某个对象键在本次上传前就有过成功写入记录，就说明该文件是被本次上传直接覆盖的原有文件
• 注意适用前提：如果当时没有为目标S3桶开启对象级的数据事件采集，CloudTrail中是不会留存具体PutObject调用记录的，这种情况就切换到下一种排查路径。

利用S3服务器访问日志交叉验证 #

如果存储桶早前开启了服务器访问日志投递，可以直接从日志中提取有效信息：

• 同样先锁定本次上传的时间范围，再通过boto3特有的User-Agent标识、调用来源IP，从日志中筛出本次操作写入的所有对象键，形成待校验的文件列表
• 在日志覆盖的更早时间范围内，检索上述列表中的对象键的历史记录：只要存在早于本次上传时间的成功写入、或正常访问记录，即可判定该文件原本就存在、被本次上传覆盖
• 检索时要排除本次上传操作自身产生的日志条目，避免误判。

依托本地操作记录做兜底排查 #

如果没有开启任何云端日志，就从本次boto3上传的本地运行痕迹找线索：

• 先从本地上传脚本的运行日志中，导出所有本次成功上传的文件对象键列表
• 检查脚本当时的逻辑：大部分批量上传脚本在正式上传前，都会调用head_object接口探测目标对象是否存在，只要日志中记录了探测时返回200的对象键，这些就是明确被覆盖的文件
• 如果脚本没有做前置探测，可以拿本地留存的待上传源文件做比对：对每个本地源文件按S3规则计算对应的ETag值，拉取当前S3上同名对象的ETag做校验——虽然上传成功后当前对象的ETag一定和本地源文件一致，但可以结合本地文件的创建时间、脚本的运行日志，排查有没有早前上传同名单文件的痕迹，缩小排查范围。

排查中的常见避坑点 #

• 不要把分片上传中断残留的未完成分片计入正式对象列表，这类内容不会出现在正常的对象枚举结果里
• 检索历史记录时，要把时间线严格卡在本次上传的开始节点上，早于这个节点的所有同键写入记录，都属于原有文件的有效痕迹
• 查CloudTrail日志时要定位到目标存储桶所在的区域，跨区域的日志不会留存本桶的对象操作记录

内容的提问来源于stack exchange，提问作者Yeahprettymuch