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:
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.
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.
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.
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.
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.