This is a followup to some VSS issues discussed recently in Features at:
http://forum.macrium.com/Topic6417.aspx
Can VSS handle apps that modify several files?
Perhaps Reflect could help detect possible inconsistencies in Backups and Images where files were modified near the time of a VSS (or other kind of) snapshot.
(1) Reflect might allow sorting, by column, of the "Files backed up" list provided for file backups. A user could view the modified timestamps of the files included in the backup to help spot files backed up near the time of a snapshot.
(2) A few new options in Reflect defaults would help spot potential problems very easily:
Other Tasks | Edit Defaults ... | Advanced | VSS options
[x] Flag backups containing potentially inconsistent files
[x] Files modified up to __ milliseconds prior to a snapshot
[x] Files modified up to __ milliseconds after a snapshot
The user could specify the window. (Or, Reflect could assume some useful window, like 1/2 second, or 10 seconds, or something that seems reasonable. But I think any user who employs this option would be in the best position to know if they want more or less aggressive flagging by Reflect.)
Backup summaries are currently marked successful (white checkmark in a green circle) or failed (white X in a red circle). If the flagging I suggest were enabled, they could now additionally be marked potentially suspect, with a white question mark in a yellow circle; and the backup summary text could explain the reason, i.e. that some files were modified within the window specified in the defaults.
Perhaps the full pathnames of the files that were modified in that window could also be listed in the html summary, and the files might also be bolded in the "Files backed up" list that is provided for file and folder backups.
This could help considerably during file system restores - a user could check the backup logs to determine what files might require special investigation, and possibly restore from an older image or backup, rather than have to review every possible file after a restore, or manually check modified timestamps in the backup or in restored files vs. the snapshot time.
Users backing up systems that run very high-activity databases that are VSS-aware, or have journalling or transaction rollback (those are probably essentially synonyms), or some other way of recovering from inconsistencies would likely NOT want this kind of flagging, but that would be up to them.
(3) Print the snapshot time in the backup summary. I don't know if the relevant time is when the snapshot request is placed, or when VSS returns success to the requesting process, or if VSS informs the snapshot requester of the actual time the snapshot is considered to have happened. Perhaps the best an application can do is print the time the snapshot is requested and the time the snapshot request is completed. I've observed that it takes much more than a few moments for a VSS snapshot to occur. In that case, the relevant window might be a certain period before the snapshot creation starts, and a certain period after the snapshot creation is complete.