Jump to content

Source volume greyed out, skript doesn't work


axelfriedrich

Recommended Posts

Hello,

 

my backup-script doesn't work, because at least one of the source volumes is greyed out.

 

Details:

I _can_ remove the greyed-out entry and add it again, because it exists twice, once greyed out and once not-greyed-out. When doing like this, backing up works. I have to do it nearly everytime when doing a backup and therefore skeduled backups doesn't work for this (these) volume(s).

 

The volumes in question are compressed FAT16-partition (e:\, g:\), another compressed FAT16-partition (f:\) works fine, uncompressed partitions work, too.

 

Using:

Retrospect Pro 6.0 (Windows),

Windows 98SE.

 

Any hints?

 

 

Regards,

 

Axel

Link to comment
Share on other sites

This means that the volume is changing in such a way as to not appear to the be the exact same volume any longer. Retrospect will compare volumes on many criteria, such as name, serial number, size, creation date, block allocation size, etc. to see if volume is the same. If any of these criteria have changed, the volume will be considered different.

Link to comment
Share on other sites

 

Thanks for the good informations. I can (and did) look at those criteria, for example with partinfo.exe (PowerQuest). But with these tools I could get only the informations of the host-partitions (they don't change), not the compressed drives. But even if I would have the informations of the compressed drives, I wouldn't know how to get rid of the problem... . Maybe, it's time to abandon the compressed drives and go to uncompressed drives...

Link to comment
Share on other sites

I have encountered the grayed-out volume problem, too, although the cause was different (I renamed a Windows directory that was defined as a Retrospect subvolume). I use Partition Magic to change partition parameters on a somewhat frequent basis and apparently will have to deal with this problem repeatedly in the future. Please reply on these two concerns:

 

 

1) Concern #2 is a suggestion for a future version of Retrospect. Concern #1 is that some company’s support staffs can’t or won’t forward suggestions to the development staff (I am not aware of Dantz’s policy). Companies that ask users to resubmit a forum suggestion to their suggestion webpage lose the context of the forum discussion and the number of people affected. The forum lets multiple users show that this is not an isolated problem and it deserves review. In fact, I hope other forum users review my suggestion below and improve it.

 

2) Existing scripts that referenced the grayed-out volume will not recognize the proper volume, even if the volume name was not changed. If there are several affected scripts, each script must be found and corrected before it is next used or its backup session will fail. Searching for all scripts and correcting them can be error-prone and time-consuming. Since volume parameter changes and renamed or deleted subvolumes are not uncommon, this problem generates needless work for Retrospect users.

 

If Retrospect detects a change in a volume but the volume remains on the same physical drive with the same volume name, Retrospect should fix the problem automatically and add a message to the Operations Log. Otherwise, Retrospect should report to the user that the volume was not found. Then, it should present the user with a list of volumes on the affected system and allow the user to select the “equivalent volume” or “none of the above”. If an equivalent volume is selected, update the recognition criteria for the volume. Finally, if scripts are linked to volume recognition criteria rather than storing it internally, scripts will automatically recognize the equivalent volume.

 

TIA

 

Link to comment
Share on other sites

  • 2 weeks later...

Concern 1: Feedback, along with feature requests, can be submitted through the following link. The product suggestions forum is a great place for people to post suggestions in a central location that may otherwise be lost in troubleshooting forums. The forums are not an official means of contacting Dantz. Due to post volume and other factors, Moderators may not see threads with feature requests buried in other posts.

 

http://www.dantz.com/en/support/feedback.dtml

 

Concern 2: If the computer container or the client computer is selected as a source, as opposed to selecting individual drives, all drives will be backed up - regardless if they have changed. The container backs up any local drive. If the individual drives are selected as sources, and Retrospect detects that the drive is not the exact same drive that was added originally, there will be an error logged that the drive was not available.

 

This is done for data safety reasons. Imagine if Retrospect backed up - or worse yet restored over - a drive that "looked" similiar but was not actually the drive you originally selected? Drives can have the same serial number and name - yet not be the same drive. Retrospect looks at many criteria to determine if the drive is the same drive - if the drive is different, Retrospect will err on the side of safety.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...