topic Re: Does Primary Data to be Snapvaulted to another location have to be in Qtrees? in ONTAP Discussions

Does Primary Data to be Snapvaulted to another location have to be in Qtrees?

davieb1969 — Thu, 05 Jun 2025 06:51:32 GMT

Hi,

I need to SnapVault CIFs and VMware to a secondary location. Can someone provide a definitive statement that source data must be located in Qtrees?

I know for Exchange and SQL when using Protection Manager/SnapManager, data must be in Qtrees, but is this also true for everything else?

The customer already has data located in the root of each volume and I don't want to have to move it.

Thanks,

Re: Does Primary Data to be Snapvaulted to another location have to be in Qtrees?

sowens — Thu, 30 Jun 2011 17:50:21 GMT

You have a couple of different options with SnapVault

For the source volume, you can do

/vol/<vol_name>

The above will backup everything in the source volume including source qtrees to the destination qtree. However, since the data is being backed up to a qtree on the snapvault secondary, the source qtrees will not be recognized as a qtree on the destination.

*NOTE the above example is only valid with SnapVault

The second option is to use a source path of

/vol/vol_name/-

The above will backup everything from the source volume that is *NOT* in a qtree.

Re: Does Primary Data to be Snapvaulted to another location have to be in Qtrees?

adaikkap — Thu, 30 Jun 2011 18:52:15 GMT

That's not a requirement for normal dataset in protection Manager.

The specific case of SME and SQL are because non-disruptive lun restore works only for qtrees, and not volumes.

When a entire volume is added to a dataset in PM its replicated entire qtress inside the volume including the data inside the volume and not in any qtree.

So if you have a volume vol1 with 1 qtree qt1, then PM will create 2 qtree snapvault or snapmirror relationship as follows.

/vol/vol1/-

/vol/vol1/qt1

Regards

adai

Does Primary Data to be Snapvaulted to another location have to be in Qtrees?

davieb1969 — Thu, 30 Jun 2011 18:54:37 GMT

Fantastic Adai, thanks for the helpful information.