How Do I rename a qtree in a Protection Manager SnapVaullt relationship?

[bachman]

I have a customer that needs to rename a qtree that is part of a Protection Manager SnapVault relationship. He knows how to rename the qtree and preserve the relationship, the issue is how to do so and have Protection Manager recognize the change and continue to manage the relationship.

Can someone point me to a document or provide information on how this can be done?

Phil

[adaikkap]

Can you get us the output of dfpm dataset list -m <dsname>

Is the customer trying to rename the qtrees in source or in destination ?

Regards

adai

[bachman]

Source. I'm having him get the output.

[reide]

I have the exact same question from a channel partner, but for the destination qtree.  How can they rename it, update the relationship, and make Protection Manager aware of the change.  So if we can answer how to do this for both the source and destination qtree, that would be extremely useful.

I'll get the same output from the partner.

[bachman]

Customer is a pharmaceutical company and as such they have to have documented procedures on how to do this. Since he's documenting, not actually changing at this time, don't have the output of 'dfpm dataset list -m <dsname>'

Can we document how one accomplishes this, one for changing the source, one for changing the destination name, as Reid requested?

[adaikkap]

Hi Phil & Reid,

                         The reason I asked for output is I wanted to know the member of the dataset. Are they volume or the qtree itself on the primary.Also the reason I wanted to know is it a source a destination is because in the secondary  only volume is a member of the dataset. PM/DFM identifies uniqueness of a volume by FSid which does not change in vol rename. Where as that's not the case with qtree.

OK will have it tested and documented for SV and QSM. BTW what is the reason for rename ? What version of DFM are they using ? In OnCommand 5.0 we support the same qtree name as primary in the secondary.

Regards

adai

[reide]

Adai,

In case you still need an example.  The reason they want to re-name the qtree is that they've deleted & re-bulit this relationship, and PM has incremented the name of the qtree with a "1".  They don't want the "1" there as it breaks a NetBackup script they've written to back it up to tape.

C:\Users\jobloc>dfpm dataset list -m "Database Backup Share"
Id         Node Name            Dataset Id Dataset Name         Member Type                                        Name

---------- -------------------- ---------- -------------------- -------------------------------------------------- -------------------------------------------------------
      1305 Production Primary         4082 Database Backup Share qtree                                              opsna1:/ops_p_cifs_backups_1/ops_p_cifs_uf_dbbackups
      1306 Production Primary         4082 Database Backup Share qtree                                              opsna1:/ops_p_cifs_backups_1/ops_p_cifs_ncf_dbbackups
      1307 Production Primary         4082 Database Backup Share qtree                                              opsna1:/ops_p_cifs_backups_1/ops_p_cifs_cf_dbbackups
      1309 Production Primary         4082 Database Backup Share qtree                                              opsna1:/ops_p_cifs_backups_1/ops_p_cifs_drwn_dbbackups
      4049 Production Secondary       4082 Database Backup Share volume                                             opsna3:/opsna1_ops_p_cifs_backups_1

Qtrees created

opsna1_ops_p_cifs_backups_1          unix  enabled  normal

opsna1_ops_p_cifs_backups_1 ops_p_cifs_cf_dbbackups ntfs  enabled  snapvaulted

opsna1_ops_p_cifs_backups_1 ops_p_cifs_drwn_dbbackups ntfs  enabled  snapvaulted

opsna1_ops_p_cifs_backups_1 ops_p_cifs_ncf_dbbackups ntfs  enabled  snapvaulted

opsna1_ops_p_cifs_backups_1 ops_p_cifs_uf_dbbackups ntfs  enabled  snapvaulted

opsna1_ops_p_cifs_backups_1 ops_p_cifs_uf_dbbackups_1 ntfs  enabled  snapvaulted

Snapvault status

opsna1.tcbna.net:/vol/ops_p_cifs_backups_1/ops_p_cifs_cf_dbbackups    opsna3:/vol/opsna1_ops_p_cifs_backups_1/ops_p_cifs_cf_dbbackups            Snapvaulted    20:43:40   Idle

opsna1.tcbna.net:/vol/ops_p_cifs_backups_1/ops_p_cifs_drwn_dbbackups  opsna3:/vol/opsna1_ops_p_cifs_backups_1/ops_p_cifs_drwn_dbbackups          Snapvaulted    20:43:40   Idle

opsna1.tcbna.net:/vol/ops_p_cifs_backups_1/ops_p_cifs_ncf_dbbackups   opsna3:/vol/opsna1_ops_p_cifs_backups_1/ops_p_cifs_ncf_dbbackups           Snapvaulted    20:43:40   Idle

opsna1.tcbna.net:/vol/ops_p_cifs_backups_1/ops_p_cifs_uf_dbbackups    opsna3:/vol/opsna1_ops_p_cifs_backups_1/ops_p_cifs_uf_dbbackups            Snapvaulted    434:11:27  Idle

opsna1.tcbna.net:/vol/ops_p_cifs_backups_1/ops_p_cifs_uf_dbbackups    opsna3:/vol/opsna1_ops_p_cifs_backups_1/ops_p_cifs_uf_dbbackups_1          Snapvaulted    20:43:40   Idle

[amirm]

I don't think we can rename the secondary i.e. backup as it is the read-only copy of the primary in snapvault relationship.

In case of the primary qtree renaming, it doesn't seems to work either. If you try to relinquish the relationship & rename the primary qtree, the renamed primary qtree doesn't appear in the External Relationship in NMC UI. External Relationship lists only the primary qtree with older name. And hence you cannot import it to existing dataset without re-baselining.

The issue in this sounds similar to the one discussed in the thread:

https://communities.netapp.com/message/59492#59492

Thanks,

-Amir