I think you can just use the "snapvault snap sched" command with either 0 for the count or a - for the time of the day, or even with -o tries=0 to prevent it from actually running the schedule, but manual updates should work as the schedule will be configured.
Yes, I also have read in documentation, that if I specify '-' for days schedule, then no snapshot copy will be created automatically
@day_list is a comma-separated list that specifies the days on which a new Snapshot copy is created for this set. Valid entries are mon, tue, wed, thu, fri, sat, sun. They are not case-sensitive. You can specify a range using a dash (-), for example, mon-sun. The dash by itself means no Snapshot copy will be created automatically. You can create the Snapshot copy manually.
Why don't you just setup (initialize) the relationship and then not create a schedule? 'snapvault snap create' will just create a snapshot... You can trigger that via a script or the like. You will have to also script the removal of snapshots you no longer need as well just using 'snap delete volXXX'.
Perhaps if you tell us what you are trying to accomplish (the "why" behind your questions), we can suggest a different approach that will get the job done.
I think you are a bit confused, so trying to answer your questions is not entirely easy. A snapshot is a snapshot, fundamentally. The contents of the snapshot are dependent on where the data comes from. A Snapvault snapshot is basically the contents of the remote NetApp+ONTap system's comparable snapshot (listing the snapshots will show you if they are "snapvault" snapshots) or last OSSV state. You can configure Snapvault to take a snapshot after the last transfer to keep a sort of checkpoint of the contents of the destination volume over a longer period of time.
Volume snapmirror is much the same, but you have a 1:1 relationship with the contents of the source volume.
Removing snapshots that are not locked is done with 'snap delete -V volXXX' . Snapvault (and volume snapmirror) snapshots that are "busy" are locked until the releationship is broken. This is also true for source snapshots for clone volumes, fwiw.
Still, if you share what you actually are trying to do, you might get more specific help.
And after update snapvault, I need to manually create SnapVault snapshot on secondary storage.
From reference: The snapvault update command does not create a new Snapshot copy on the secondary system. You need to use the snapvault snap create command if you want to create a new Snapshot copy on the secondary system.
SnapVault is more or less a tool to make it easier for users to create specific snapshots and do several tasks that are manually very hard or impossible to do, but in essence, it transfers data as if you would do it by hand, then makes snapshot's as if you would also do them by hand. SnapVault is a tool, using SnapMirror as basis to make things easier for the user. You can perhaps compare it with a map and a navi system for a car. Both show you streets and paths to your destination but the navi system builds on the normal map and adds additional features to make it easier for the driver.
On top of SnapVault, OnCommand is yet another layer of management software, personally I think one that can be very cumbersome and often buggy. SnapVault snapshots and normal Snapshots while basically the same, are differentiated in OnCommand mostly for ease of use for the end user, as this often includes people who do not have the know how to use the command line or access the filer directly for different reasons, it splits these snapshots so they do not get confused. Sometimes this has also to do with access rights and permissions. in some big corporations and environments, the user that is responsible for snapvault backups, might not have access to other normal snapshots.
Also Snapvault snapshots are for the most part incremental snapshots, while the technology behind them is the same, you will not be able to do anything with a snapvault snapshot without the baseline, while "normal" snapshots are for the most part standalone snaps that can be used on their own.
SnapVault uses the same engine as qtree snapmirror to replicate snapshot data with some differences, like the per volume basis instead of a per relationship basis for schedules.
As for your initial question, I'd go with the way Riley already mentioned. Set the tries to 0, this prevents the schedule to run automatically, then you can go on with manually starting the update and depending on your personal preferences on the snapshots continue with snapvault snap.
In normal operation, qtree updates and snapshot creation proceed automatically according to the snapshot schedule. However, SnapVault also supports manual operation. The snapvaultupdate command on the secondary initiates an update transfer from the primary to the secondary for an individual qtree. The snapvaultsnapcreate command begins snapshot creation just as if the scheduled time had arrived. On the secondary, if the -x option for the snapshot schedule is set, the secondary will contact the primaries to begin update transfers for all the qtrees in the volume, just as it would if the scheduled time had arrived.
The whole point of a schedule in the first place, as the word itself aleady says, is to have an automated trigger mechanism that regularly does the snapvault update and snap create for you.
You mentioned the missing option nodes in ZExplorer, but I didn't get the issue for this question, would you mind to elaborate here so we get a better idea of what you feel is missing?
Whe I create SnapVault schedule with tries count specifies to 0 (or any other parameter):