PAYATHON 2026

Azure Portal 恢复已删除 SQL Server database 失败

数据阿明

结论

RestoreIneligibleDroppedDatabaseShortLifespan 的意思是：数据库从创建到删除的时间太短，Azure SQL Database 还没有生成并保留完整、可用于还原的备份链，因此无法执行时间点还原。

Portal 显示 Earliest restore point 和 Restore point，不代表底层备份一定可以还原。界面可能根据数据库生命周期、删除记录或备份保留元数据生成候选时间范围，但最终能否恢复，仍取决于 Azure SQL 后端对实际备份链的检查。如果缺少初始完整备份，或者备份链不完整，后端就会返回这个错误。

把还原时间提前 5 分钟通常解决不了问题。这里的问题不是还原时间晚于删除时间，而是没有符合条件的基础备份。

为什么会出现这种情况

Azure SQL Database 的时间点还原不会在数据库创建后立即可用。新建、复制或还原出的数据库，需要先完成初始完整备份。之后生成的差异备份和事务日志备份，才能组成可用于 PITR（Point-in-Time Restore）的备份链。

以下情况较容易触发这个错误：

  • 数据库创建后不久就被删除。
  • 数据库刚由复制、还原或部署流程创建，初始备份还没有完成。
  • 数据库使用相同名称反复创建和删除，Portal 中的删除记录与预期数据库不属于同一次生命周期。
  • Portal 已经显示删除记录和时间范围，但底层备份尚未完成、未成功注册，或者已经无法还原。

初始备份需要多长时间，没有适用于所有数据库的固定保证。数据库大小、服务层级、区域负载和内部备份调度都可能影响完成时间。因此，不能只根据数据库存在了多少分钟，判断它一定可以恢复。

这里需要区分两个概念：

  • 备份保留期：备份生成后可以保存多久。
  • 备份可用性：数据库删除前是否已经生成一套可用备份。

即使删除时间仍在短期保留期内，只要数据库删除前没有形成可用的初始备份，保留期就无法解决问题。

建议先核实数据库的实际生命周期

检查 Azure Activity Log、部署流水线或 IaC 记录，确认以下信息：

  1. 该数据库实例的创建时间。
  2. 数据库是否通过复制或还原操作生成。
  3. 数据库的删除时间。
  4. 是否存在同名数据库删除后又重新创建的情况。
  5. 删除前是否成功执行过 PITR、导出或复制。

名称相同，不代表它们是同一个数据库实例。删除后重新创建同名数据库，会产生新的资源生命周期和备份链。

还需要在 Deleted databases 中核对所选记录的删除时间，确认它与 Activity Log 中目标数据库实例的删除事件完全一致。

可以尝试的恢复方式

1. 选择更早且早于删除时间的还原点

如果数据库在删除前已经运行了较长时间，可以选择更早的还原点，例如提前一小时，而不是只提前五分钟。

这种方法只适用于较晚的日志备份存在问题，但更早的备份链仍然有效的情况。如果所有时间点都返回 RestoreIneligibleDroppedDatabaseShortLifespan，继续按分钟调整还原时间通常没有意义。

还原操作会创建一个新数据库，不会直接恢复原数据库。目标名称也必须符合当前 logical server 的命名规则，并且不能与现有名称冲突。

2. 检查 Long-term retention 备份

如果该数据库之前配置过 LTR（Long-term Retention），可以到服务器或数据库的长期保留备份页面查找可还原的备份。

LTR 必须在数据库删除前完成配置并成功生成备份。数据库删除后，无法补建过去的 LTR 备份。

3. 查找其他数据副本

如果 PITR 不可用，可以继续检查是否存在以下数据副本：

  • .bacpac 导出文件。
  • Azure Storage 中的手工备份或数据导出。
  • Geo-replica、failover group secondary 或其他只读副本。
  • 开发、测试、报表或数据仓库中的同步副本。
  • Azure Data Factory、ETL 或分析平台保存的数据。
  • 应用程序缓存、审计记录或业务导出文件。
  • 删除前创建的数据库副本。

如果只需要恢复一张表，从这些副本中提取数据，通常比恢复整个生产数据库更实际。

4. 提交 Azure Support 请求

如果 Activity Log 显示数据库实际存在了较长时间，但 Portal 仍然报告”存活时间太短”，建议提交 Azure Support 工单，并提供以下信息：

  • Subscription ID。
  • Logical server 名称。
  • 已删除数据库名称。
  • 数据库创建时间和删除时间。
  • Region。
  • 完整错误代码 RestoreIneligibleDroppedDatabaseShortLifespan。
  • Restore operation 的时间、Correlation ID 或 Deployment operation ID。
  • Portal 显示的 Earliest restore point 和所选 Restore point。

这些信息有助于确认具体原因：Portal 元数据不一致、选择了错误的同名数据库实例，或者底层确实没有可用备份。

如果 Azure 后端确认数据库删除前没有形成可用的备份链，Support 通常也无法从不存在的备份中恢复数据。

成功恢复后只读取一张表

假设数据库已经恢复为 old-db-name_recovered，可以先确认目标表是否存在：

SELECT
    s.name AS schema_name,
    t.name AS table_name
FROM sys.tables AS t
JOIN sys.schemas AS s
    ON s.schema_id = t.schema_id
WHERE t.name = N'TargetTable';

读取数据时，应明确指定 schema：

SELECT *
FROM dbo.TargetTable;

如果数据量较大，不要直接运行没有限制条件的查询。可以先查看总行数和部分样本：

SELECT COUNT_BIG(*) AS row_count
FROM dbo.TargetTable;

SELECT TOP (100) *
FROM dbo.TargetTable;

需要将表导出到本地时，可以使用 bcp。下面的命令使用 Microsoft Entra authentication 导出数据：

bcp "SELECT * FROM [dbo].[TargetTable]" queryout TargetTable.bcp \
  -S "your-server.database.windows.net" \
  -d "old-db-name_recovered" \
  -G \
  -N

如果要把数据导入另一个 Azure SQL Database，可以先在目标数据库中创建结构相同的表，再执行：

bcp "dbo.TargetTable" in TargetTable.bcp \
  -S "your-server.database.windows.net" \
  -d "target-database" \
  -G \
  -N

导入前需要核对主键、identity、计算列、外键和触发器。对于结构复杂的表，使用 SSMS 的 Generate Scripts、导入/导出向导或 .bacpac 通常更稳妥。

注意事项

  • 删除数据库列表中存在记录，不代表一定有可恢复的备份。
  • Earliest restore point 只是界面提供的候选边界，最终能否恢复取决于服务端的备份状态。
  • 还原时间必须早于删除时间，但仅满足这一条件，仍不能保证恢复成功。
  • 调整还原点无法补上缺失的初始完整备份。
  • 不要删除当前 logical server 或相关资源组，否则可能进一步影响删除备份的发现和恢复。
  • 在目标表完成导出并通过验证前，不要删除恢复出来的新数据库。
  • 对重要数据库，应同时配置合理的 PITR 保留期、LTR、定期 .bacpac 导出或独立数据复制，避免只依赖一种恢复机制。

备注：内容仅供参考。