Troubleshooting, Log Collection and Escalation
Troubleshooting sequence
-
Identify tenant, workload, product/module, version, enabled service and exact scope.
-
Capture exact sanitised error text/code, activity/incident/correlation ID and timestamp with timezone.
-
Check current releases, compatibility, advisories and lifecycle evidence, current service status and whether the issue is widespread.
-
Confirm prerequisites, plan/policy assignment, service enablement, tenant entitlement and recent change.
-
Check agent/component health, network path, credentials/permissions, source health and destination capacity.
-
Reproduce safely where appropriate; do not destroy evidence or recovery points.
-
Collect the correct system report, logs and screenshots.
-
Document actions already tried and their results.
-
Escalate with business impact, severity, affected scope and required recovery objective.
Diagnostic coverage
-
Acronis system information/report collection
-
Agent/service/component logs
-
VSS and snapshot diagnostics
-
Network/firewall/proxy/TLS verification
-
Storage, Files Cloud and archive access
-
Microsoft 365/Google discovery and permissions
-
Email-security trace, verdict, quarantine and policy evidence
-
DLP, collaboration-security, posture and awareness-training evidence
-
Hypervisor and application logs
-
DR network, recovery-server, runbook and RPO/RTO state
-
EDR/XDR/MDR incident evidence
-
RMM, patch-policy, maintenance-window and reboot state
-
Integration/API/webhook/PSA request, scope, certificate and response evidence
-
Product release, compatibility, lifecycle and advisory state
-
Exact error-code lookup
Use the Acronis Error Code Search and How to Submit a Useful Support Request.
Tier 1 and AI safety boundary
Cloud Sentinel and a Tier 1 analyst must:
-
Use the current SCKB operational evidence for the exact product, workload and version; a current page does not prove that an external vendor fact is still current.
-
Give one safe, reversible check at a time and record its result.
-
Ask only for useful non-sensitive facts and sanitised evidence. Never request passwords, MFA codes, API keys, private keys, payment authentication data, personal data or unredacted logs.
-
Stop before destructive, authority-dependent or high-risk actions such as WMI resets, agent removal, backup-chain deletion, broad firewall weakening, forced reboots, live failover/failback, restores that may overwrite data, credential rotation or security-control disablement.
-
Continue a routine case while a useful safe check remains, but recommend Tier 2 after two documented checks, when the user lacks authority, or when no safe supported check remains.
-
Distinguish vendor capability, enabled tenant entitlement, Soteria Cloud support scope, reseller responsibility and customer responsibility.
-
Treat governance, source-register, legacy and quarantine pages as context only, not as operational procedures.
Escalation boundary
Soteria should not escalate merely because the first search failed. Complete the applicable Soteria triage, establish scope, preserve evidence and provide a reproducible symptom.
Fast-track these conditions:
-
suspected or active compromise, ransomware, data loss or exfiltration
-
a failed live disaster-recovery event or business-stopping recovery
-
production downtime, a broad outage, all-customer impact or multi-tenant impact
-
a confirmed defect requiring vendor engineering
These conditions are important but are not automatically emergencies on their own:
-
an alert-only security event
-
an endpoint that is already isolated with no continuing compromise
-
a failed restore while production remains online
-
a missing recovery point without confirmed active data loss
-
a routine backup, patching, reporting, access, entitlement or integration failure
Escalation records must carry the evidence already collected, checks attempted, their results, business impact, scope, last successful event, recent change, version/build and required recovery objective. Do not make the customer repeat the Tier 1 record.