Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
owbsljtdb02:/ dcbsnap02:/vol/ossv_backup01/obsljtdb02
dcbsnap02*> snapvault release / dcbsnap02:/vol/ossv_backup01/obsljtdb02
/ is not a valid primary path.
usage:
On a snapvault primary:
snapvault release <primary_path> <secondary_filer>:<secondary_path>
On a snapvault secondary:
snapvault release <secondary_path> <primary_system_path>
where <primary_system_path> is <primary_system>:<restored_path>
ideas short of destroying the volume? I'm just starting with OSSV so it's no big loss, however is a typo occours in the future, how would I fix this? So far no amount of escaping the / worked.
Solved! See The Solution
1 ACCEPTED SOLUTION
migration has accepted the solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aah. If the source hass already released the relationship then you can simply do
snapvault stop /vol/ossv_backup01/obsljtdb02
to remove the QTree and delete the backed up data
-Michael
8 REPLIES 8
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Your primary path is something like FILER:/vol/volumeXY/qtreeZ, or in the case of OSSV, something like SERVER:/C:/
If in doubt, just copy/paste the output of "snapvault status"
-Michael
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I did copy the output. it fails.
it doesn't believe a simple "/" is a valid path.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think there's something wrong with what you pasted here. It says that your primary path is "owbsljtdb02:/" and your secondary path is "dcbsnap02:/vol/ossv_backup01/obsljtdb02". But snapvault release tells you that the first argument should be the secondary path and the second argument the primary.
So I *think* you have to type
snapvault release /vol/ossv_backup01/obsljtdb02 owbsljtdb02:/
on your filer (sorry, but I don't have an OSSV system here to test at the moment)
-Michael
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
dcbsnap02> snapvault release /vol/ossv_backup01/obsljtdb02 owbsljtdb02:/
/vol/ossv_backup01/obsljtdb02 owbsljtdb02:/: No release-able destination found that matches those parameters.
Use 'snapvault destinations' to see a list of release-able destinations.
I think I found "yet another bug"..... argh. might crack open a case with support.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
could you try it with only the secondary path? as in
filer> snapvault release /vol/ossv_backup01/obsljtdb02
also, maybe post the output of "snapvault status" and "snapvault destinations", too.
I don't think it's a bug, this would be a rather big one and thus it would be noticed almost instantly
-Michael
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
the output is in the orignal post
owbsljtdb02:/ dcbsnap02:/vol/ossv_backup01/obsljtdb02
I tried it all the various combo's you can. can't release it on the secondary side. the primary side has released it already.
migration has accepted the solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aah. If the source hass already released the relationship then you can simply do
snapvault stop /vol/ossv_backup01/obsljtdb02
to remove the QTree and delete the backed up data
-Michael
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ppfffftttt...
that works.
argh. Thank you.
