My take: A better solution than the backup partition.

OK, so as I pointed out in my other thread, the Drobo does not reserve space for the backup partition. If other partitions use up all the available disk space before the backup partition is full, then your backup software will not know you are out of space. And if your backup software is set to delete the oldest backups when it needs space, you have a major problem when this occurs.

So, my solution is to use a fixed size virtual disk (.VHDX or, if 2TB is enough, a .VHD) file and mount that. To insure you are truly reserving space, it must be fixed size. Besides, Drobo warns against creating dynamic volumes on a Drobo. The VHDX format has some advantages over .VHD other than the size limit, so it is the recommended one.

I’m afraid I can’t get into specifics for Mac users, maybe a skilled Mac user will add a response.

For Windows users, a .VHDX/.VHD file can be created and mounted in Disk Management in the Action pull-down. It does, of course, require admin credentials. It also takes a while, so give it time. When it’s done, the new “drive” will appear and be ready to be partitioned and formatted.

One potential problem is that a virtual drive is not automatically mounted at start-up. So here are a couple of ways around having to manually mount it every time, and Google is your friend for more detail:

  1. The VHDMOUNT command is included in the free Windows Virtual Server 2005, but it works only on .VHD files, not VHDX. The installer will allow you to disable installation of everything you don’t need, installing only VHDMOUNT. This is a command line tool, but you can run it in a startup task.

  2. WinVHD is a utility that has a user window interface and is supposed to be able to mount virtual drives at start-up. But, it lies. It can auto mount drives when it runs, but it requires admin credentials, and thus cannot run at startup (though it tries). This works with .VHDX and .VHD. I chose this method after finding that the first doesn’t support .VHDX.

  3. A DiskPart script can be created. Just Google it, it’s more complicated than I care to go into here. This also works with both file types.

All of these require admin credentials to run. The solution is to run them via a startup script or in a task that runs right before your scheduled backup (if you are not using a program that constantly backs up), checking the box to “run with highest privileges.” If you are backing up another computer to the drive, you can add a NET SHARE commend to the script to share the virtual drive. If your backup software already uses the Windows Task Scheduler to run, it probably also runs with highest privileges, and you can just add one of these to the beginning of the task. Examples of how to create startup or scheduled tasks can be found on the web. But if all this sounds too complicated to you, you probably shouldn’t be doing it. I accept no responsibility if you overstep your level of expertise and screw up your computer. It is always best to test your commands in a batch file and/or on-demand script before committing them to a startup script.

There are a couple of caveats to this.

  1. The virtual disk has to be mounted so that the “user” of the backup software can see it. So if your backup software does not run using your logon credentials (check in the task manager to see), then you will have to schedule a task that also runs under those other credentials.

  2. If you are using VHDMount, by default it mounts the VHD and uses a separate “undo” file. That means you have to dismount the drive before the changes are committed to the real file. So, either make sure you do dismount it (making sure to unshare it first, if shared), or use the /f option to change that behavior.

(just linking to your other thread)

Before the Backup Volume support was added, this was exactly the way Data Robotics suggested it be done with Apple’s Time Machine. They even had a Mac app that would let you easily create such a volume.

I ran it this way for awhile on my 2nd gen Drobos, using an encrypted disk image, and it seemed to work fine.

I was hoping with the new backup volume that the space was reserved ahead of time, and you could use it like a physical drive (partitions, reformat, etc.). U have since learned (like you) that it does not, and problems can occur later.

I now am not sure I really understand what is different between a normal volume and a backup volume. My Drobo was originally initialized as a bunch of 1TB volumes, so are they really any different than if I made a Backup volume with a 1TB size?

hi allen, and there was me thinking i was one of the few remaining (cough cough) advocates of the 2TB max volume size per volumes with the benefits of using multiple smaller volumes (if 2TB can be still classed as small) :slight_smile: