OSS Backup & Third-Party Tool Integration Diagnosis

Diagnose backup-software integration problems with Alibaba Cloud OSS: "Veeam backup to OSS keeps failing validation", "Synology backup OSS reports V1 signature is forbidden", "rclone sync over the S3 compatible interface deleted my files", "high retrieval fee from backup on an Infrequent Access bucket", "how do I get the Veeam whitelist for my bucket".

Core approach: take the customer-reported tool / error message / symptom / storage class, match it through the embedded tool x symptom attribution catalog to a root-cause direction (signature adaptation, endpoint form, request style, permission mapping, whitelist provisioning, retrieval-fee attribution, or tool usage), and deliver verbatim configuration advice. This skill makes zero cloud API calls and performs no live network probing; all reasoning comes from the catalog distilled from official OSS documentation (S3 compatibility, V1->V4 upgrade, retrieval billing) and 170 matched real support tickets.

Trigger Conditions

Route here when the user reports any of: Veeam backup to OSS fails validation or asks for the Veeam whitelist; Synology / NAS backup reports V1 signature forbidden; rclone or AWS CLI sync over the S3 compatible interface fails or behaves unexpectedly; a backup workload on Infrequent Access / Archive storage triggers a high retrieval fee; or any third-party backup tool integration error against OSS.

User Confirmation

This skill makes zero cloud API calls, so there are no cloud resources to confirm before running the entry script — no bucket ownership, UID, or credential confirmation is needed. The only collection required is the tool name/version and the verbatim error text (plus symptom or storage class when relevant); take everything available from the user's message and run the diagnosis directly, declaring what is still unknown instead of asking up front (see Information Completeness).

Information Completeness

1. Auto-fill first, ask second — never block. Derive every parameter you can from the user's own message (tool name, verbatim error text, symptom, storage class, bucket, region) and run the entry script immediately. Do NOT ask a clarifying question before the first run, and do not demand a complete parameter set; one extra round of questions is acceptable only when the script returns STATUS: FAIL.
2. Declare the gap in the answer, not in a lookup. The final answer MUST carry one explicit line naming every input still unknown (for example: storage class of the billed objects, bucket name, tool version) and what each unknown would change in the conclusion. An unknown is stated as an unknown; it is never silently defaulted and never resolved by touching the cloud (see Absolute Rule 2).
3. Declare the source of every fact. Each fee attribution, endpoint form, signature rule and doc reference in the final answer MUST be traceable to the script output — cite the doc_verification.docs titles/URLs and, when doc_verification.note starts with DEGRADED, state plainly that online doc verification was unavailable.