DB10 Issue with multiple physical hard drives

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?

 

I raised this issue a week ago in hopes that one of the moderators or Paragon insiders would post a general solution. No such luck.

In the absence of a good solution, here is a solution for those who are willing to hack DB10's scripts. The issue is knowing which of two (or possibly more) drives is which. Assuming that you can identify a partition (volume) label uniquely to one of the disks, code similar to the following will do the trick.

// ===========================================================
// Discern how Windows has numbered the hard drives by finding which
// of the two hard drives holds the system volume C: by matching its volume label
// ===========================================================

if ( VOLUMELABEL (1,0) == "D9100system" ) THEN
select disk 1
ENDIF
ELSE
select disk 0
ENDELSE

This is not a pretty solution, although it could be automated by a script generator. In the VOLUMELABEL procedure, the first argument is the "disk indicator" and the second is the "partition indicator". The scripting language permits a letter or a string for the partition indicator, which might permit a more symbolic solution. However the semantics of those forms isn't stated. Can any Windoze experts explain what identifiers Windoze provides, if any, for the disks themselves other than the positional identifies (numbers) used by Paragon?

The issue seems still wide-open as to whether DB10 really handles scheduling of multiple hard drives properly through its wizards.

 

Note that the "feature" of Windows of randomly numbering hard disks has been around a long time (Windows 2003, XP as well as the later versions noted in my first post) --http://support.microsoft.com/kb/825668/ Surely someone at Paragon has addressed this?

 

I have the same issue and I am surprised as well that there is no solution. All other software I have used does offer the use of drive letters.
The solution with the VOLUMELABEL didn't work either. I use Vista64 and no matter what I tried it never went into the TRUE condition.

However after playing with it for a while I found an even easier solution:

I didn't use select disk at all and only used

select partition <drive letter> e.g. in my case

select partition T

and it does work like a charm. I have 3 internal drives and now it doesn't matter what drive number is assigned at boot, it always takes the correct drive according to the drive letter.

However I would hope that Paragon will change the GUI to allow for that rather to have to manually edit the scripts.

 

As far as I know, this is known issue.

They plan to change 'links' what to backup and where to save backups from 'HDD Number - Partition number' to 'HDD ID (unique & independent from HDD Number) - Partition GUID (unique & independent)'.

This feature is planned to be released in next versions.