Jump to content

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


Recommended Posts

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.



  • 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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites



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.




Link to comment
Share on other sites

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.


Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...