-S [sec_system:]sec_qtree_path specifies the secondary system and qtree path from which you want to restore the data.
The -f option forces the command to proceed without first asking for confirmation from the user.
The -k option sets the maximum transfer rate in kilobytes per second.
The -r option attempts an incremental restore. The incremental restore can be used to revert the changes made to a primary qtree since any backed-up version on the secondary system.
The -w option causes the command not to return after the baseline transfer starts. Instead, it waits until the transfer completes (or fails). At that time, it prints the completion status and then returns.
The -s option specifies that the restore operation must use the specified(snapname) Snapshot copy on the secondary system.
prim_system is the name of the primary system that you want to restore to. If specified, this name must match the name of the host system.
prim_qtree_path is the name of the primary system qtree that you want to restore to.
For more information about the snapvault restore command options, see the na_snapvault(1) man page.
So the question remains is this by design or do I just not get it how to parameterize the SC to do the third way?
If it just can do the first two options than we need to raise a BURT / FPVR to get this fixed.
SC does not do an incremental snapvault restore, we would have to add an option since this is a separate API. Not sure if we should just do incremental restore and never a full restore, we would need to look at that. Either way SC does not do incremental snapvault restore unfortunately today.
Snapvault restore is also still only supported through CLI so this feature has not fully been integrated either so we are definitely open to suggestions and improvements.