Restore logs in Azure Monitor

The restore operation makes a specific time range of data in a table available in the hot cache for high-performance queries. You specify a source table and time range, Azure Monitor creates a destination table (ending in _RST), and you run full KQL queries against the restored data. When you're done, you dismiss the restore to stop billing.

Restore is one way to access data in long-term retention. Use restore to run full Kusto Query Language (KQL) queries against data in a particular time range. Use search jobs to access data based on specific criteria. Also use the restore operation to run queries on any Analytics table when log queries can't complete within the 10-minute timeout.

Prerequisites

To restore data from long-term retention, you need Microsoft.OperationalInsights/workspaces/tables/write and Microsoft.OperationalInsights/workspaces/restoreLogs/write permissions to the Log Analytics workspace. The Log Analytics Contributor built-in role provides these permissions.

Tables with the Auxiliary table plan don't support data restore. Use a search job to retrieve data in long-term retention from an Auxiliary table.

Restore data

When you restore data, you specify the source table and a name for the new destination table. The destination table name must end with _RST. The restore operation creates this table and allocates extra compute resources for querying the restored data by using high-performance queries that support full KQL. The destination table provides a view of the underlying source data but doesn't affect it.

# 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

# 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

PUT https://management.azure.com/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"
    }
  }
}

Query restored data

When you query a restored table in Azure Monitor, use the destination table name (ending in _RST). Restored logs retain their original timestamps, not the time of the restore operation. Set the query time range based on when the data was originally generated.

Set the query time range by either:

• Selecting Custom in the Time range dropdown at the top of the query editor and setting From and To values.

• Specifying the time range in the query. For example:

  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)
  

Dismiss restored data

Dismissing restored data means deleting the destination _RST table to stop restore billing. Delete the restored table when you no longer need it.

Deleting the restored table doesn't delete the data in the source table.

Restore considerations

The restore operation in Azure Monitor has the following constraints:

• Supported table plans: Analytics and Basic. The Auxiliary plan isn't supported.
• Minimum time range: At least two days of data per restore.
• Maximum data volume: Up to 60 TB per restore.
• Concurrent restores: Up to two restore processes per workspace at the same time.
• One active restore per table: Running a second restore on a table that already has an active restore fails.
• Weekly limit: Up to four restores per table per week.

Restore pricing

The cost of restored logs depends on the volume of data you restore and the duration the restore is active. The price is per GB per day on each UTC day the restore is active.

Key pricing rules:

• Minimum data volume: 2 TB per restore. If you restore less, you're charged for 2 TB.
• Minimum duration: 12 hours. If the restore is active for less, you're charged for 12 hours (0.5 days).
• Partial-day billing: On the first and last days, you're only billed for the part of the day the restore is active.
• No query charges: Querying restored data has no extra cost since restored tables use the Analytics plan.

For pricing details, see the Logs tab on Azure Monitor pricing.

Cost examples

Related content

• Configure data retention and archive policies
• Run search jobs to access archived data