在 Azure Monitor 中还原日志

还原操作使表中数据的特定时间范围在热缓存中可用于高性能查询。你指定源表和时间范围后，Azure Monitor 会创建一个以 _RST 结尾的目标表，你可以对还原的数据运行完整的 KQL 查询。完成后，删除该还原项即可停止计费。

还原是访问长期保留中的数据的一种方法。使用还原功能对特定时间范围内的数据执行完整的 Kusto 查询语言（KQL）查询。使用搜索作业，根据特定条件访问数据。此外，当日志查询无法在 10 分钟的超时时间内完成时，还可以使用还原操作针对任意 Analytics 表运行查询。

先决条件

若要从长期保留中还原数据，您需要具有对 Log Analytics 工作区的Microsoft.OperationalInsights/workspaces/tables/write和Microsoft.OperationalInsights/workspaces/restoreLogs/write权限。 Log Analytics参与者内置角色提供这些权限。

具有辅助表计划的表不支持数据还原。使用搜索作业从辅助表中检索处于长期保留中的数据。

注意

Azure Lighthouse不支持对还原作业或搜索作业的委派访问权限，即使委派角色包含restoreLogs/write权限也是如此。

恢复数据

还原数据时，请指定源表和新目标表的名称。目标表名称必须以 _RST. 结尾。还原操作创建此表，并使用支持完整 KQL 的高性能查询为查询还原的数据分配额外的计算资源。目标表提供基础源数据的视图，但不会影响它。

Important

还原开始时即开始计费，并持续到你删除已还原的数据为止。查询完成后立即关闭还原操作。有关成本详细信息，请参阅还原定价。

以下 Azure CLI 示例使用了 az monitor log-analytics workspace table restore create 命令。它将源表中的数据时间范围还原到新的目标表中。使用 --name 参数设置的目标表的名称必须以结尾 _RST。

# Set variables
resourceGroupName="<ResourceGroupName>"
workspaceName="<WorkspaceName>"
tableName="<TableName>_RST"
restoreSourceTable="<SourceTableName>"
startRestoreTime="2026-01-01T00:00:00.000Z"
endRestoreTime="2026-01-08T00:00:00.000Z"

# Create the Log Analytics workspace restore logs table
az monitor log-analytics workspace table restore create \
  --resource-group "$resourceGroupName" \
  --workspace-name "$workspaceName" \
  --name "$tableName" \
  --restore-source-table "$restoreSourceTable" \
  --start-restore-time "$startRestoreTime" \
  --end-restore-time "$endRestoreTime" \
  --no-wait

注意

Azure CLI命令使用当前 CLI 上下文中的Azure 资源管理器终结点，因此无需在命令语法中指定 management.chinacloudapi.cn。

以下Azure PowerShell示例使用 New-AzOperationalInsightsRestoreTable cmdlet。它将源表中的数据时间范围还原到新的目标表中。使用 -TableName 参数设置的目标表的名称必须以结尾 _RST。

# Set variables
$resourceGroupName = "<ResourceGroupName>"
$workspaceName = "<WorkspaceName>"
$tableName = "<TableName>_RST"
$sourceTable = "<SourceTableName>"
$startRestoreTime = "2026-01-01T00:00:00.000Z"
$endRestoreTime = "2026-01-08T00:00:00.000Z"

# Define parameters for New-AzOperationalInsightsRestoreTable
$newAzOperationalInsightsRestoreTableParams = @{
    ResourceGroupName = $resourceGroupName
    WorkspaceName     = $workspaceName
    TableName         = $tableName
    SourceTable       = $sourceTable
    StartRestoreTime  = $startRestoreTime
    EndRestoreTime    = $endRestoreTime
}

# Create the Log Analytics workspace restore logs table
New-AzOperationalInsightsRestoreTable @newAzOperationalInsightsRestoreTableParams

注意

Azure PowerShell cmdlet 使用当前 Az 上下文中的Azure 资源管理器终结点，因此无需在 cmdlet 语法中指定management.chinacloudapi.cn。

以下 REST 示例使用表 - 创建或更新 REST API 操作。它将源表中的数据时间范围还原到新的目标表中。目标表的名称必须以 _RST 结尾。

在请求正文中包含以下值：

