Error opening Parentvhdfile

Running urbackup server 2.0.38 and on 3/6/17 upgraded to 2.1.19

This urbackup server has close to 50 client servers running incremental image backups only without issue, except for one.

Starting on 3/6/17 the incremental image backups for one volume (H:) started failing because the urbackup server could not find the parent vhd file. All of the other volumes backup successfully.

I attempted to perform a full image backup so that the incremental chaining would start fresh. Here is the output of the server log:

2017-04-07 00:36:27: ERROR: Error opening VHD file
2017-04-07 00:36:27: ERROR: Error opening Parentvhdfile “/mnt/urbackup/SERVER6/Image_H_170305-0127.vhd”
2017-04-07 00:36:27: ERROR: Error opening parent VHD
2017-04-07 00:36:27: ERROR: Error opening VHD file “/mnt/urbackup/SERVER6/170407-0036_Image_H/Image_H_170407-0036.vhd”
2017-04-07 00:36:27: ERROR: Backup failed

Server6 is 2012R2 server running the 2.1.15 urbackup client.

Do I need to move all of the backed up data for the H drive out of the urbackup data location, run a urbackupsrv remove-unknown and then run a full image backup? Or is there a way I can keep the data that is backed up (in case we need it) and get a fresh full backup?

I guess it should be fixed by temporarily disabling synthetic full backups and then starting a full image backup? Is the parent VHD file missing or something else?

You are correct in that the server was setup to perform synthetic full backups. I changed the setting to use full backup #1 and restarted the server process.

When I kickoff a full image backup, it still creates a writable snapshot of previous image backup and then only transfers a small amount of data based on CBT.

Is there a way to get it to ignore any existing images and start with a fresh image and transfer all of the data again from the server?

Sorry - wrong server. This server has ZFS filesystem. According to section 8.5.3 and 8.5.4 of the admin doc full image backups will never happen after the initial because they are disabled. The doc says that for btrfs and raw images which I assume is the same for ZFS and raw images.

Hmm, so since it is now in ZFS/btrfs mode turning off synthetic full image backups should work, shoudn’t it?

It is my understanding (which is probably way off) that if the backups reside on ZFS that the synthetic full backup setting doesn’t matter because it will always to a synthetic full.

No matter how I have the setting set, when I do a full image backup, it takes less than 1 minute and transfer like 50MB of data. If I start with a fresh urbackup server, the first initial full image backup runs for about 4 minutes and backs up 7GB of data. Any subsequent full or incremental backup seems to be based off of that initial backup.

Is this how it is supposed to operate?

Yes, correct, it is always a “synthetic full” with ZFS/btrfs. But in your first post it references VHD files which only happens if images are backed up to VHD files and there it behaves differently and uses the setting.

Yes, my first post was referencing a different server that does not use ZFS. I have made the change there and will test tonight if the backup works.

Sorry for confusing the issue and thank you for the clarification!

If it is always a synthetic full on ZFS, does it make any sense to ever run an incremental? Would it be better to always run a full?

On the server that does not use ZFS that had the problem taking the full image, I changed the full image backups from synthetic full images to full image backup #1 and the full backup worked again!

Thank you!

Restart the service.
That solved our problem.