issue with SVM root volume recovery and make-vsroot

[yodablown]

Hello. Having an issue making Vserver root volume recover work with snapmirror in DP mode using make-vsroot on cdot 9.3 .

Its my inderstanding that once the the snapmirror relationship to the root volume is broken and you run make-vsroot against the DP volume that the DP volume becomes the Vservers root and all the volumes of that vserver will remount to the new volume.

From netapp documentation..

Result

When the new volume is promoted as the Vserver root volume, the other data volumes get associated with the new Vserver root volume.

Thats not what happens though. when i make the DP volume the new root it does apear to become the new root but all the junction paths still point to the original as orphaned. i have to unmount and remount them all..

so after running make-vsroot against my dp volume it does become the new root..

luster1::*> volume show -volume vs1_root_dp -instance

                                     Vserver Name: vs1
                                      Volume Name: vs1_root_dp
                                   Aggregate Name: aggr1_node2
    List of Aggregates for FlexGroup Constituents: aggr1_node2
                                      Volume Size: 1GB
                                     Name Ordinal: base
                               Volume Data Set ID: 1053
                        Volume Master Data Set ID: 2161074734
                                     Volume State: online
                                     Volume Style: flex
                            Extended Volume Style: flexvol
                           Is Cluster-Mode Volume: true
                            Is Constituent Volume: false
                                    Export Policy: default
                                          User ID: -
                                         Group ID: -
                                   Security Style: ntfs
                                 UNIX Permissions: ------------
                                    Junction Path: /
                             Junction Path Source: -
                                  Junction Active: true
                           Junction Parent Volume: -
                              Vserver Root Volume: true

But the volumes that were mounted dont move over to it and are inaccesable..

Before new root volume..

Cluster1::*> volume show -vserver vs1 -fields junction-path
vserver volume junction-path
------- ------ -------------
vs1     FS1    /FS1
vs1     FS1A   /FS1A
vs1     FS1B   /FS1B
vs1     FS1C   /FS1C
vs1     vs1_root
               /
vs1     vs1_root_dp

After new root volume

Cluster1::*> volume show -vserver vs1 -fields junction-path
vserver volume junction-path
------- ------ --------------
vs1     FS1    (vs1_root)/FS1
vs1     FS1A   (vs1_root)/FS1A
vs1     FS1B   (vs1_root)/FS1B
vs1     FS1C   (vs1_root)/FS1C
vs1     vs1_root
               -
vs1     vs1_root_dp
               /

Am i missing something here?

Thanks

Lp

[GidonMarcus · Accepted solution]

Hi

according to this article it's expected.

https://library.netapp.com/ecmdocs/ECMP1140387/html/GUID-3A6C32A1-EBE5-4F5C-A3EA-837BF6246A83.html

i been told a few times before not to bother and backup to vservers root volumes. as it's just as creating a new one.  (load sharing is still beneficial for other reasons)

Gidi

[yodablown]

Thank you for the reply. Yes that is the behavior i am seeing. However according to this Netapp document on root server recovery there is no mention of having to unmount and remount. It leads to believe that follow these instructions and your recovered.

Not a very good way to recover if you a lot of mounted volumes. I did test the LS mirror recovery and it works as expected. Why I was told DP was the preferred protection method and why netapp configured our system this way is beyond me.

Thank you.

Restoring a Vserver's root volume

https://library.netapp.com/ecmdocs/ECMP1196906/html/GUID-3A6C32A1-EBE5-4F5C-A3EA-837BF6246A83.html