Removable Source Clobbering??

[rkylin]

We are running Retrospect 6.1 (MacOS 10.4) as our backup server. It has two external firewire cases in which hard-drives can be mounted. We run backup server scripts so that each potential drive that may be inserted has its own script, and its own backup set (file set).

 

So:

scriptA looks for driveA (in removable tray 1) and backs up to setA,

scriptB looks for driveB (in removable tray 1) and backs up to setB.

 

However inserting driveA backs up to setA and setB. In fact, if you have scriptA open (viewing) it shows the source as driveA. But if you then insert driveB, scriptA changes, saying it will back up driveB.

 

Is the device (firewire box) actually the thing remembered, and not the volume name? How can I force Retrospect to remember the volume name?

[Mayoff]

Make sure the source does not contain the local disk container (desktop container). The script sources should only list the individual disks you would like to back up.

[rkylin]

I verified that the source does not contain the local container. When we add a source, we click on the drive icon within the desktop container.

 

We actually have many removable (slides into firewire tray) drives we back up this way. It seems there are sub-sets that somehow get grouped together, and Retrospect is not differentiating between them although they have different drive names. These drives are all Windows XP drives, it that is important.

 

Also, when viewing sources it seems the normal behavior is that if a removable drive that is a source for a script is not mounted, the drive is still shown, just grayed out. However, for these un-differentiated drives, it seems to only remember the most recent in the group that was mounted (again, like Retrospect is having trouble differentiating).

 

Is there some hidden name or attribute on the Windows drives that Retrospect is actually triggering on other than the volume name?

[Mayoff]

Retrospect looks at the disk size, name, block allocation size and probably the creation date.

 

Are the disk creation dates/times the same?

 

I have never seen Retrospect get confused by 2 different hard disks, but I have never tried using Windows formatted disks on my Mac, which I would never recommend doing with Retrospect.

 

If these 2 disks are used as destinations for Retrospect, you REALLY need to format them for Mac, so you don't run into more problems in the long run.

[rkylin]

The Windows disks are being used as source only. I know unix systems, in general, don't write to NTFS. I'll have to check what the disk creation date looks like to the Mac.

 

Is there anything else I can do/test/try to illustrate what is happening? The only problem is I have no network or data-transfer ability between the backup machine and the internet.

[CallMeDave]

IIRC, disk size is the most possible confusing factor. Check and see if they're the same.

[rkylin]

I am positive many of our disks are the same size. What is IIRC?

 

If the disk size similarities are causing problems, what can I do to help retrospect recognize the disks as individuals?

 

Thanks

[CallMeDave]

What is IIRC?

 

If the disk size similarities are causing problems, what can I do to help retrospect recognize the disks as individuals?

 

 

Re-partition the disk to add a small, unused partition. Easy in Disk Utility on the Mac, likely equally doable on a Windows machine.

 

Dave

[rkylin]

.. A little more information.

 

In the MacOS finder, there is no creation date, and the modified date is April 24, 2009!

 

It seems odd that Retrospect would trigger on the drive size rather than the partition name. Especially considering there aren't that many different drive sizes, and typically are ordered in bulk (for commercial use).

[CallMeDave]

It seems odd that Retrospect would trigger on the drive size rather than the partition name

 

Retrospect generally doesn't use name to track stuff; in fact, I was quite surprised to see Robin list it as one of the criteria for Sources. I'm pretty certain that names are not used at all to track folders that have been defined as a Retrospect Subvolume.

 

Imagine having a well tested and functioning backup strategy, with scripts to access specific Sources. All is working well, and backups are reliable and consistent. Then one day, for whatever reason, a name is changed. Maybe a trailing space is added, maybe a user on a client machine decided to add some personalization. Suddenly, and without warning to the backup administrator, that Source is no longer valid or found. Not a Good Thing.

 

So instead (for Subvolumes), Retrospect uses the Unique File ID assigned by the operating system, allowing names to change while Retrospect continues to find/use the originally defined folder.

 

I suppose physical/logical volumes don't have this ability, so other identifiers must be required to make things unique.

 

Dave

(who is out of his depth on the specifics here)

[rkylin]

So maybe we should not back up entire disks, but just the major folders on the disk (especially since we can't restore a bootable NTFS partition anyway).

 

If there are two identical hard drives, with the exact same file structure, do you know if the unique File ID assigned by the operating system will be different between the two identical drives ? This would be good because then my problem is solved.

[CallMeDave]

If there are two identical hard drives, with the exact same file structure, do you know if the unique File ID assigned by the operating system will be different between the two identical drives ?

 

Do I know? No, I do not.

 

But I believe that the assignments are random, a belief I draw from my experiences using the program.

 

Perhaps someone else here will have some actual technical information regarding the processes involved.