Recall request "triggered by ADS access"

Last post 02-18-2019, 4:06 AM by jof. 5 replies.
Sort Posts: Previous Next
  • Recall request "triggered by ADS access"
    Posted: 02-15-2019, 6:28 AM

    Can anyone explain what these entries are I am seeing in the logs of Persistent Recovery jobs?

    What does "triggered by ADS access" mean? What is triggering these recalls (which fail to recall)? I'm glad they fail to recall and this seems to be by design, as per last highlighted section below, but I wonder if the triggers can be prevented in the first place? It is clearly not end-user initiated recalls.


    Extract from log:

    CFSDMAPI::RecallFile(222) - Received recall request for E:\Home\IqbalRe\My Documents\4od, stubType=LOCAL (triggered by ADS access)
    2752  e6c   02/13 11:45:56 ###### CFSDMAPIPrivate::RecallFile(328) - Reparse data :
    2752  e6c   02/13 11:45:56 ###### CRecallServiceInterface_Driver::ProcessIRP(477) - Failed to submitd Recall Request for file E:\Home\IqbalRe\My Documents\4od
    2752  e6c   02/13 11:45:56 ###### CRecallServiceInterface_Driver::ProcessPendingIRPS(237) - Failed to process IRP Reparse 2:2:72:2151441:47586623101:144a3f73-ad2a-42d5-a8ac-64d7897afaf5:8770a4450db382d8feece4b68a86e217:2208:896571:0:141E9238-335D-4465-BFA5-E19A54746A58:1023519?E:\Home\IqbalRe\My Documents\4od|1544500027... Error 0xEDDD0000:{CFSDMAPIPrivate::RecallFile(406)/Int.0.0x0-Ignoring recall triggered by ADS access as per configuration}

  • Re: Recall request "triggered by ADS access"
    Posted: 02-15-2019, 8:48 AM

    This link may help with explanation of what could be triggering the jobs. 

    Live Browse, Block-Level Browse, and Metadata Collection
    http://documentation.commvault.com/commvault/v11/article?p=30807.htm

    For block-level restores, in addition to the restore job, the Job Controller launches a persistent recovery job that opens a common pipeline, enabling multiple extent recall requests to be submitted as a group. The default timeout for a persistent recovery job is 24 hours. For block-level restores using the Virtual Server Agent, the persistent recovery job remains open for 24 hours and can be used for subsequent block-level restores that use the same proxy.

     

    ADS= Alternate Data Streams you may want to check that file path highlighted and see if ADS is set in NTFS (thats is windows setting). 

    Additionaly double check the AV exclusions for CV on this server. 

     

  • Re: Recall request "triggered by ADS access"
    Posted: 02-15-2019, 11:04 AM

    Thank you for your response, good to now know what ADS stands for.

    We don't do Live Browse or block-level backups/restores, so don't think that bit is relevant here.

    I've already added relevant AV exclusions for CV on this and other servers, but as we're not doing real-time AV scanning AV is likely not responsible for these triggers I see on a daily basis.

    Not sure I understand what is triggering these ADS recalls still. Your suggestion "you may want to check that file path highlighted and see if ADS is set in NTFS (thats is windows setting)." How do I check this - where exaclty please? And if it is set, should I leave it?

     

     

  • Re: Recall request "triggered by ADS access"
    Posted: 02-15-2019, 11:38 AM

    Hello Jof,

    ADS is the alternate data streams thats supported by windows platforms. When we archive the files, though we backup all the streams of the file, the archiving aspect is applicable to the main data stream of the file. So when an application reads only the ADS of the file, the read comes in but by default we dont recall files when the read is on the ADS streams. Thats why you see that the recall come in but we deny the operation to recall the file. There is a configuration entry that can be turned ON if necessary to recall the file even if ADS is read. 

    As I understand, you dont want recalls happening when the ADS is read. So, recall behaving the way you intended I suppose? Please clarify. 

  • Re: Recall request "triggered by ADS access"
    Posted: 02-15-2019, 11:38 AM

    Hello Jof,

    ADS is the alternate data streams thats supported by windows platforms. When we archive the files, though we backup all the streams of the file, the archiving aspect is applicable to the main data stream of the file. So when an application reads only the ADS of the file, the read comes in but by default we dont recall files when the read is on the ADS streams. Thats why you see that the recall come in but we deny the operation to recall the file. There is a configuration entry that can be turned ON if necessary to recall the file even if ADS is read. 

    As I understand, you dont want recalls happening when the ADS is read. So, recall behaving the way you intended I suppose? Please clarify. 

     

    Regards

    Chitra

  • Re: Recall request "triggered by ADS access"
    Posted: 02-18-2019, 4:06 AM

    Hi Chitra,

    Thank you very much for the explanation. That is correct, I do not want files recalled just because the ADS is read and so it is behaving as I would like. We only want recalls to be successsful if a user is opening the file. What I still do not know is what application is reading the ADS. What is touching these files to cause this? The reason it is bothering me is because in our envir,onment it means that several Persistent Recovery jobs, for different clients, are nearly always running as something is clearly touching these files all the time. I feel this is not normal (I'm aware a Persistent Rec job will stay open for 24 hours). I don't know if having Persistent Recovery jobs constantly running has any negative impact, maybe not, but seems a bit unneccessary. We have AV exclusions in place for CV directories/files/processes, but we are not performing real-time AV scanning on these servers anyway, so I don't think it can be AV responsible for these reads. (The AV exclusions therefore should apply when a weekly scheduled AV scan occurs).

    I guess I may need to use something like Process Explorer to try to determine what is touching these files.

    Your help is appreciated.


    Regards,
    Jo

     

The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Close
Copyright © 2019 Commvault | All Rights Reserved. | Legal | Privacy Policy