Jump to content

Disaster Recovery and 6.5.336


kaikow

Recommended Posts

The readme file for 6.5.336 states:

 

Quote:

Disaster Recovery : Previously, Retrospect’s Disaster Recovery CD could fail under certain circumstances when booting on Windows XP, Windows 2000, and Windows Server 2003 operating systems. To address this issue, Retrospect will no longer save Backup Set Catalog Files on the Disaster Recovery CD for these operating systems. That means that for these operating systems, you will always have to recreate the Catalog File from the storage media during disaster recovery. The Disaster Recovery Restore Wizard will automatically prompt users to recreate the Catalog.

 

 

 


 

Fine, the catalog did not belong there in the first place, as one needs to choose the backup set from which to restore.

 

However, I am concerned about the requirement to

Quote:

recreate the Catalog File from the storage media during disaster recovery

 


 

Will we be able to identify an extant catalog on, say, an interna/external hard, CD-ROM or ZIP drive, or must one be created anew from the media?

Link to comment
Share on other sites

Hi

 

You only have to rebuild if you don't have access to the catalog file. Accessing the catalog on a Zip, hard disk or CD will work just fine. If you have the catalog on CD-R media you may have to copy it to the local hard disk first depending on the operations you want to perform.

 

Nate

Link to comment
Share on other sites

Quote:

natew said:

 

Hi

 

 

 

You only have to rebuild if you don't have access to the catalog file. Accessing the catalog on a Zip, hard disk or CD will work just fine. If you have the catalog on CD-R media you may have to copy it to the local hard disk first depending on the operations you want to perform.

 

 

 

Nate

 


 

 

 

 

 

That's what I thought.

 

 

 

The Retrospect Readme file should state that explicitly, rather than leave us guessing.

 

 

 

I'd have to use the DR to boot to a state in which the CD-RW drive and CD-ROM drives are recognized.

 

 

 

I likely could foprce this to occur by booting the DR CD from the CD-RW drive, instead of the CD-ROM drive.

Link to comment
Share on other sites

  • 4 weeks later...

This afternoon, I created a new DR CD using RP 6.5.336.

 

When I tested the CD, I was NOT gioven an opportunity to choose an extant catalog, instead the DR insisted on building a new catalog.

 

 

I tried to find the Retrospect program so I could drag trhe catalog onto the Retrospect icon, but I could not find where the critter is located.

 

I now see that there is a retrospect.exe in M:\DRWINNT.TMP\system32\retro.

If I had quit Retrospect and then dragged the catalog to M:\DRWINNT.TMP\system32\retro\retrospect.exe, could I have avoided the catalog rebuild?

 

I also noticed that there's obviously a flawed algorithm used to display performance figues during the catalog rebuild.

 

Initially, for several minutes, perforformance as in the range of 900-1200MB/minute.

THen, suddenly it dropped down to around 600MB/minute and started to wildly fluctuate in a sort period of time down to 20MB/min, back up to 500-600MB/min, then back to 120MB/min, and back and forth in a short time interval. So sumptin's not right with the critter calculating performance numbers. It would seem that some code in calculating a continous figure, whilst other code is likely sampling over a short interval, not very useful, n'est-ce pas?

 

Quote:

natew said:

Hi

 

You only have to rebuild if you don't have access to the catalog file. Accessing the catalog on a Zip, hard disk or CD will work just fine. If you have the catalog on CD-R media you may have to copy it to the local hard disk first depending on the operations you want to perform.

 

Nate

 


Link to comment
Share on other sites

Hi Howard,

 

Stop the rebuild and just double click on the extant catalog - that should be enough to register it in Retrospect.

 

I don't know for sure but I suspect the speed fluctuation is caused by Retrospect doing different things during the rebuild. First it copies off the catalog file to disk and then it starts reading the data on the disk to update the catalog file. Depending on the media and bus there could be some fluctuation as well. I would also guess that there is some time when the media is slow or idle while other operations take place.

 

Nate

 

Link to comment
Share on other sites

Quote:

natew said:

 

Hi Howard,

 

 

 

Stop the rebuild and just double click on the extant catalog - that should be enough to register it in Retrospect.

 

 

 

I don't know for sure but I suspect the speed fluctuation is caused by Retrospect doing different things during the rebuild. First it copies off the catalog file to disk and then it starts reading the data on the disk to update the catalog file. Depending on the media and bus there could be some fluctuation as well. I would also guess that there is some time when the media is slow or idle while other operations take place.

 

 

 

Nate

 

 

 


 

 

 

Come on now!

 

 

 

The performance fluctuation I DESCRIBED is obviously a bug in the way that Retrospect calculates the performance figures!!!!!!

 

 

 

The only numbers that matter are the total number of bytes processed in the session and the total time used.

 

 

 

I've not seen Retrospect report the former anywhere.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...