用途：帮助开发者和数据工程师在 Azure ADLS Gen2 上设计、实施并运维 Snowpipe 的业务连续性与灾难恢复（BCDR），在六种模式间做选择。
六种模式（资料给出的 RPO/RTO/成本/复杂度）：1 手动补齐（单管道，Min–hrs / 30–90 min / 最低 / 低）；2 双活+去重（Zero / ~1 min / 最高 / 高）；3 RA-GRS 读取（近零 / 5–15 min / 中 / 中）；4 主备 SF+GRS（近零 / 5–15 min / 中 / 中）；5 仅 Snowflake Failover Group（近零 / 5–15 min / 低–中 / 低）；6 双存储双管道（近零 / 5–10 min / 中 / 中）。模式 2–6 需 Business Critical 版本以使用 Failover Group；低版本仅适用模式 1。
选择依据：非 Business Critical 选 1；要求零丢失选 2；Azure 故障选 4 或 6；Snowflake 故障选 5；有 RA-GRS 选 3；预算受限选 1 或 5。
核心规则：同一文件集只允许一个写入管道（模式 2 去重除外）；存储集成须同时允许主/次 URL（STORAGE_ALLOWED_LOCATIONS 中列 azure://<primary> 与 azure://<secondary>）；COPY_HISTORY 在 Failover Group 中复制但仅保留 14 天，需更久则维护 FILE_LOAD_HISTORY 备份表；ALTER PIPE … REFRESH 硬上限 7 天，更早文件用 DIRECTORY(@stage) + COPY INTO；INBOUND 通知集成不复制，故障切换后须在 DR 账户同名重建并重新建立 Service Principal 信任与 Event Grid 订阅。
流程：Step 1 确认版本、存储类型、Event Grid 与 Storage Queue；Step 2 按存储集成→stage→管道（AUTO_INGEST=TRUE 和通知集成）→监控视图→补齐过程实施；Step 3 用 SYSTEM$PIPE_STATUS 验证，监控 pendingFileCount、COPY_HISTORY 错误率与加载延迟；Step 4 执行切换/回切/补齐，含暂停主管道、从 COPY_HISTORY 取检查点、启用备管道并 REFRESH MODIFIED_AFTER。
限制：仅 Azure ADLS Gen2，AWS S3 / GCS 变体不在范围；执行 CREATE/ALTER 前及暂停主管道前设有需用户确认的停止点；常见错误包括双管道同时运行致重复加载、集成缺次 URL 致 ACCESS_DENIED、依赖超 14 天的 COPY_HISTORY、DR 无 Event Grid 订阅、对旧文件用 REFRESH、重建管道漏 AUTO_INGEST=TRUE 等。