Skip to main content
Solved

FS Archiving agent "Stub" and domain change ?


Marco Lachance
Byte
Forum|alt.badge.img+7

Hi Team,

Just to be sure !

I’m planning a domain change for all the servers at a customer,

I just want to be sure if there is a special gotcha for FS who as Archiving “Stub” on them !

Nothing special to be aware of ?

Thank you,

Best answer by Amey Shevtekar

Hi @Marco Lachance, @Mike Struening 

 

We confirmed in lab domain change for CS/MA/Clients as specified in our documentation should not cause any issue with stubs. You should be able to archive and recall them after the procedure. 

https://documentation.commvault.com/11.24/expert/7022_changing_commserve_computer_name.html

https://documentation.commvault.com/11.24/expert/7034_changing_domain_name_for_clients.html

 

 

For question about acl change, say at file level or at top level directory in which case it is reflected underneath folders/files depending upon inheritance setting will not result in the recall of the stubs. We will actually backup the stub/stubs in next incremental so the changed acl is backed up. Whenever that stub is now recalled in future an user can see the new acl.

 

Thanks,

Amey

View original
Did this answer your question?

8 replies

Mike Struening
Vaulter
Forum|alt.badge.img+23

Hey @Marco Lachance !  Safe to be sure, right?

Nothing to worry about.  As long as the stub is there, it will issue the recall of the file through the Agent installed and perform the restore.  Name resolution happens between client and CS, MA, etc. but is not tied to the stub.


Marco Lachance
Byte
Forum|alt.badge.img+7

Thank you, 

Always better safe than sorry :-)


Mike Struening
Vaulter
Forum|alt.badge.img+23

Always, my friend!!


Marco Lachance
Byte
Forum|alt.badge.img+7

@Mike Struening

 Another one to validate !

If the customer touch the file in any way, like a need to change some file permissions on the root of the file server volumes. If those rights are changed and inherit down to every subfolder, will that pull the archived files back into storage from those folders? I’m pretty sure it will, and if it’s the case, is there a way to change it with GXHSMUtility or other tools without initiating a recall ?


Mike Struening
Vaulter
Forum|alt.badge.img+23

That’s a good question…..my initial instinct is yes as well.  Let me ask someone to confirm for us both!


Mike Struening
Vaulter
Forum|alt.badge.img+23

I got some additional thoughts on this: 

I think that would only happen if it modifies the file itself as it would update the ACLs. If the ACL on the file changes, the whole file needs to be backed up again to include the direct ACL change. However, if the ACL on the file is set to inherit from higher folders, I don't think it would trigger a recall. Would either need to test this or ask dev on what would happen in this situation. I don't think there would be any additional setting to stop this.

I’m also going to get some dev opinions for you.


Forum|alt.badge.img+1

Hi @Marco Lachance, @Mike Struening 

 

We confirmed in lab domain change for CS/MA/Clients as specified in our documentation should not cause any issue with stubs. You should be able to archive and recall them after the procedure. 

https://documentation.commvault.com/11.24/expert/7022_changing_commserve_computer_name.html

https://documentation.commvault.com/11.24/expert/7034_changing_domain_name_for_clients.html

 

 

For question about acl change, say at file level or at top level directory in which case it is reflected underneath folders/files depending upon inheritance setting will not result in the recall of the stubs. We will actually backup the stub/stubs in next incremental so the changed acl is backed up. Whenever that stub is now recalled in future an user can see the new acl.

 

Thanks,

Amey


  • 0 replies
  • August 30, 2021

@Amey Shevtekar , 

Thank you very much for your answer.


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings