Acronis Telemetry Finds Backup Retry Storms Reflect Persistent Failures
Summary
Acronis’s H2 2025 telemetry analysis links high backup retry counts to persistent failures, not evidence that retries cause errors. It recommends limiting retries, adding delays and alerts, and investigating recurring faults.
Key points
- Acronis reports that policies with 10 or more daily runs generated about 4.7 million errors in October 2025; always_full policies had a 10.01% per-job error rate in that group.
- The article says quota exhaustion (15.9%) and VSS writer failures (11.48%) were leading business-hours failures that retries cannot resolve.
- It attributes 9.11% of business-hours failures to ConnectToPlatformFailedNetwork, noting that recurring connectivity faults may need investigation rather than retries.
- The analysis cautions that higher error rates among policies with more runs reflect selection bias: failures trigger additional runs, so the comparison does not show that retries cause errors.
- It says repeated attempts consume CPU, storage I/O, network capacity, and scheduler resources, and can slow users and neighboring MSP clients.
- Recommendations include limiting retries by backup type, setting delays, alerting when a policy exceeds four runs per day, and investigating recurring failures.
Article Details
- Publisher
- Acronis
- Report Period
- H2 2025; key retry-storm figures cover October 2025
- Scope
- Acronis backup telemetry on retry behavior, failure causes, resource use, and backup-retry guidance.
- Sample Size
- Approximately 1.23 million policy-day combinations with 10+ runs in October 2025, as reported by the article.
- Key Statistics
- Policies with 10+ daily runs generated approximately 4.7 million errors in October 2025.
- The article reports an average of 43 runs per policy-day combination among 10+ run combinations.
- always_full policies in the 10+ run group had a 10.01% per-job error rate.
- SpaceQuotaReachedHard and MemoErrorVssWriterFail represented 15.9% and 11.48% of business-hours failures, respectively; together, 27.38% of all business-hours failures.
- Estimated retry-storm resource waste was approximately 8.8 PB of disk I/O per day and 3–4 PB of network bandwidth per day; these are article estimates.
- Recommendations
- Limit retries by backup type: for example, a maximum of two retries for always_incremental and one for always_full policies.
- Set meaningful delays between retries; the article suggests 20 minutes for always_incremental and 30 minutes for always_full.
- Alert when a policy executes more than four runs in a day.
- Investigate recurring failures and their root causes rather than increasing retry counts.
- Treat policies that fail more than three days in a week as configuration or infrastructure problems.
Vendors
AcronisRetries are a diagnostic signal of policy health rather than an effective treatment: Acronis H2 2025 telemetry shows policies with many retries typically suffer persistent customer-side failures (quota exhaustion, VSSAmazon Web ServicesIndustry guidance (Google Cloud, Microsoft Azure, AWS) treats retries as a controlled response to transient faults and emphasizes limits, observability, and escalation rather than unlimited retries.GoogleIndustry guidance (Google Cloud, Microsoft Azure, AWS) treats retries as a controlled response to transient faults and emphasizes limits, observability, and escalation rather than unlimited retries.MicrosoftIndustry guidance (Google Cloud, Microsoft Azure, AWS) treats retries as a controlled response to transient faults and emphasizes limits, observability, and escalation rather than unlimited retries.
Products
Amazon CloudWatchBackup console and is not exposed as a CloudWatch status.AWS BackupAWS Backup shows why this distinction matters operationally.Azure BackupMicrosoft’s Azure Backup automation guidance states that retryingSQL ServerWindows Server and SQL Server troubleshooting guidance makes the sameWindows ServerWindows Server and SQL Server troubleshooting guidance makes the same