Can I Exclude Files That Retrospect Generates From The Next Backup?

[13f34d82-a550-484a-8d26-4be05e79aa81]

Retrospect seems to generate files with names of the form {long hex}{different long hex} and put them in the Systems Volume Information folder while doing a backup. The file names have 36 characters between each set of brackets including four hyphens (dashes). Perhaps something to do with open file backup or shadow copy. Depending on the size of the backup, these files can be quite large -- 2 GB or more.

 

First question: am I correct about what is happening?

 

These files are big enough to eat up my external storage pretty quickly and to require more frequent recycle backups. And when backing up a second computer via wireless, the time of the backup can be very long. So unless it is important for those files to be backed up, I'd like to exclude them from the backup. I tried using an exclusion formulated as {*}{*}, but that didn't seem to work.

 

Second question: Is it important to back up such files, and if not, how do I exclude them?

[13f34d82-a550-484a-8d26-4be05e79aa81]

Having no responses, I investigated this issue further, and have at least some partial answers, which I include below in case anyone else has the same issue.

 

By looking inside the doubly hidden System Volume Information folder, I found that it contains several files with names that display as

{8hex-4hex-4hex-4hex-12hex}{another 36-character string with the same structure}. The second set of curly brackets is identical for all the files, and there is also a 64KB file with that name but no curly brackets in the list. The first set of brackets changes, but some of the hex strings repeat. For example, files created on the same date seem to duplicate a couple of the 4hex strings.

 

By comparing the dates and times of creation for those files with the dates and times of Retrospect backups and of events in the Event Viewer, I think that many of these file were created by Retrospect just after the scanning process but before Retrospect starts copying the files to my external drive. I infer that Retrospect may be using Windows' Virtual Shadow Copy Service (VSS) to store copies of the files needing backup so that open files can be copied to the external drive. Apparently Retrospect does not delete these files immediately after the backup, even though I see no further use for them.

 

Some other files in the System Volume Information folder have names of the same structure (including the identical second curly bracket), but do not appear to have been created by Retrospect. Again using the Event Viewer, I think that the Windows System Restore software creates them, probably again using VSS, when Restore Points are created. I don't know whether they are just intermediates to storing the System Restore information elsewhere or are themselves that information.

 

On my computer, the earliest such file was dated July 4, 2011, so something is deleting these files at some point. It may have something to do with how much memory is allocated to System Restore files. On my wife's computer, for example, the dates go back into June and the total memory occupied by these files is much larger. Interestingly, the second curly bracket in the names is the same on her computer as on mine.

 

By trial and error, I found that I can exclude these files from a Retrospect backup by using the exclusion criterion Name "Contains" and specifying the last 12hex characters of the second curly bracket. For some reason, using the whole string including the curly brackets didn't work.

 

So I'm left with two questions:

 

Did I get all this right?

 

Do I risk anything by excluding these big files?

[sparky4460]

Did you ever come to a final conclusion on this subject? I to am finding an enormous amount of space being consumed saving these files. How did you determine the last 12hex characters of the file?

[13f34d82-a550-484a-8d26-4be05e79aa81]

Nobody ever confirmed or denied my guesses on how these files were generated or whether they are important for system security. I still am excluding them from my Retrospect backups, and it saves a lot of time and space. I suppose if I have a big crash and they turn out to be important, I'll be sorry, but I'm willing to take that risk.

 

If you are experiencing the problem in the same way as I did, the file name will stay on the Retrospect screen long enough for you to write it down. If not, you can unhide the contents of the System Volume Information folder by performing the following (scary!) steps (at least in Windows 7):

 

Open Windows Explorer

Navigate to your Operating System (C:) root directory

Click on Organize at the upper left, and then on Folder and search options

Click on the View tab

Uncheck "Hide Protected Operating System Files", answer yes to the scary question, and then click OK.

You should now see a folder called System Volume Information with a little padlock icon.

Try to open that folder.

