Unable to substract path on imported disk

[spzsoft]

Hi,
I have an imported disk on section "agents", it is a endpoint 1.5 configuration derived from varius troubles with the endpoint job. I try to delete it from disk or from configuration but I have Always the same error "Unable to subtract path <destination backup folder> from <.vib file>. Elements are differents".
I have the same error if I try to rescan my endpoint repository. The file indicated in the error message not exists in the target folder, it are different and the backup job in the endpoint PC can not finish with success.
How can I delete it ?

Regards Basilio

[Mike Resseler]

Basilio,

From what I can see you are doing the correct steps so it might be a bug. I would suggest that you create a support call, post the case ID (and the follow-up after that) here.

Thanks
Mike

[enrique.frisoli]

I´m getting this error, but when trying offload backups to Blob Storage on Azure,

12/7/2021 15:41:51 :: Failed to offload backup. Error: Unable to substract path C:|Windows|TEMP|VeeamBackupTemp|245d1cf4-2815-4851-b9e6-0da45b43c1e6 from C:|Windows|TEMP|VeeamBackupTemp|8e552a21-3dc7-4a7d-ab00-cf6f583f70f5. Elements are different.

Case Support was opened with number 04897632, but if anyone saw this error before I will appreciate comments.

Tks!!

[PetrM]

Hi Enrique,

I've asked our support team to accelerate the research of your problem.

Thanks!

[keith.jarrell]

I am trying to Run the Support Information Collection Wizard. I am seeing a similar but different failure: Unable to substract path. Roots are different. Was there an answer to this case. I've open case 04976110

[PetrM]

Hello,

Looks like you've faced a different issue that just triggers a similar error, please continue working with our support in order to resolve it.

In the support case above, it turned out that the problem was related to the metadata files for the job in question. Looks like there are 2 ways to address it: to create a new job or backup chain which would simply start over OR to rename the metadata file which basically forces the job to rebuild that metadata file itself. However, I'm not sure that these workarounds are applicable in your case.

Thanks!

[Anguel]

Just updated to VBR 12.1.1.56. Looks like I am getting a similar error:

Code: Select all

Failed to pre-process the job Error: Unable to substract path F:|Backups from O:|Backups|Backup Copy to ROTATED OFFSITE USB|Backup Job MY-PC. Roots are different.  

The job seems to be hanging and I cannot even stop it.
I expect this is due to the offsite disk having assigned letter F: instead of the previous letter O: , so this is not directly connected to Veeam, although the rotated drives repo depends on Windows drive letter assignment which is IMHO not optimal.
Now, when I go to the rotated drives repo properties, the "browse" button for the path (F:\Backups) is grayed out and I cannot change it at all. Is this expected or is there any way to fix this?

[Mildur]

Hi Anguel

Our rotated disk option depend on the correct drive letter when you run the first time a backup to a new disk.
But when the backup runs a second time against a known disk (backup server now knows the disk id), the drive letter can be different.

Now, when I go to the rotated drives repo properties, the "browse" button for the path (F:\Backups) is grayed out and I cannot change it at all. Is this expected or is there any way to fix this?

You can't change the repository settings, but you can change the letter of your drive to F.

If that doesn't solve the issue, please contact our customer support to investigate your issue.

Best,
Fabian

[Anguel]

Thanks Fabian. I think the Windows letter assignment for the USB drive changed from O: to F: for some unknown reason, maybe due to Windows Server Update.
However, I do not understand how the new letter F: instead of O: got into the repo settings. Maybe this happened during the VBR update? I expect a Veeam bug here, what do you think?

[Mildur]

I'm not aware of any known issues. Our support team will be able to confirm bugs after they have investigated the log files.

Best,
Fabian

[Anguel]

Contacted support, case ID is #07143206.
It is even more confusing, because Veeam at some point attempts to access
D:\Backups\Backup Copy to ROTATED OFFSITE USB\
in the logs. D: has never been a rotated drive, it is a DVD-ROM.

[Anguel]

UPDATE:
Unfortunately, support is not helpful at all in this case.
The major problem seems to be that the Backup Copy to ROTATED OFFSITE USB job cannot be stopped, cannot be disabled and cannot be deleted, even after rebooting the server. It also prevents me from deleting the target repository. This job also seems to block other jobs for some reason. Looks like a serious problem, maybe related to this:
veeam-backup-replication-f2/can-t-stop- ... 69207.html

[Anguel]

So I spent a lot of time and did multiple Veeam database edits with DBeaver in order to get this working again. IMHO the whole implemented rotated drive logic is a serious problem - Veeam relies on a specific drive letter first, but then, if the drive letter changes (which can obviously happen anytime on Windows), at some point everything gets out of control and we get different paths in the database that don't match anymore, the "new" wrong drive letter even gets hardcoded into the repo settings. The "Unable to substract path ... Roots are different" starts to pop up not only in the job logs but also in error dialog boxes everywhere in the interface and there is nothing the user can do. This problem then prevents us from stopping the job, deleting the job, even deleting orphaned backups and also from deleting the "bad" repository. After a lot of trial and error I could disable the job through a database edit (see post I linked to above), so at least it did not block other jobs anymore. But this did not solve the problem at all, as I could still not remove the job or the repository - the "Unable to substract path ... Roots are different" chicken-egg problem I described above still occurred everywhere.
Finally, after more trial and error, I ended up doing a full text database search (thanks to DBeaver) for the incorrect path F:\Backups. Only a replace with the original O:\Backups path in each and every place in the DB made things consistent again so I could finally remove the problematic job and repository.
Not sure what is wrong with 12.1 update, but it also had damaged some of my Veeam Agent Free job entries in the database, I also had to manually fix this according to KB4421.
None of these problems could be solved without being able to edit the database, which a user should normally never touch. Also not sure if I should describe my solution to support, as they did not even understand my problem, so I post it here, maybe it will help someone.

[oflores]

Hi, at this moment I too have this same problem, and the support team doesn't help me

[david.domask]

Hi Oscar (oflores),

Can you share your case number here please?

Anguel, I'm sorry to hear that Support wasn't able to help in the way you were hoping -- I checked the case quick and as I see it Support had made a suggestion hoping to avoid database edits, and I am guessing an edit would be next if the steps did not work; fixes naturally through the UI are typically preferable (just cleaner and less busy work for you as we can avoid the db backup + upload, etc), but I understand you needed to get it going. Please do note however that such manual edits are not supported without review by the Support team; your fix seems reasonable and I've done such ones personally, but it's best to confirm with support.

Please do note (for both of you) if you have concerns about the handling on a Support Case, use the Talk to a Manager Button in the case portal. Support Management is fast to respond on these, and it's the best and most correct way to get additional attention if you have concerns on a case. The more details on the concerns, the better they can be addressed.

[Anguel]

One more thing I'd like to add here: Now I use USBDLM form Uwe Sieber to always assign the same drive letter by volume name:
https://www.uwe-sieber.de/usbdlm_e.html
This is great software and the developer has even added support for ReFS formatted USB drives on my request.
Again, it is far from optimal to have to use such workarounds with leading backup software...