Welcome to Microsoft Q&A!
Thank you for providing the details.
Based on the behavior described a gap in Cluster Performance History can be expected if the components responsible for collecting or storing performance data were unavailable during the maintenance window. However, maintenance mode itself is not documented as deleting previously collected performance history.
Performance History is collected automatically and stored locally within the S2D cluster. It is a recommendation reviewing performance history alongside event logs and storage configuration data when investigating S2D performance-related issues.
1. What the missing data may indicate
- Missing samples only during node or cluster downtime
This is generally expected. If the cluster nodes, Health Service, or Cluster Performance History components were unavailable during maintenance, no new samples could be collected for that interval.
- History resumes after maintenance completes
This typically indicates a temporary collection gap caused by component unavailability rather than a monitoring pipeline failure.
- History remains missing after the cluster is fully online
This is not expected maintenance behavior and may indicate that the Health Service or related Cluster Performance History components did not recover correctly. Internal S2D guidance recommends verifying Health Service status when investigating post-maintenance issues.
- Previously available historical data is also missing
Verify the selected timeframe and retention granularity first. While older samples may be consolidated over time, the loss of a continuous block of previously available data is not typically explained by normal retention behavior.
2. Recommended validation
After all cluster nodes have returned to service, verify that performance data is actively being collected:
# Confirm that new measurements are being collected
Get-Cluster | Get-ClusterPerf -TimeFrame LastHour
# Check Health Service
Get-ClusterResource -Name Health |
Format-List Name, State, OwnerNode
# Check cluster and storage health
Get-ClusterNode
Get-StorageSubSystem
Get-StoragePool
Get-VirtualDisk
Get-PhysicalDisk
Get-StorageJob
It is a recommendation collecting performance metrics, storage configuration information, and relevant event logs when troubleshooting S2D performance issues.
Next, verify that no nodes or disks remain unintentionally in maintenance mode:
Get-ClusterNode |
Format-Table Name, State
Get-PhysicalDisk |
Where-Object {
$.OperationalStatus -match 'Maintenance|Removing' -or
$.Usage -eq 'Retired'
} |
Format-Table FriendlyName, SerialNumber,
OperationalStatus, HealthStatus, Usage
Please notes that nodes or disks left in maintenance mode can prevent normal storage operations from resuming and may affect recovery following maintenance.
3. Review logs around the maintenance window
Generate a cluster log covering the affected period:
Get-ClusterLog -UseLocalTime -Destination C:\Temp
Review the following logs for warnings or errors during and immediately after the maintenance window:
- Microsoft-Windows-FailoverClustering/Operational
- Microsoft-Windows-StorageSpaces-Api/Operational
- Microsoft-Windows-StorageSpaces-Driver/Operational
- System
- Health Service-related events (if available)
Microsoft-Windows-StorageSpaces-Api/Operational is identified as a useful source for validating storage maintenance mode transitions and Health Service behavior during maintenance activities.
For additional validation, collect Performance Monitor (PerfMon) data as an independent comparison. I recommend gathering performance metrics alongside event logs and storage configuration information when troubleshooting S2D environments.
4. Interpreting the results
- If data stops during maintenance and resumes shortly after the cluster returns online, this is typically consistent with a temporary collection gap caused by component unavailability.
- If all performance series exhibit the same gap, this is more indicative of a cluster-wide interruption affecting the Health Service, Performance History collector, or underlying history storage.
- If only a specific node, disk, VM, or volume is missing data, focus the investigation on that object's availability, ownership, and health state.
- If no new samples appear after maintenance has completed, investigate a potential Health Service or Cluster Performance History recovery issue.
- If
Get-ClusterPerfreturns current data but Windows Admin Center does not display it, investigate the management or presentation layer before assuming the underlying collector has failed. - If both Cluster Performance History and an independent PerfMon/logman collection stopped during the same period, look for a broader interruption involving cluster services, storage services, or maintenance automation.
- If only Cluster Performance History stopped while independent performance counters continued to collect data, focus troubleshooting on the Health Service and Cluster Performance History components.
In short, if the missing data aligns exactly with the maintenance window and collection resumes afterward, the behavior is generally consistent with temporary collector unavailability and does not, by itself, indicate a monitoring pipeline failure.
However, if performance history does not resume after maintenance completes, or previously retained history has disappeared, further investigation should focus on the Health Service, maintenance recovery state, and cluster/storage logs to determine whether a Cluster Performance History collection issue has occurred.
Reference: Troubleshoot Performance Issues in Storage Spaces Direct - Windows Server | Microsoft Learn
I hope this information helps. If you find the response useful, please click Accept Answer.
Thank you for using Microsoft Q&A.