I have been trying to implement UrBackup for the last year or so and constantly having problems with VSS. None of the solutions suggested in this forum applied, if not implemented already, doing so made no difference. I have realised that the problem lies with the Drobo disk arrays we use. For those not in the know, Data Robotics have developed a disk array with goes beyond RAID, particularly in flexibility. (It allows the use of drives of different sizes and hot-swapping to replace a drive, e.g. with a larger one.)
This flexibility comes at a price, of course. In order to enable to hot-swap to larger disks, the volume of the Drobo has to be over-resourced (larger than the conceivable physical space it requires). The default volume size is 64TB. Unfortunately, that appears to exceed the maximum volume size of 64TB imposed by Microsoft Windows 10 for VSS to be applied to a volume.
Perhaps this is because 64TB for DROBO means 64x1024^4 and for MS mean 64x1000^4
There appear to be four solutions:
- Reduce the size of the DROBO virtual volume. But if that requires a reformat of the device it takes too long (days to move the data out and in again).
- Increase the Microsoft limit on VSS Volumes. Apparently possible, but, again, would that require a reformat?
- Use a different drive to hold the VSS files. Perfectly possible and, in the long term feasible.
My preferred solution is:
4. Drobo provide for a ‘Backup Volume’ which can be created on the basic drive without reformatting. This is a fixed size volume. I have used it to house, not the backup target as intended, but the backup source. It is not ideal since the size of the volume can only be changed by moving its content, deleting the volume and creating a new one of the desired size and, finally, restoring the content. However, it works now and I have identified the problem, which is not of UrBackup’s making.