Video Screencast Help

Differential Job now Running FULL backups!

Created: 26 Dec 2013 • Updated: 03 Mar 2014 | 6 comments
Grayc's picture
This issue has been solved. See solution.

Here's a wierd situation I'm having:

I'm using BE2012 SP2 and have a backup job that has two methods:  a FULL and a Differential.  This job was created about 3 months ago and ran as I wanted it to until Wednesday of last week.

When I checked the Differential job results that ran Wednesday night, the Differential job was was still in progress.  I found this to be pretty odd since the average Differential run is under 30 minutes and averages about 50 GB in size.  The original fileshare size is 1.2 TB, which takes about 20-22 hours to complete when I run a FULL job over the weekends.

Here's the wierd part:  Now when a Differential job is running, it literally performs a FULL backup of this 1.2 TB fileshare!  The job was not edited or anything.

Does anyone have an explanation as to why this is now happening?  I have another network that this very same phenomenon has started happening on too.

Operating Systems:

Comments 6 CommentsJump to latest comment

Jaydeep S's picture

The Incremental and Differential typically run with reference to the archive bit set on the files. Has anything changed the archive bit settings on your file shares? Antivirus software is where, I would start investigating. Also, is there any onther type of Backup being performed (outside Backup Exec)?

lmosla's picture

In addition to what Jaydeep reccommended  try recreating your job in case it got corrupt somehow.

Also run all of you updates and push out them out to your remote servers

pkh's picture

Where is your fileshare located? If it is on a NAS which does not have RAWS/RALUS loaded, then this behaviour is expected.  Incremental/differential backups are not supported on machines/devices which do not have RAWS/RALU loaded.

In addition to the earlier advice, it is not just the archive bit method that will be thrown off if you have AV scanning.  The modified time method is also affected.

Grayc's picture

Turns out it a Symantec Endpoint Protection (SEP) issue. Everytime SEP runs on the Windows fileshare, it changes the update sequence number (USN) change journal on each file residing on that particular fileshare.

Further research showed that the fileshare server's registry was missing an entry that prevents SEP from changing the USN change journal. The following DWORD was added to our 64-bit server:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Symantec\Symantec Endpoint Protection\AV\NoFileMod

where the value data was set to "1".

pkh's picture

If you had told us that you are using SEP and the modified time method, I would have pointed you to my blog below which document this problem

Grayc's picture

Consulted our server team. The registery was updated.