I am seeing snapvault lags are more than 30 days. I thought of updating by snapvault update <desination filer name>:<qtree path>. Here I am not sure how it'll create base line. I have more than 30 days snaps in source. How can I update in this case.
Also can anyone explain difference between snapvault update and snpvault start -r -S sourceqtree destinationqtree commands.
Solved! See The Solution
snapvault update will only work if you have the (snapvault) snapshots on source and destination...
try: snapvault update <desination filer name>:<qtree path>
if this throws an error, then you might have lost one of the snapshots you need to update. then try the beasline with start -S ...
snapvault start -S is there to initialize a snapvault relationship (baseline transfer)
The -r option tells the secondary to restart updates from a different primary path.
Most often, this command will be used after a snapvault restore to tell the secondary to restart updates from a qtree that was previously restored from the secondary to a primary. It may also be used after a primary data set is migrated to a new primary volume.
Hope this helps,
Thanks for your reply
In my case I have (snapvault) snaps on both source and destination. I'll do snapvault update.
1.Wheter I'll have old snaps in destination?
2. What will happen instead of snapvault update if I do snapvault start -r -S source destination with existing relation (here am not changing different primary path)?
1. In snapvault the source snapshots stay where they are, only with Volume SnapMirror these snapshots are getting transfered.
2. If you enter this command, it will give you an error, that the qtree you want to initialize is already in a relationship. You would need to provide a new path/qtree to get it working.
I have 60 days old snapshot(snapvault) in source. and updated with command (snapvault update destination) it created new baseline snashot with todays date.
but i want that 60 days old snapshot(snapvault) in source to be snapvaulted to destination. so that I will have last 60 days data(snaps) in destination as well?
correct me if I am wrong here
This is one of the common misunderstandings with snapvault...
With snapvault you have the source volume/qtree (data you want to backup).
And you have the destination volume/qtree where the backup data shall be written to (sort of like a tape).
you have local snapshots on the source (snapvault snap sched ..... )
and you have snapshots on the destination (snapvault snap sched .....)
in addition you create snapvault snap scheds to transfer the data from the source to the destination (with the -x parameter) and in order to be able to transfer the data, snapvault creates or uses snapshots to do this.
e.g. snapvault snap sched -x source:/vol/qtree destination:/vol/qtree sv_daily .....
So you define the snapshot retention on the source, then on the destination and the transfer schedule, thats it!
Excerpt from the manpage:
The third configuration step is to establish the SnapVault snapshot schedules on the primaries and the secondary with the snapvault snap sched command. A snapshot schedule in a volume creates and manages a series of snapshots with the same root name but a different extension such as sv.0, sv.1, sv.2, etc. (For snapshots on SnapLock secondary volumes, the extensions are representations of the date and time the snapshot was created rather than .0, .1, etc.). The primaries and secondary must have snapshot schedules with matching snapshot root names. On the secondary, the -x option to the snapvault snap sched command should be set to indicate that the secondary should transfer data from the primaries before creating the secondary snapshot. If -x is set, when the scheduled time arrives for the secondary to create its new sv.0 (or sv.yyyymmdd_hhmmss_zzz for SnapLock volumes) snapshot, the secondary updates each qtree in the volume from the sv.0 snapshot on the respective primary. Thus, the primaries and secondaries need snapshot schedules with the same base snapshot names. However, snapshot creation time and the number of snapshots preserved on the primary and secondary may be different.
Very interesting read.
What are the causes of high lag times?
We have a large estate of highend filers, most new - but I'm seeing lots of high lag times on multiple volumes.
Would really like to understand the causes... (been looking at various docs, but I'm non-the-wiser )