2009-05-06 12:33 PM
I'm busy setting up Snapvault for the first time.
A number of applications are configured to take snapshots of their volumes manually rather than the filer doing them (via snap sched). These work similar to SnapManager in that they need to make the data crash-consistent before taking the snapshot.
I need to start storing archived copies of these snapshots in a Snapvault secondary. So, I created a Snapvault relationship between the primary qtree and a secondary volume. This all works fine - a baseline copy took place and snapshots were created on both the primary and the secondary. I can successfully issue a "snapvault update" on the secondary to have it copy the deltas from the primary.
What I can't seem to get to work - on the primary or the secondary - is manually creating a snapshot using "snapvault snap create". As far as I can tell the syntax should be "snapvault snap create <volname> <snapname>" but whatever combinations I put for <volname> and <snapname> on the primary or the secondary, I get the following error:
Snapshot creation aborted: snapshot target not configured.
I cannot find any references to examples that may be useful to me. It seems that I'm missing something, possibly something obvious.
Any help would be appreciated!
2009-05-06 12:45 PM
Sounds like you are well on your way to getting SV running. The only thing you need to make sure you do on the destination is run the "snapvault snap sched vol_name snapshot_name retention@-" - for example "snapvault snape sched sv_daily sv_dest 8@-". The reason the snapshot creation is failing on the destination is because you don't have a schedule setup for snapvault. Please note this won't transfer any data - all SnapVault will do is make sure you have 8 copies (in this example) available on the destination. This also eliminates the need to perform snap rename and snap delete commands to handle the retention/rotation of snapshot copies on the destination. Also, you want to make sure you use the "-s" option on your "snapvault update" command to make sure you are updating from the application consistent snapshot you are creating. Also, be sure to have your script run the "snapvault snap create" command after the update since the "snapvault update" doesn't create a snapshot on the destination when it's complete.
So, cliffs notes version:
run the "snapvault snap sched" command on the destination and you should be able to continue.
Let us know if you have any other questions!
Technical Marketing Engineer
Data Protection Solutions
2009-05-06 01:03 PM
Excellent, this is just what I needed! Nowhere have I read that a schedule needs to be in place even to do a manual snapshot. But, having the schedule manage the retention is very useful.
In theory, can I still use a "snap sched" on the secondary to automatically update and snapshot the Snapvault copy? As long as I specify the correct snapshot name? The application can perform its work and then the secondary can request the update a half hour later without having to manually run anything on the secondary.
2009-05-06 01:13 PM
The best practice would be to disable the snapshot schedule on the destination system (the "snap sched" one). You should use the "snapvault snap sched" on the destination in it's place. This will help make sure you don't hit the snapshot limit on the volume, or have mutliple snapshots of the same data. Also, if you want (not required), you can do the same on your source system - where you would use "snapvault snap sched" in place of "snap sched". This would also eliminate the need to do any of your own retention/rotation of snapshots on the primary system. Also, please note that you can use the "snap sched" command (hourly, nightly, weekly) created snapshots.
2009-09-16 01:51 PM
Be carefule of one little gotcha with snapvault. Make sure that if you update the snapvault snap sched that you add the -x argument to the command. If you modify it after the initial create don't forget to modify it on the source as well. If you dont' it will still work but the latency will cause you to tear your hair out till you have that oh yeah moment.
2009-11-11 07:57 AM
may i know what is the command to check the snapvault schedule ?
if i trigger this command, this is what is coming out.
junex-sim2> snapvault snap sched
create vault_vol 0@-
2009-11-11 08:37 AM
You check the schedule with snapvault snap sched.
junex-sim2> snapvault snap sched
create vault_vol 0@-
vault_vol = volume name
0@ = equals the # of snapshots
- = when they are taken, in this case never
Here is one of mine:
To view a specific volumes snapvault snap sched:
eden> snapvault snap sched A_nfs1
create A_nfs1 0@-
xfer A_nfs1 sv_daily 30@mon-sun@3
This means that I create the snapshot as sv_daily, and it increments them as sv_daily.0 so forth and so on. I retain them for 30 days. Only create them mon-sun (all 7 days of the week). I transfer them at 3 am.
The snapvault snap sched command won't do anything without having already had a snapvault start issued against to create the destination qtree.
To change the schedule after its been started use the following:
Snapvault snap sched modify -x
You MUST use the -x argument!
So it would look like this using the parameters below:
Vol = A_nfs1
Snapshot name = sv_daily
Changing duration to mon-fri and lowering number taken to 22
Transferring at 5am
Snapvault snap sched modify -x A_nfs1 sv_daily 22@mon-fri@5
NOTE*** This must also be done on the source. You don't have to retain the same number of snapshots on the source as the destination.
Questions? Drop me a line.
2009-11-11 08:44 AM
Quick clarification here.
"snapvault snap sched -x" should only be used on the destination. The "-x" means that you are creating a transfer schedule - it tells SnapVault to get the data from the SnapVault primary system. SnapVault won't actually attempt this transfer until 5 minutes after the hour - this gives the SnapVault primary system 5 minutes to create the snapshot which is more than enough time to make sure the snapshot is created, and will account for any possible clock differences (the schedule is initiated based off the local system clock of the NetApp system).
On the source system, you would just run a "snapvault snap sched command". That command will only create a snapshot (along with the name, time and retention specified). Since the data resides on the primary system, the -x isn't required and shouldn't be used since it will then attempt to transfer data.