Failed on: Determining Data to Send

I see now this Quest RR KB (that I can also not access) that refers specifically to my issue.

support.quest.com/.../117506

More details-

The partition size is incorrect, please shrink the volume.

This error leads to the following unreadable Dell KB-

support.software.dell.com/.../195341

Hi Corrigun,

Please contact our support admins at the "Customer Service Request" section at support.quest.com/contact-support. They will be able to look into why you can't view the KBs. If you have an active license with AppAssure or Rapid Recovery there should be no issue looking at the KBs.

I did and they sent me the KB's. As far as Dell is concerned my Sonicwall contract is only good for Sonicwall support.

It appears the problem is that RR perceives a problem with the partitions "overlapping". The suggested solution is to resize the volumes but I'm not willing to break a production server by resizing a system or reserved partition. Especially when other backup software (including AA) will back up the machine successfully.

I'm working with support and hope to get a solution soon. In the mean time I am open to any suggestions.

What is your support SR#? I'll take a look into it.

The fact that AppAssure was able to take a backup, is actually a problem. The code was changed between AA and RR so that it would block backups in this scenario. The reason being that a backup in AA of a system with a volume offset problem would result in a full restore (export or BMR) failing. This is because the partition is actually larger than the underlying physical disk. So during a restore of the full partition, it would fail since the partition is trying to be written to a disk that is smaller than it is.

A partition offset problem like this simply means that the last volume on that disk is larger than the physical disk and so has logical blocks of data that have no underlying physical component. To fix this, all you should need to do is shrink the last volume on the disk that is failing to backup. Or if this is a virtual machine, expand the disk in your hypervisor (but don't increase the partition size). In the case of a system disk, you usually have a System Reserved Partition and a C volume. Shrink the C volume by the amount of the offset and then it will work. In most cases that shrink only needs to be a few MB.

These partition offset problems are most commonly caused by physical to virtual conversions of the machine. They can also occur in standard windows installations where windows miscalculates (for some unknown reason) and makes the partition larger than it should be.

Hi Tim,

I read the KB which you paraphrase and I understand that a BMR may be out in this instance but I would rater be able to back up and restore granular items and data volumes than to do nothing at all.

In many instances there is a smaller RAID array that is dedicated to the reserve and O/S volumes. This would be the last volume on that disk. Resizing a reserve or system volume on a working physical server is not suggested by anyone that I am aware of and therefore this is not really a solution.

Well, chalk me up as someone who would suggest shrinking a system volume. I've done it on over 100 production systems without any negative consequences. Since Microsoft implemented live disk resizing I've used it a lot and it's a very safe mechanism.

This solution has been around since the early days of AppAssure as we have dealt with backup failures due to partition offset issues. If a block of data is marked as used and it is in that section of the partition that doesn't have underlying physical disk, then the backup will fail (you cannot collect a block of data from a section of disk that doesn't exist). So even if we were to go back and remove the logic that blocks backup of this situation, you may still get a failure at some point that can only be fixed by shrinking the volume.

And now a second server has failed with this same error on a new install. So on this trial run I am 2 for 4 servers. AA was 4 for 4 as is BE13/14

Something is definitely not right. All these servers are nearly identical and were all deployed by the same people at the same time.

For any that may read this in the future:

I installed an agent on an old server set up by the same guys that did the problem servers and lo and behold it also fails with the same error on the same volume. It has to be something they did when they partitioned the arrays because they all seem to do it.

Since the machine was not really in service I tried the live resizing and it seemed to work and reboot. I am transferring the volumes from it as we speak.

Tim's answer and the KB was clearly was right and I was wrong. I do think the KB's should be published though.