This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Unallocated Space

How does Quest deal with unallocated space on a volume? Will it just ignore it?

We have one server with a very large primary partition and nothing on it but the OS. I would like to shrink that and leave the unused space as unallocated. One big reason for doing this is if/when I need to recover it I will not need to recover to an even larger partition than it is now.

Thanks

  • The unallocated space should be just ignored as it does not contain any blocks that change and a method to keep track of them. Moreover, shrinking the volume should not trigger a base image (unless some specific issues are encountered). Such issues may arise if you use non-MS partition management software to shrink the volume and a lot of data is moved during the process.
  • The unallocated space should be ignored like Tudor said. However, one caveat that I think is worth double checking is that the volume can be restored to a disk that is smaller than the original disk. Last time I checked the size of disk needed for restore needed to match the size of disk on the original machine. It's not based on volume size because it's related to the disk geometry. I could be totally off on that, but it sticks in my mind as something we run across every once in a while.
  • Yes the same or larger which is why I wanted to shrink it.

    I have run into this in the past. A recovered machine ended up with a 1TB primary partition because the lost machine had a 300GB one and it would not restore to another 300GB one. (The only servers I had on hand were 300GB and 1TB)

    Are you saying shrinking the primary partition preemptively would not prevent this as Quest would "know" it was originally a 1TB?
  • If you were going to 'shrink' a volume I would personally take/force another base image myself so that I made sure that the core updated/modified the disk parameters so that if/when I went to do a BMR it would see the 'new' size of the partition and not continue to use the previous size. I can't validate off hand whether or not the core does this on its own, however I would personally do this.

    Also, I seem to recall that in recent versions we modified this restriction, the fact of having to go to the same size or larger. I can't say that I have officially seen this in documentation, however I do seem to recall it working. Tell ya what, let me spin up a handful of machines and see if indeed my memory is correct or not and try your situation and I'll get back with the results.
  • Alright, this is what I have found regarding this situation in practice for RR 6.1.3.

    Doing a BMR/rollback to a disk that has less capacity than the protected disk appears to be tied to the operating system of the protected node. For an example, if I tried to do restore to a smaller disk on a machine that was running Windows Server 2008, it would not work, anything that was 2K8 R2 or newer, it would work as long as the new disk had enough space to hold the files being restored.

    So, 2K8 or older the disks have to be the same size or bigger. For restores of 2K8 R2 or newer you can restore to smaller disks.

    Also for the shrink variable, I was not able to restore to smaller disk regardless of OS. I was able to restore the same size (current) or larger. I did not have to go to a disk as large as the original (if that makes sense). So, source was 100 GB, reduced it to 90 GB I am able to BMR to a 90, however nothing below.

  • Thanks a lot for going out of the way on this. This is exactly what I needed to know.

    Thanks All!