I believe I've seen references elsewhere to this problem , but couldn't find the discussion with a search of the forum today. DB10, in unattended / scheduled mode, uses scripts to specify the operations it needs to do. Which disks or partitions are to be backed up are hard coded by physical disk and partition numbers. For example, we expect normally that disk 0, partition 0 refers to what Windows refers to as drive C: and which we expect to be the first partition on the first physical hard disk. However, a "feature" of Windows (7, Vista and Server 2008 ) http://support.microsoft.com/kb/937251 is that the numbering of hard drives need not correspond to the physical order. Put bluntly, in a multiple drive system, the numbering of hard drives cannot be trusted. C: may reside on what Windows labels as disk 1, not disk 0. This isn't a problem for Windows software, since data is accessed via drive letter. It is a problem for DB10's scripts, because they refer to hard-coded disk number, partition number locations. So I presently find that my job scheduled to back up my system partition C: (physical disk 0, but labeled Windoze disk 1, partition 0) from my first hard disk is in fact backing up my swap file partition (physical disk 1, but labeled Windoze disk 0, partition 0) from my second hard disk. This is not terribly useful. Is there a work-around for this problem?