At this point, you MAY be able to see the curly bracket files; the last 12 hex on mine all show 04046e6cc752 .

But the first time I did this, I had to go through an additional step to unlock and see the contents of the System Volume Information folder.

Because whatever I did seems to have stuck, I can't reproduce it right now. But I think you right click on the folder, click on Properties, click on the security tab, and then give yourself permission to list folder contents. You can also give yourself permission to Read or even Read and Execute, but it is probably best to avoid Full Control. By you, I mean your user name. At some point, a security message came up. When I said to proceed, I got a series of scary messages about proceeding, to which I continued to answer yes. Finally the file names were visible.

When you are done recording the hex, I suggest you repeat the first 4 steps and hide the protected files again.

[Cygnis]

The "Open File Backup" feature does utilise VSS, so I'd guess you're correct about how/why the files are generated.

 

These large "System Volume Information" files never appear in backups of my Windows XP machine, but do on my Windows 7 machines. Perhaps this is due to differences between the two Windows versions in terms of how Shadow Copy works, as outlined here:

http://en.wikipedia.org/wiki/Shadow_Copy#Windows_XP_and_Windows_Server_2003

 

Not sure about whether it's important or useful to keep these files backed up, but I'll post back here if I find out anything of interest.

Edited September 11, 2011 by Cygnis

[sparky4460]

I agree I did not see them on XP machines and Windows 7 machines take much longer to back up. Almost unacceptable. I tried the built in Windows 7 backup which includes a shadow copy and making a complete drive image of all drives and it did it in a fraction of the time. About 20 minutes vs. 4-5 hours on a Retrospect back-up.

 

The million dollar question is whether the files are created just prior to a back-up and they contain important files that must be backed up if you want a reliable restore. However I think you said it is backing up large {} files created from PREVIOUS back-ups. If you do an incremental backup and these are old files that have not changed Retrospect should not be backing them up again but it seems to be. Doesn’t make sense. We need comments from a Roxio engineer on this one. I am not inclined to exclude them until I find out if they are necessary. I have plenty of back-up space I just hate how long it takes.

[phlampe]

Hello All !

 

I have the same problems and questions as you guys. I'm running a Retrospect 7.7 SBS server with Open Files addon, backing up Windows XP, 7, Linux and Mac OS clients.

 

Here are some points I can confirm:

. these files are backed up only on Windows 7 systems, not XP

. they are related to VSS, and are actually the shadow copies files themselves being made by VSS

. I also have files ending with 04046e6cc752: I suppose it could be the ID of the software writer asking for the VSS (either Windows itself or Retrospect ?)

 

 

If you want to have a look at the VSS files, follow what's in these articles:

Controlling Shadow Copies in Vista (and Windows 7!) and Identifying how much disk space is used for restore points in Windows Vista

The vssadmin command works on Windows 7 Pro just like in Vista.

 

 

Now for my suppositions and questions:

. I believe that the VSS files copied by Retrospect are the ones generated during the previous open files backup. For example, a backup made January 7th copied VSS files from Dec 19th and Jan 4th. Some of those files are big (over 5 Gb) and slow down the copy a lot because of the network time transfer involved.

. one of my Windows 7 backup doesn't have any VSS files copied: why ? what should I check ?

 

. my biggest question is if those files are needed by Retrospect in case of a full system restoration ?

-> I don't think so, because it seems that the open files at the moment of the backup are copied correctly (outlook pst files for example), and all the VSS files existing in a backup image are older by several days in my case than the time of the backup itself

-> I don't see in what use case would these intermediate VSS files be needed after a full restoration. Any ideas ?

 

. as a side question, I'd like to better understand how thoses strings between { } are built. The second string seems a constant of {3808876b-c176-4e48-b7ae-04046e6cc752} (that's based on 2 of my Windows 7 Retrospect backups for 2 different computers). The end of the first string seems constant too: 5c260a4d3940

 

Hope this helps, and that some of you might have some ideas or answers,

Best regards,

Paul-Henri