Skip to content

Fix issue when restoring backup after migration of volume #12549

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
DaanHoogland merged 9 commits into from
Feb 13, 2026
Merged

Fix issue when restoring backup after migration of volume #12549

Changes from 1 commit
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
f51e048
Fix issue when restoring backup after migration of volume
Pearl1594 Jan 29, 2026
348c9ee
use the backed volume path to get the right location of backed volume…
Pearl1594 Jan 30, 2026
101e2a0
fix logic to prevent take backup from failing
Pearl1594 Feb 2, 2026
896bae2
address comment
Pearl1594 Feb 4, 2026
fe764c0
fix
Pearl1594 Feb 5, 2026
6f23a2d
properly point to the right source and destination volume paths durin…
Pearl1594 Feb 6, 2026
a626760
Fix backup path (after migration) for single volume restore and refactor
abh1sar Jan 30, 2026
f21d493
use backup backed volume param to get backup path
Pearl1594 Feb 10, 2026
6164d41
reference backup's volume info
Pearl1594 Feb 12, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion plugins/backup/nas/src/main/java/org/apache/cloudstack/backup/NASBackupProvider.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -215,7 +215,7 @@ private BackupVO createBackupObject(VirtualMachine vm, String backupPath) {
public boolean restoreVMFromBackup(VirtualMachine vm, Backup backup) {
List<Backup.VolumeInfo> backedVolumes = backup.getBackedUpVolumes();
List<VolumeVO> volumes = backedVolumes.stream()
.map(volume -> volumeDao.findByUuid(volume.getUuid()))
.map(volume -> volumeDao.findByUuid(volume.getPath()))
Copy link
Copy Markdown
Contributor

@sureshanaparti sureshanaparti Jan 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the new uuid or path after migration needs to be updated in the backed-up volumes metadata if any backups existing for them? any case path might also change?

Copy link
Copy Markdown
Contributor Author

@Pearl1594 Pearl1594 Jan 29, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new UUID / path for the backed up volume doesn't need to be updated as the uuid - points to the volume UUID - which is always the same on subsequent backups, and the path points to the backup path - which shouldn't vary even if volume is migrated. I don't see the path of the backup changing.

Copy link
Copy Markdown
Contributor

@sureshanaparti sureshanaparti Jan 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
.map(volume -> volumeDao.findByUuid(volume.getPath()))
.map(backedVolumeInfo -> volumeDao.findByUuid(backedVolumeInfo.getPath()))

it's better change to backedVolumeInfo to avoid confusion.

@Pearl1594 Correct, path of the backup doesn't change. I mean, the volume path after migration might change as the volume is checked by its backed up path (which is before migration). cc @abh1sar

Copy link
Copy Markdown
Contributor

@abh1sar abh1sar Feb 6, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should not have path in the backed-up volumes metadata at all.

  1. Backup files are named suing the volume uuid
  2. The path in backed-up volumes is not being referenced anywhere apart from UI

volume.getPath() already gives us the path where we have to restore. I don't see a point in maintaining it in backup metadata also and updating it whenever volume path changes.

There was a PR merged on main that makes the UI reference uuid instead of path. (#12156)
So I propose removing path entirely from Backup.VolumeInfo in the main branch. We don't need upgrade handling also. The path in the DB for older backups will simply get ignored.

Now in the context of this PR, we should get the path from volume.getPath() not from backup-up volumes metadata.

Thoughts? @sureshanaparti @Pearl1594

Copy link
Copy Markdown
Contributor Author

@Pearl1594 Pearl1594 Feb 6, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With respect to this statement:

Now in the context of this PR, we should get the path from volume.getPath() not from backup-up volumes metadata.

I think we need to consider backedVolume.getPath() - as a volume could have gotten migrated and the path changes. But when restoring from a backup, we need to reference the path of the backedVolume (which was the path of the volume prior to the migrate operation). Correct me if I'm wrong.
If volumeUuid is passed, then volume's uuid is used, but, when null, it uses the backupVolume path to determine the backup file as seen in : https://github.com/apache/cloudstack/blob/main/plugins/hypervisors/kvm/src/main/java/com/cloud/hypervisor/kvm/resource/wrapper/LibvirtRestoreBackupCommandWrapper.java#L224-L225

Copy link
Copy Markdown
Contributor

@abh1sar abh1sar Feb 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should not have path in the backed-up volumes metadata at all.

  1. Backup files are named suing the volume uuid
  2. The path in backed-up volumes is not being referenced anywhere apart from UI

Please disregard my last comment as backups files are named using the volume path, not uuid.
So we need to store the path in the backed up volume metadata.

Comment thread
DaanHoogland marked this conversation as resolved.
Outdated
.sorted((v1, v2) -> Long.compare(v1.getDeviceId(), v2.getDeviceId()))
.collect(Collectors.toList());

Expand Down