Retrospect backs up its own huge temp files -- can this be fixed?

[MrPete]

A new symptom in rev 7.6 has got to be a source of grief to many users. I've not seen any hint that this is being addressed... any possibility it could gain some visibility?

 

This was first raised here.

 

Details:

• Every full NTFS volume backup always contains a large (3GB) temp file created during the backup and deleted before the backup completes.

• If the backup begins at 12:00am, the temp file is generally dated at approximately 12:01am on ALL NTFS volumes to be backed up.

• On drives other than C:, the file name is
  \System Volume Information\nn{xxxxxxx-xxxxx-xxxx} (not the right number of characters) where nn increments on every drive, and xxxxx-xxxx... is usually identical. On drive C:, the nn is another group of {xxxx-xxxx...} characters.

• Drive C: also typically backs up the normal SVI files

 

As far as I can tell, this means that Retrospect Pro backs up an extra 3GB for every NTFS partition after C:, every time. Of course this wastes time and backup space... particularly since these are 100% temp files that do not exist before or after the backup takes place.

 

Can anything be done to eliminate this wasteful process? I'm sure I could create a workaround with fancy filters, but leaving this in place seems to go against the purpose of Retrospect as a usable software tool.

 

Thanks much. Glad to help as possible if further diagnostics are needed.

[MrPete]

I wonder if an partly-effective workaround is possible...

 

Do custom selectors support both "?" and "*" wildcards?

 

If so, selectors could be created for

E:\System Volume Information\??{*

and the same for other drives beyond C:

This would save 3/4 of the junk backups on this system.

[Mayoff]

I have never heard of these files before. I will need to research if this is Retrospect or Windows creating the files.

[MrPete]

Thanks. I can do a bit of debugging here as well with SysInternals tools...

[Mayoff]

Those files may be created by the System Restore feature in Windows. They may also be triggered by the VSS service in windows, which Retrospect does use.

[MrPete]

I'm currently running a backup, with SI Process Monitor tracking any file system interactions on any SVI-related system calls on any drive.

 

Hopefully that would catch it.

 

If not, then it's happening in a windows call triggered by Retrospect... perhaps VSS as you say.

 

Since it didn't happen in 7.5, it must be something that changed in the update.

[Mayoff]

we are looking at how these files can be excluded from all backups.

[MrPete]

Awesome!

 

This does look like a pain-in-the-neck bug. It appears to be some kind of indirect interaction. Possibly VSS. The files are only directly named when Retrospect grabs them for backup. (I.e. *nobody* directly creates and writes these files... yet they get created anyway.)

 

I have a Process Monitor trace if that helps; I suspect the dev's are on the right trail already.

 

THANK YOU!

 

[MrPete]

Comparing the Process Monitor trace to the actual Retrospect backups shows:

 

* The files are created when vssvc.exe does its thing.

* It's indirect: process monitor does not see the filenames described above. It just sees vssvc accessing the SVI folder.

* This time, an extra file in SVI was generated on two (non-C:) volumes: MountPointManagerRemoteDatabase

 

I'd suggest that Retrospect should check the SVI volumes (on all drives) at the start of a backup, and ignore any files that are found after the backup begins.