none
Large sync job once per week; Synchronization reports RRS feed

  • Question

  • We are evaluating DPM2010RC on Server 2008R2.  We have several protection groups set up and running, however we also have some peculiar activity on these protection groups.  We currently use Backup Exec for our backups, and while I know that the DPM and Symantec BE are completely different solutions, I can't help but make comparisons.

    With that said, for the 3rd week in a row the synchronization for one of our protected computers is synchronizing about 50GB of "changes."  The entire amount of data on this server is about 80GB.  To make it even more interesting, this large synchronization starts around 2PM every Sunday afternoon.  There is noone in the office at this time, and all synchronizations prior to this are very small.

    Furthermore, I highly doubt that there were 50GB worth of changes on Sunday afternoon when there was no one in the office.  The largest sync job that we see through the week when people are there actively working is about 20MB to 50MB.  So, for there to be 1000 times more data changed on a Sunday afternoon is simply unbelievable.

    With Backup Exec, I can go back and view what files were backed up by an incremental job etc.  I have not been able to find any options within DPM that allow me to see what files were changed or synchronized.  I would like to be able to see what files are being synchronized during these large synchronizations.  Are there any reports or job properties that would enable me to see what files "changed" to trigger them to be synchronized?

    Protection group details:  Server 2003 R2   Replica Volume: 126GB, 80.09GB used | Recovery point volume: 14GB, 1.52GB Used

    Synchronize every 2 hours, Recovery Points: 8am, 12Noon, 6pm.  Retention 10 days. On-wire compression enabled.

     

    Monday, May 24, 2010 4:01 PM

Answers

  • Thank you for the reply Mike.

    It turns out that we do run Symantec Anti-Virus on this server, and there is a full scan job that kicks off at 12 noon on Sunday.  I also just noticed that we have another server that displays the same behavior due to a scheduled symantec anti-virus scan.  I'm willing to look for other 3rd party apps as you suggested, however I am 99.99% sure it's Symantec.

    Server A: Symantec Full scan begins at noon, DPM sync begins at 2PM and picks up 50GB of "changes."

    ServerB:  Symantec Full scan begins at 2AM, DPM sync begins at 4AM and picks up 5GB of "changes."

    I guess the part that baffles me is the fact that DPM only synchronizes 50GB out of 80GB on Server A, and only 5GB out of 10GB on server B.  The Symantec Full scan that runs weekly is set to scan ALL files, so I would think since every file is touched DPM would attempt to backup all 80GB and all 10GB respectively.  But it's hard to tell what Symantec is actually doing during its scan.

    Anyway, it appears that Symantec scanning is to blame here.  I did a little digging, and it appears that Symantec offers up a registry "fix" to suppress the USN modification that takes place during a scheduled or manual scan.  I found the link here:  http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007101816043548   I realize that you cannot fully endorse a reg hack posted by Symantec, but it sounds like you have seen this issue before.  Is this a common issue?  Is this reg fix for Symantec A/V the "fix" that I'm looking for?  Or does Microsoft have a more appropriate workaround for this issue?

    Thank you again for your time!

     

    Tuesday, May 25, 2010 1:50 PM
  • There is no way to supress this from DPM side, as DPM depends on USN journal to check a file is being modified or not, as this only the reliable mechanism to check if a file is changed. If some software un necessary causes events into it misleads to DPM to understand which are genuine vs which are unnecessary. I would suggest to go with the registry setting or any other option to supresses the un necessary USN entries which are not really file data changed events on which the the file need to be re-backed-up.
    Thanks, Praveen D [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, June 7, 2010 11:45 AM

All replies

  • Hello Bruce,

     

    DPM Queries the NTFS Usn Journal to see what files have changed between synch jobs, then should only transfer the changed blocks within the changed files back to the DPM server.  Since the problem always occurs at the 2:00PM Synch on Sundays, something that is scheduled to run every Sunday after 12:00 noon is causing the files to change, or make the files look like different files to DPM.  Check for 3rd party apps like antivirus that might touch all the files on the volume.  If you locate some APPS that do that, change their start times or disable them for a short period until you narrow down the one causing the issue.  

     

    Regards

    Mike J.


    Regards, Mike J [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, May 24, 2010 11:38 PM
    Moderator
  • Thank you for the reply Mike.

    It turns out that we do run Symantec Anti-Virus on this server, and there is a full scan job that kicks off at 12 noon on Sunday.  I also just noticed that we have another server that displays the same behavior due to a scheduled symantec anti-virus scan.  I'm willing to look for other 3rd party apps as you suggested, however I am 99.99% sure it's Symantec.

    Server A: Symantec Full scan begins at noon, DPM sync begins at 2PM and picks up 50GB of "changes."

    ServerB:  Symantec Full scan begins at 2AM, DPM sync begins at 4AM and picks up 5GB of "changes."

    I guess the part that baffles me is the fact that DPM only synchronizes 50GB out of 80GB on Server A, and only 5GB out of 10GB on server B.  The Symantec Full scan that runs weekly is set to scan ALL files, so I would think since every file is touched DPM would attempt to backup all 80GB and all 10GB respectively.  But it's hard to tell what Symantec is actually doing during its scan.

    Anyway, it appears that Symantec scanning is to blame here.  I did a little digging, and it appears that Symantec offers up a registry "fix" to suppress the USN modification that takes place during a scheduled or manual scan.  I found the link here:  http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007101816043548   I realize that you cannot fully endorse a reg hack posted by Symantec, but it sounds like you have seen this issue before.  Is this a common issue?  Is this reg fix for Symantec A/V the "fix" that I'm looking for?  Or does Microsoft have a more appropriate workaround for this issue?

    Thank you again for your time!

     

    Tuesday, May 25, 2010 1:50 PM
  • Hi Bruce,

     

    I think you are right on the money - I would go ahead and apply that change outlined by Symantec and see if that resolves the problem.  I'm betting it does.

     

     


    Regards, Mike J [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, May 25, 2010 3:44 PM
    Moderator
  • There is no way to supress this from DPM side, as DPM depends on USN journal to check a file is being modified or not, as this only the reliable mechanism to check if a file is changed. If some software un necessary causes events into it misleads to DPM to understand which are genuine vs which are unnecessary. I would suggest to go with the registry setting or any other option to supresses the un necessary USN entries which are not really file data changed events on which the the file need to be re-backed-up.
    Thanks, Praveen D [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, June 7, 2010 11:45 AM
  • Just to follow up to hopefully help out anyone else:

    I have applied the registry entry supplied by Symantec on one of the previously mentioned servers, and this appears to have corrected the issue.  I plan to roll this change to our other protected servers before the next scheduled full scan by Symantec Endpoint.

    Tuesday, June 8, 2010 1:47 PM