in our setup for volumes with no qtrees using /vol/volname/- or /vol/volname as the source made no difference it still backed up all volume data to the snapvault qtree. you still have the issue of a snapvault restore will result in a directory with the name of the vault qtree in your primary volume and you would have to mv that data out to its original location.
if you want to keep the "one click" restore with snapvault but still use individual flexvols you can create a somewhat redundant qtree but not bother with the quotas and other qtree overhead.
ie if you have an oracle raq cluster with 5 instances and you use individual data mounts for each sid mounted as /oradata/SID you could setup your primary volume with a single qtree as /vol/oradata_SID/oradata. yes it is redundant but overall not a huge deal and if one step snaprestore from vaults is that important it is required.
so then your primary to nearstore would look like this, assuming you group multiple db instances into a common vault. obviously if they have different retention and scheduling requirements they would be in unique vaults.
FILER:/vol/oradata_SID/oradata -> NEARSTORE:/vol/oradata_vault/oradata_SID FILER:/vol/oradata_SID2/oradata -> NEARSTORE:/vol/oradata_vault/oradata_SID2 ...
yeah, i don't like qtrees much either but using one without the hassle of quota management is something i can live with and doesnt limit my ability to shrink/grow or add extra management overhead.
--daniel
-- Daniel Leeds Manager, Storage Operations Edmunds, Inc. 1620 26th Street, Suite 400 South Santa Monica, CA 90404
310-309-4999 desk 310-430-0536 cell
-----Original Message----- From: owner-toasters@mathworks.com on behalf of Jeff Bryer Sent: Fri 7/18/2008 1:49 PM To: Romeo Theriault Cc: toasters@mathworks.com Subject: Re: snapvault start question
On Fri, Jul 18, 2008 at 03:56:54PM -0400, Romeo Theriault wrote:
- On the snapvault start command you can specify your source (primary)
dataset by these three different options.
- filer:/vol/volname/qtree_name - for a particular qtree
- filer:/vol/volname/- - for non-qtree data in a
volume 3. filer:/vol/volname - for contents of entire volume including all qtrees.
My question is, "Is there any difference between options 2 and 3, if I don't have any qtrees in any of my volumes?".
My understanding was the option 2 only backs up non-qtree data. And option 3 only back up qtree data. We use option 2 mostly as we have very few qtrees.
As I've eluded to in my question above, we don't use any qtrees in our environment. Is the above note saying that when I do a snapvault restore that it's going to restore back into a qtree and I'll have to manually copy the contents out of the qtree back into the root dir of the volume before it will be back to the way it was before the restore? I'm hoping that's not what it's saying, though it sure sounds like it.
Yes that's exactly what it is saying. In our tests we just did a mv (on a Solaris NFS mount) to put everything in the qtree back up a level which is pretty much instantaneous.
If you don't have a license or a filer on which you can experiment, I'd recommend installing the simulator for both secondary and primary Snapvault instances and trying it all out. For us, it made more sense once we could play around than just reading the docs.