VCF restore fails with "Restore to a different version of the product is not supported" due to a VMSP cluster name conflict
search cancel

VCF restore fails with "Restore to a different version of the product is not supported" due to a VMSP cluster name conflict

book

Article ID: 445670

calendar_today

Updated On:

Products

VMware Cloud Foundation

Issue/Introduction

You may observe one or more of the following when attempting to restore a VCF component backup (vIDB or VCF Automation) — most commonly during a migration or upgrade procedure that requires a backup-and-restore to a new cluster:

  • The LCM restore operation fails immediately with the error:
    Restore to a different version of the product is not supported.
Provide backup path of version: <version>
    For example, for vIDB:
    Restore to a different version of the product is not supported.
Provide backup path of version: 9.0.2.0100
  • The error is thrown even though the backup was created by VMSP at exactly the version shown in the error message.
  • The SFTP backup path contains the correct version folder (e.g. 9.0.2.0100), yet the restore is rejected.
  • Attempting to restore from the .increment backup files produces the same error.
  • Redeploying the component at the base version and re-patching it to the correct version before restoring does not resolve the error.

NOTE: All symptoms must be present for this KB to apply.

Environment

VCF 9.0.x

Cause

The LCM restore pre-check parses the SFTP backup path to extract a version token. It scans path segments and stops at the first occurrence of vIDB or VCF Automation. VMSP generates the backup path using the cluster name (VM_NAME_PREFIX) as the first variable segment. When the cluster name isvIDB or VCF Automation, it appears before the version segment, causing the parser to stop too early and extract a non-version string as the version.

VMSP path template:

/backup/vcf/backups/<cluster-name>/<version>/<component>/<timestamp>/

Example (vIDB, cluster name = vidb):

/backup/vcf/backups/vidb/9.0.2.0100/vidb/2026-06-01T06-28-02Z/

The parser encounters vidb (the cluster name) and stops there, extracting "backups" instead of "9.0.2.0100".

Example (vcfa, cluster name = vcfa):

/backup/vcf/backups/vcfa/9.0.2.0100/vcfa/2026-06-01T06-28-02Z/

The parser encounters VCF Automation (the cluster name) and stops there, extracting "backups" instead of "9.0.2.0100".

In both cases the version mismatch causes the error. This is a defect in LCM. VMSP generates the path correctly as per design; no VMSP configuration change is required.

Resolution

Below workaround restructures the SFTP backup directory so that the version folder appears before the component identifier in the path, satisfying the LCM version check. The steps below use vIDB and VCFA as the example.

Note: This is a one-time operation performed directly on the SFTP server. No changes to VCF Management Services Runtime or the Kubernetes cluster are required.

Step 1 — Locate the existing backup on the SFTP server

  • Log in to your SFTP/backup server and identify the backup path. The path follows the pattern shown below:
/backup/vcf/backups/<cluster-name>/<version>/<component>/<timestamp>/
  • vIDB example:
/backup/vcf/backups/vidb/9.0.2.0100/vidb/YYYY-MM-DDTHH-MM-SSZ/
  • VCF Automation example:
/backup/vcf/backups/vcfa/9.0.2.0100/vcfa/YYYY-MM-DDTHH-MM-SSZ/

Step 2 — Create a symlink with a neutral cluster-name segment

SSH into the SFTP/backup server and run a single command to create a symlink, replacing the cluster-name segment with the neutral name vmsp:

ln -s /backup/vcf/backups/vidb /backup/vcf/backups/vmsp

For VCF Automation:

ln -s /backup/vcf/backups/vcfa /backup/vcf/backups/vmsp

Verify the symlink was created correctly:

ls -la /backup/vcf/backups/vmsp

Expected output (vIDB):

lrwxrwxrwx 1 <user> <group> <date> /backup/vcf/backups/vmsp -> /backup/vcf/backups/vidb

This makes the conflicting path accessible under a name that does not trigger the LCM version-check bug. No files are copied or moved.

If shell access to the SFTP server is not available, copy the backup files manually via your SFTP client from the original path to the equivalent path under vmsp/ instead of creating a symlink.

If the ln -s command fails:

  • ln: failed to create symbolic link '/backup/vcf/backups/vmsp': File exists — a file, directory, or stale symlink named vmsp already exists at that path. Remove it first with rm /backup/vcf/backups/vmsp and then re-run the ln -s command.
  • ln: failed to create symbolic link '/backup/vcf/backups/vmsp': Permission denied — the current user lacks write permission on /backup/vcf/backups/. Re-run the command as the SFTP backup service account or root.

Step 3 — Submit the restore using the new path

In the LCM UI, submit the restore operation using the new path:

  1. Log in to VCF Operations (https://<vcf_operations_fqdn>) as a user with the Administrator role.
  2. Navigate to Fleet Management → Lifecycle → VCF Management → Components.
  3. Under Components, click VCF Identity Broker (or VCF Automation for vcfa).
  4. On the component summary page, click the horizontal ellipsis (⋯) → Backup & Restore → Restore.
  5. On the Restore pane, select Restore from a specific backup and enter the new backup path:

vIDB example:

/backup/vcf/backups/vmsp/9.0.2.0100/vidb/YYYY-MM-DDTHH-MM-SSZ

vcfa example:

/backup/vcf/backups/vmsp/9.0.2.0100/vcfa/YYYY-MM-DDTHH-MM-SSZ

The restore should now complete successfully.

After the restore

  • Remove the symlink once the restore completes successfully: rm /backup/vcf/backups/vmsp
  • Future automated backups will resume writing to the original VMSP-managed path — no further changes to the SFTP server are needed.
  • Post-restore validation steps (SSO, certificates, DNS) are the same as documented in the relevant VCF upgrade guide.

Additional Information

Powered by Wolken Software