docs(kb): per-VM tenant DR recovery follows snapshot ownership

[CarlRodabaugh]

Summary

Reworks the KB article on per-VM DR recovery for tenant workloads. The original version asserted that a "provider-to-provider" sync gives "no clean handle" to restore one VM without saying why, and it introduced a three-direction sync taxonomy that appears nowhere in the docs.

The argument is now the actual mechanism. A system snapshot exposes two enumerations, View VMs (the host's own VMs) and View Tenants, and nothing below that. Reaching a VM nested inside a tenant means restoring the tenant first, because the tenant reading its own snapshots is what produces both the VM listing and the ability to restore it. That generalizes into the rule the article leads with: you recover one level down from the system that owns the snapshot, and no further.

What changed

• Terminology matches the docs. sync-configuration.md already describes configuring a Site Sync "at HOST level or at tenant level," so the article uses host level / tenant level with Incoming Sync and Outgoing Sync. The invented provider-to-provider / provider-to-tenant / tenant-to-tenant taxonomy is gone, which resolves the terminology question raised in the original reviewer note.
• Added the sizing case that motivates the article. Production at 500 GB RAM hosting a tenant provisioned 200 GB, DR at 128 GB. The tenant recovers fine on the DR side and lands Offline, then will not power on, because assigned tenant-node RAM has to actually be available (add-tenant-resources.md).
• The workaround is walked honestly rather than dismissed. Tenant node RAM can be reduced on the fly, and you are only opening the tenant to restore the VM, not to run it, so the trim can go well below production. The article states what that path involves and lets the reader judge it.
• Dropped the advice to retire the host-level sync. That sync is what protects networking, system settings, and the other tenants. Deduplication on the receiving system means replicating one tenant through both paths costs transfer time rather than capacity, so the article points at 26.1 partial system snapshots to trim the redundant transfer instead.
• Cross-links the existing article Recovering a Single VM from a Remote System Snapshot, which already documents this recovery flow with a destination tenant, instead of duplicating its steps.
• New caveat. A tenant-level sync does not carry the tenant's provider-side allocation: node count and sizing, provisioned storage, assigned external IP addresses.

Retitled to Recovering a Single VM from Inside a Tenant at Your DR Site and re-slugged to per-vm-dr-recovery-tenant-level-sync.

Type

Conceptual / DR topology decision guide

Source

Recurring support pattern across two customer cases. Technical claims checked against system-snapshot-restores.md, tenant-restores.md, tenant-snapshots.md, add-tenant-resources.md, reduce-tenant-resources.md, share-vm-snapshot.md, and sync-configuration.md, and confirmed with Support.

Checks

• validate_frontmatter.py and validate_widget_links.py pass locally
• All eight internal link targets and both section anchors resolve to existing pages that are present in mkdocs.yml nav
• mkdocs build was not run locally (mkdocs is not installed in this environment), so the lychee link job is unverified on my side

🤖 Generated with Claude Code