
removing the old VM LINUX001 and redefining after rescan the same VM LINUX001 lets the job run succesfully. The old VM is "no longer processed" by this job. Displaying the disk backupset for the given jobs shows the old machine LINUX001 with the number of restorepoint it had. the 'new' LINUX001 has started with a new restorepoint. So my questions are whether this enforced a new full for that LINUX001 as this machine is seen as a new object? Hopefully the backuprun is deduplicated against the backupfile it already had. And second the old LINUX001 backupdata sits and waits until the retention of the deleted VM option is reached? I now have 4 restorepoints for the same machine and this will add up as time proceeds. So If I have the deleted VM option set to 1 year, I will get stuck with that even if I just intend to keep 3 versions of a backup.(assuming I run a daily backup, I only keep 3 restorepoints, 3 days...) This can cause a significant impact on the capacity one needs to store the backups. In case of a big restore with multiple VMs involved, this can become a problem when all the restorepoints are kept until the expiration period is reached. The only option might be set the deleted VM option to the lowest possible value (1 day?). But then this option becomes rather useless imo, I kind of see this option more than a grace period to keep your last backups in case of a removed VM and you loose all your previous restorepoints.
It would be better to have an option that can link the new to the old object and manage accordingly. So I now should see only 3 restorepoints, 2 of the old one and 1 of the new one. As new backups run, the old restorepoints get discarded nicely.. Probably not easy to realize but I think mention it anyway. Any thoughts on that?
thanks, Peter