名称	类型	说明
`properties.restoredLogs.sourceTable`	字符串	包含要还原的数据的表。
`properties.restoredLogs.startRestoreTime`	字符串	还原的时间范围的开始时间。
`properties.restoredLogs.endRestoreTime`	字符串	还原的时间范围的结束时间。

恢复表状态

该 provisioningState 属性指示还原表操作的当前状态。 API 在启动还原时返回此属性，稍后使用 GET 表上的操作检索此属性。该 provisioningState 属性具有以下值之一：

值	说明
正在更新	正在执行还原操作。
成功	还原操作已完成。
正在删除	正在删除已还原的表。

示例请求

本示例将数据从 2026 年 1 月从 Usage 表还原到名为 Usage_RST的表。

PUT https://management.chinacloudapi.cn/subscriptions/{SubscriptionId}/resourceGroups/{ResourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{WorkspaceName}/tables/{TableName}_RST?api-version={apiVersion}
Authorization: Bearer {AccessToken}
Content-Type: application/json

{
  "properties": {
    "restoredLogs": {
      "sourceTable": "Usage",
      "startRestoreTime": "2026-01-01T00:00:00.000Z",
      "endRestoreTime": "2026-01-31T00:00:00.000Z"
    }
  }
}

响应

状态代码：202 已接受。

查询还原的数据

在 Azure Monitor 中查询已还原的表时，请使用目标表名称（以 _RST 结尾）。还原的日志保留其原始时间戳，而不是还原操作的时间。根据最初生成数据的时间设置查询时间范围。

按以下任一方式设置查询时间范围：

在查询编辑器顶部的“时间范围”下拉列表中选择“自定义”，并设置“从”和“到”值。

在查询中指定时间范围。例如：

let startTime = datetime(01/01/2026 8:00:00 PM);
let endTime = datetime(01/05/2026 8:00:00 PM);
TableName_RST
| where TimeGenerated between (startTime .. endTime)

忽略已还原的数据

弃用已恢复的数据意味着删除目标 _RST 表以停止恢复计费。不再需要还原的表时，请将其删除。

删除还原的表不会删除源表中的数据。

注意

只要基础源数据可用，还原的数据就可用。当您从工作区中删除源表，或者源表的保留期结束时，数据会从还原的表中删除。但是，空表仍会一直保留，直到你明确将其删除。

还原注意事项

Azure Monitor中的还原操作具有以下约束：

支持的表套餐：Analytics 和 Basic。不支持辅助计划。
最小时间范围：每次恢复至少需要两天的数据。
最大数据量：每次还原最多 60 TB。
并发还原：每个工作区最多同时执行两个还原过程。
每个表只能有一个正在进行的还原操作：如果某个表已存在正在进行的还原操作，则对该表运行第二次还原会失败。
每周限制：每个表每周最多 4 次还原。

恢复定价

还原日志的成本取决于还原的数据量以及还原处于活动状态的持续时间。还原处于活动状态的每个 UTC 日内，价格为 每 GB 每天。

密钥定价规则：

最小数据量：每次恢复 2 TB。如果恢复的数据量不足 2 TB，仍按 2 TB 收费。
最短持续时间：12 小时。如果还原处于活动状态的时间不足 12 小时，仍将按 12 小时（0.5 天）收费。
部分日计费：在第一天和最后一天，仅对还原处于活动状态的一天部分进行计费。
无查询费用：由于还原的表使用 Analytics 计划，查询还原的数据没有额外费用。

有关定价详细信息，请参阅Azure Monitor定价的“日志”选项卡。

成本示例

情景	已还原的数据	Duration	每日计费量	计算
大规模恢复，持续多天	5 TB（500 GB/天× 10 天）	直至关闭	5,000 GB	5,000 GB × 每 GB/天的价格 × 活跃天数
小规模恢复，持续多天	700 GB	直至关闭	2,000 GB （最小值）	2,000 GB × 每 GB/天的价格 × 活跃天数
大型恢复，1 小时	5 TB（兆字节）	1 小时	5,000 GB	5,000 GB × 每 GB/天的价格 × 0.5 天（至少 12 小时）
小型恢复，1 小时	700 GB	1 小时	2,000 GB （最小值）	2,000 GB × 每 GB/天价格 × 0.5 天（至少 12 小时）

Last updated on 2026-08-28