Instant Scan and long-time bugs

[sowen222]

Long-time Retrospect Pro user, I upgraded basically because I want to have a supported product for such a critical function.

 

Reading the FAQ on how Instant Scan works, and in practical use, I've decided to disable it.

 

1) Files that were created and/or modified since the last Instant Scan are not backed up

2) Files that were deleted since the last Instant Scan result in a -1101 error (file not found)

 

I want my backups to be a reflection of my current system status. Also, having to wade through loads of errors-which-aren't-really-errors in my logs make it easy to miss any real errors.

 

What is "Instant" about the Instant Scan, if it is not even an accurate list of the current filesystem? The amount of time it saves in my 3-system, 6 volume configuration is marginal. I fear the Marketing Department has been allowed to take over the developers.

 

I've disabled it by disabling the Instant Scan service on all the clients. It would be really nice if it were an option in the server, instead.

 

Now what I would REALLY like to see is some of the old bugs which have existed since Retrospect 5 to finally be fixed. For example:

 

- when I select multiple snapshots to transfer using cntl and shift, click ok, go back into the list and find different snapshots have been selected.

 

- when I transfer snapshots or backups, identical duplicate files are correctly backed-up only once, but then when I add to the backup set, all the files which since changed location are backed-up again (even though this setting is correctly set in the backup options), resulting in backups which are GBs bigger than they need be.

[bcarter27]

+1

 

This introduces another point of failure, the time-savings is minimal according to my logs, and this FAQ doesn't inspire confidence-

 

--Question: If I think the scan file is corrupted, can rebuild the scan file?

 

Answer: Yes, you will need to first stop the RetroISA process and then you can delete the RetroISAScans directory.

 

 

I want to backup what is on the disk, not what this catalog thinks is on the disk.

 

There should be an option on the server-side to not use Instant Scan when talking to a client. Or there should be an option to disable it client-side in the new client prefs. Logging into each client to disable this service will be time-consuming.

[bcarter27]

To disable the service remotely-

sc \\remotecomputer config "RetroInstantScanService" start= disabled
sc \\remotecomputer stop "RetroInstantScanService"

 

or with psexec on a whole domain-

 

psexec \\* cmd /c (sc config "RetroInstantScanService" start= disabled ^& sc stop "RetroInstantScanService")

[bcarter27]

Does anyone have a command I can push out to the Macs via Apple Remote Desktop to disable and stop this service?

[sowen222]

... and this FAQ doesn't inspire confidence-

 

--Question: If I think the scan file is corrupted, can rebuild the scan file?

 

Answer: Yes, you will need to first stop the RetroISA process and then you can delete the RetroISAScans directory.

 

 

Ya, that's about the point that I definitely decided to disable the service. Indeed, they MUST include the option to disable this in the server rather than have to do each client separately. I suspect during an upgrade of the client the service will be re-enabled, but at least they'll all have to be manually re-checked to ensure they are disabled.

 

But I have critical processes which run on my systems at particular times of the day/week, and I need to know that their output gets backed up. With this Instant Scan service I have no idea of it has done a scan and included the changes by the time I do my backups.

 

In short, Instant Scan is unpredictable and unreliable, so why would any serious system admin want to have it as part of their backup regime? Saving time during the backup, but having it effectively cost time during the restore (because critical files could be missing), is not a trade-off I want to make. Furthermore, with Instant Scan active, I can no longer do backups which rely on files being synchronised over multiple systems (as I can with OFB but *without* Instant Scan).

[arachnaut]

I have disabled the Instant Scan as well, for some of these reasons, but mostly because I didn't want something to run unexpectedly while I am creating a great deal of audio files during recording sessions. I don't want any extra latency or interrupt processing on audio-critical projects. Audio generation is much more critical of DPC and Interrupt latency than any other application, including video.