Azure Blob：版本保留、生命周期与恢复
版本、快照与生命周期
前置是当前Blob、属性与条件写入。目标是针对误覆盖、误删除与保留成本选择保护机制。理论核对截至2026-10-17；这些保护能力依赖账号种类、HNS状态、区域和服务限制，应按实际账号核对。示例工程不启用或修改任何保护策略。
Azure Blob 版本与快照
Azure Blob 版本与快照：版本化在受支持的写入后自动保留历史状态，快照由调用者主动捕获只读时间点；读取历史数据须带version_id或snapshot明确选择。两者都不是“把ETag作为下载地址”。历史对象会产生存储成本，创建前就要定义保留期与清理责任。
版本化开启时，删除当前Blob会保留先前版本而使当前对象不再可见；恢复要明确将选定版本提升为新的当前对象，而不是猜哪个时间戳最新。快照可单独读取或复制，基础对象与快照共享名称但快照有独立标识。若使用Copy Blob恢复，要检查copy_status并等待完成，不能把返回copy_id视为字节已恢复；复制源还须满足服务可读的授权条件。
Azure Blob 软删除与HNS差异
Azure Blob 软删除与HNS差异：软删除在保留期内保护指定删除场景，HNS账号与平面账号支持的覆盖恢复路径不同。HNS当前不支持Blob版本化，不能照抄“开启versioning后自动保留每次覆盖”的方案；HNS软删除主要保护删除，不保护覆盖。快照适用性与特定Data Lake操作限制也应按官方能力矩阵验证，不能只凭Blob API端点存在就推断全面支持。
平面账号启用软删除而不启用版本化时，覆盖可形成软删除快照；同时启用版本化时，覆盖形成历史版本。undelete_blob在有效保留期内恢复软删除数据，但版本化场景不会直接把旧版变成当前Blob。容器软删除独立于Blob软删除；删除容器后要先恢复容器，再检查对象。关闭策略不会自动恢复已经丢失的数据。
Azure Blob 生命周期规则
Azure Blob 生命周期规则：规则按过滤条件与时间阈值异步执行分层或删除，生命周期不是立即执行的定时任务。只过滤当前对象并不自动处理版本和快照；清理设计必须分别覆盖baseBlob、previousVersions和snapshots所需动作，并确认当前对象的删除与其历史数据限制。
配置草案的评审应核对prefixMatch包含容器名、大小写、目标类型、最后修改/创建/最后访问时间的具体含义，以及与软删除、不可变保留、法律保留的交互。不要在生产账号直接试一个广泛匹配的删除规则。练习题：设置30天删除是否保证第31天账单归零？答案是否定的，执行异步、软删除保留与历史对象仍可能计费。
Azure Blob 归档与备份边界
Azure Blob 归档与备份边界：Archive是离线访问层，重水化需要时间；分层用于成本控制，独立备份用于满足恢复目标。读取归档对象失败不应直接按404处理或重建空内容。恢复演练要衡量重水化、权限恢复、批量复制和应用索引重建的总时间，而不是只测一个GET。
同账号版本或快照可能遭遇同一权限误操作、账号级破坏或保留策略删除；冗余复制又可能传播业务误删。对关键数据应评估隔离副本、不可变性、Azure Backup适用模式及跨边界权限，不能声称软删除覆盖任意灾难。恢复点目标决定保留与复制频率，恢复时间目标决定可接受的恢复流程。策略写完后仍需在读者授权环境定期演练；本文没有执行演练。
官方依据
恢复决策与故障诊断
前置是HTTP状态码、ETag及账号保护配置。目标是从证据选下一步，而不是看到错误就重试。所有案例为人工预期，示例未执行；不得把静态检查结果当作恢复成功报告。
Azure Blob 403 与404诊断
Azure Blob 403 与404诊断：403应核对实际身份、数据角色、SAS范围和网络规则，404应核对账号端点、容器、大小写与版本标识。仅凭状态码不能穷尽根因，应同时读取服务错误码与请求ID，并记录操作名和UTC时间；日志必须剔除SAS、Authorization及连接串。角色传播延迟可能影响刚授权的请求，不能用公开容器绕过排障。
题目：Portal能看到账号但SDK不能下载怎么办？答案是先区分管理平面与数据平面，再核对credential chain实际主体和容器角色。题目：当前Blob不存在但能列举版本怎么办？答案是查明删除或覆盖历史并选择恢复点，不要立刻上传空文件占用原名称。私有DNS错误还可能使请求发到错误端点，先确认客户端访问的是Blob endpoint。
Azure Blob 409 与412诊断
Azure Blob 409 与412诊断：409可能表示对象已存在或租约状态冲突，412可能表示ETag或租约条件失败；应以服务错误码和请求条件定位，不把所有412都当ETag过期。工程只有在指定旧ETag分支才将412列为预期。保留读得的ETag、发出的条件和请求ID，才能重建谁先写入。
解决乐观并发失败时重新读当前状态，并由业务决定合并或返回用户冲突，不能简单删除If-Match。解决lease失败时联系租约所有者、确认续约和有效期；自动break租约可能破坏其他进程。超时后重试若出现412，可能先前写入已经成功，应核对内容、元数据与业务操作ID，不能直接重复追加或覆盖。
Azure Blob 恢复路径选择
Azure Blob 恢复路径选择：先识别删除的是容器、当前Blob还是历史版本，再检查软删除保留期与可读恢复点。平面账号且未开启版本化时，保留期内undelete_blob可用于相应软删除场景；启用版本化时，恢复当前对象通常要选旧version_id复制为新的当前对象，undelete不会自动完成提升。
安全恢复应先下载或复制到新名称验证长度、摘要与应用格式，再以条件操作发布，避免破坏仍在使用的当前对象。复制要处理源授权、目标权限、pending状态与最终失败，并核对应用索引是否引用正确对象。版本/快照清单不是一致的跨对象事务快照，多个对象组成的业务记录须有清单、事务边界或业务版本关联。本课工程只展示读取历史标识，不自动发起恢复复制。
Azure Blob 恢复失败边界
Azure Blob 恢复失败边界：保留期过后或没有保护点时，历史字节可能无法恢复；冗余不是任意时间回滚。HNS功能差异、账号删除、永久删除权限、不可变策略、归档重水化与容器恢复都可能改变可用路径。不要承诺“开启软删除就一定能找回”。
事故记录至少保留精确账号/容器/名称、UTC时间、请求ID、版本或快照ID、保护配置生效时间和业务影响。暂停会减少恢复点的生命周期删除与并发写入后，按授权恢复计划执行；演练应验证读者身份能恢复数据，也验证恢复后的应用能正确读取。账单仍有历史存储不代表当前对象没删，404也不代表所有版本已清理。
官方依据
继续阅读
- Azure Blob完整SDK工程
- Azure Blob对象与入门
- Azure Blob身份与保护契约