Forum Discussion

Stanleyj's avatar
Stanleyj
Level 6
12 years ago
Solved

hard link or reparse point change detected

I just started recieving this error on a 2003 file server backup job that is only backing up 3 small directories.

NOT using change journal data for <C:\Program Files\GFB>: hard link or reparse point change detected

I've read thru the following post but it doesnt provide a real answer as to how this all the sudden started happening.

https://www-secure.symantec.com/connect/forums/accelerator-cant-use-journal-hard-link-or-reparse-point-change-detected

I know the backups are still ok even though there not using the change journal but i would like to get them back working and see what could be causing this.

There should not be any mount points on this server and i tried running all the commands that the post refrences and nothing shows any mount points withing these directories.

Master: 2008 R2 7.5.0.6

Media server : 2.5.3 5200 appliance

Client: Server 2003 (7.5.0.6)

Change journal enabled, Accelerator enabled, client side dedup is enabled.

  • Opened a ticket about this issue and support said this looked to be a timeout issue with the pauses caused by the clientside deduplicaton.

    "As the clients are on a WAN connection I am going to assume there is a Firewall between sites?  This issue looks like a known connection timeout due to the delay in sending packets to the media server and the firewall closing the connection due to an idle timeout.

    The problem you are facing matches this Technote: http://www.symantec.com/business/support/index?page=content&id=TECH206337

    You can change the TCP Keepalive time out as per this HowTo: http://www.symantec.com/business/support/index?page=content&id=HOWTO56221 can you first check this setting, if it doesn't exist can you set it to 15 minutes as in the document? - This will be on the client and media server."

    I changed the client settings and didnt see much of a difference and i asked our network engineer to check firewall settings and he confirmed they had not changed in years as far as the timeouts go.

    So next i decided to try and clean up some backup data.  i removed 4gb worth pictures from the backup locaton and viola no more issues.

    I know shrinking the amount of data to be deduped over a WAN link will always improve things (especially pictures) but its all i could figure out.
     

  • I am guessing you have only seen this recently?

    These messages seem to have appeared in 7.5.0.5 and remain in 7.5.0.6 and are informational

    As you want to use the Change Journal then perhaps a Forced Re-Scan will help, but if this server is being archived by EV then that may prevent the change Journal from being usable.

    If it is not archived by EV then perhaps it has a change journal error and disabling and re-enabling it folllwed by a forced re-scan backup may resolve it for you

  • You are correct.  I just updated to 7.5.0.6 and the client as well and then i started seeing this message.  This server is not being archived by evault but I did find something very interseting about 5 minutes ago.

    I decided to create a new policy (from a copy of the existing) and when i run it strangly enough no reparse error messages appear??

    In the original policy i have 25 servers all identical with the directores being backed up and OS and only this one paticular machine has issues.

    Is it possible for policies and client names to corrupt like this after doing an upgrade?

  • Stanley

    If you create a new policy it will have created a new track log (similar to if you do a forced re-scan) for that policy (The track logs for accelerator go by name, policy etc.)

    It may have been that the track log did not cope with the upgrade and a forced re-scan on any that have issues (or deleting the track logs from the client) will resolve it for you.

    Hope this helps

  • Thanks buddy.  I will give the forced rescan a try and see what happens.

  • Attempted a forced rescan and still getting errors.  I did discover if i turn client side deduplication off that the jobs complete successfully.

    With Client side deduplication on I get the following error.

     Info bpbkar(pid=780) accelerator sent 10166069760 bytes out of 10116006912 bytes to server, optimization 0.0%
    9/6/2013 3:40:49 PM - Info bpbkar(pid=780) bpbkar waited 38463 times for empty buffer, delayed 175662 times.  
    9/6/2013 3:41:46 PM - Critical bptm(pid=13654) sts_close_handle failed: 2060019 error occurred on network socket    
    9/6/2013 3:41:46 PM - Critical bptm(pid=13654) cannot write image to disk, media close failed with status 2060019 
    9/6/2013 3:41:47 PM - Info nbuappl01(pid=13654) StorageServer=PureDisk:nbuappl01; Report=PDDO Stats for (nbuappl01): scanned: 9879810 KB, CR sent: 0 KB, CR sent over FC: 0 KB, dedup: 100.0%
    9/6/2013 3:41:47 PM - Critical bptm(pid=13654) sts_close_server failed: error 2060005 object is busy, cannot be closed  
    9/6/2013 3:41:55 PM - Info bptm(pid=13654) EXITING with status 87 <----------       
    9/6/2013 3:41:59 PM - Info bpbkar(pid=780) done. status: 87: media close error      
    9/6/2013 3:41:59 PM - end writing

    nbuappl01 = media server

    I actually have a prevouse post that you help me with before that had this same error but in this case those notes are not working.  This almost always means there is a name resolution error but i have confirmed lookups for client, media and master work on both directions from all machines.

    The nbdsu show zero errors when ran from the client and I even went on ahead and put in host entries for itself, media and master but im still getting errors when it tries to send the data back up to the media server.

     

  • Opened a ticket about this issue and support said this looked to be a timeout issue with the pauses caused by the clientside deduplicaton.

    "As the clients are on a WAN connection I am going to assume there is a Firewall between sites?  This issue looks like a known connection timeout due to the delay in sending packets to the media server and the firewall closing the connection due to an idle timeout.

    The problem you are facing matches this Technote: http://www.symantec.com/business/support/index?page=content&id=TECH206337

    You can change the TCP Keepalive time out as per this HowTo: http://www.symantec.com/business/support/index?page=content&id=HOWTO56221 can you first check this setting, if it doesn't exist can you set it to 15 minutes as in the document? - This will be on the client and media server."

    I changed the client settings and didnt see much of a difference and i asked our network engineer to check firewall settings and he confirmed they had not changed in years as far as the timeouts go.

    So next i decided to try and clean up some backup data.  i removed 4gb worth pictures from the backup locaton and viola no more issues.

    I know shrinking the amount of data to be deduped over a WAN link will always improve things (especially pictures) but its all i could figure out.