Stubbing and DFSR

Last post 10-02-2019, 11:53 AM by scrossle. 3 replies.
Sort Posts: Previous Next
  • Stubbing and DFSR
    Posted: 10-01-2019, 4:52 PM

    I understand that Microsoft doesn't support the replication of Commvault stub files.  Is there anyone that's using stubbing with DFSR and if so, how are you getting around the replication issue?  Are you restoring stubs to the replicated site?  Commvault is highly recommending that we don't mess with the stubs but I was curious if anyone has a viable solution in place to work around the replication limitation.  What are the risks if we start restoring all the stubs to the replicated site?  Any insight would be greatly appreciated.


     - Bill

  • Re: Stubbing and DFSR
    Posted: 10-01-2019, 5:37 PM

    Don't do it.

    Here's what happens:

    1. Replicated file is stubbed on server A

    2. File is detected as deleted/removed from replication on server A

    3. Deletion is replicated by DFSR to server B

    4. File is deleted on server B.

    5. Deletion is replicated back to server A and the original stub is deleted!


    If you are doing a one-time replication for a server migration, you could do an out-of-place Commvault restore of stubbed files to the destination (use a filter to select only stubbed files) but I haven't had much luck with DFSR and stubs.

  • Re: Stubbing and DFSR
    Posted: 10-01-2019, 6:58 PM

    If I'm understanding you correctly, basically what you're saying is that since DFSR can't replicate the stub to site B, DFSR detects a difference (Stub at site A) and subsequently circles back deletes the stub?  Have you actually observed this behavior or this just theoretical?

    What we were considering was the possibility of a scheduled out of place restore (stubs only) to the replicated site.  Sounds like it may not be worth pursing and potentially catstrophic. (All your stubs getting deleted)



    - Bill

  • Re: Stubbing and DFSR
    Posted: 10-02-2019, 11:53 AM

    Yes, I've observed this behavior, with the following caveat:

    It's been several years so my recollection may be slightly different - I don't recall specifically whether it removed the files outright, or just stripped off the reparse point data that made it a valid stub, leaving a corrupted file in its place (on all replica members).  It was a Bad Thing, regardless, and involved restoring from a bunch of different replica members based on which one had performed the most recent backup.  Fun times!

    The only way I can see your proposal working, is some way of having DFSR exclude stubbed files entirely from replication, and/or telling CV not to stub files within folders being DFS-Replicated.  However, based on my understanding of DFSR, it does not currently provide this functionality.  (Revisiting the DFS-R documentation just now has confirmed this - one can filter files based on name/folder or extension, but not attributes or reparse point existence.)

    The way we have handled this is to have specific folders/shares for which replication is necessary (software distribution shares, for example) placed in a subclient for which stubbing/archiving is not enabled.  In fact, since these folders are typically replicated from a central point, we actually do this only on one primary core server, and on the branch servers we just exclude the software distribution folders entirely from commvault.

    The corollary of this is that if you are replicating a folder from server A to server B (or worse, to B and C and D and...), and stubbing it everywhere, different files will get stubbed at different times on different servers and the damage will increase exponentially based on the number of replica members... it gets really bad, really fast.

    - Shaun

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.
Copyright © 2020 Commvault | All Rights Reserved. | Legal | Privacy Policy