Definitely not supported, I have used this trick for a while My key concerns with it are that a USB drive can drop bits though (but so could tape) and any blocks on a NetApp controller are RAID_DP protected, lost write protected, checksumed, etc... but not the image file to other media. So a swing system is always our recommendation...but when not possible.
Some use cases we have seen... like you said where no tape an no swing system (although as mentioned in the forum you need room to write the base mirror as a single file). Other cases are if you have a FAS270 swing system that doesn't support dedup (or a swing system that doesn't support dedup the size of the source system) then you can smtape from the source to a file on the swing system (even if over the dedup size of that system since it write a snapmirror image - so you can still use a controller that doesn't support all the source features when written to an individual file... aka using an older fas like a usb drive) then copy that image back on the target (need 2x the space to do that on each side to hold the image). Another use case is if ndmp backup is so slow (millions of files) and the backup software doesn't support smtape (or if nfs/cifs backup is slow) you can image the volume to one file then back it up (but no single file restore...but still a way to backup with a more painful restore).
I'll post my example from the vsim but with the new smtape commands since store and retrieve were a part of 7g ontap when the other post was listed.
Example with the 8.1 7-Mode VSIM
Source Controller
# create the test volume
vsim-7m-1> vol create test aggr1 2g
# write a file to the volume just to show it arrives on the target
vsim-7m-1> wrfile /vol/test/file1
# create the smtape target volume (could be any volume with room though)
vsim-7m-1> vol create /vol/smtape aggr2 2g
# diag mode and dump the test volume
vsim-7m-1*> priv set diag
vsim-7m-1*> smtape backup /vol/test /vol/smtape/smtape_dump
Target Controller
# create the smtape restore volume
vsim-7m-2> vol create smtape aggr2 2g
# copy the snapmirror image from source to target (USB drive or other controller to copy the file)
host# mount 192.168.150.210:/vol/smtape /mnt/1
host# mount 192.168.150.211:/vol/smtape /mnt/2
host# cp /mnt/1/smtape_dump /mnt/2/
host# ls -l /mnt/2
drwxrwxrwx 2 root wheel 4096 Jun 11 10:54 .snapshot
-rw-r--r-- 1 root wheel 2101248 Jun 11 10:58 smtape_dump
# create and restrict the volume to cascade
vsim-7m-2> vol create test aggr1 2g
vsim-7m-2> vol restrict test
# diag mode and restore the volume
vsim-7m-2> priv set diag
vsim-7m-2*> smtape restore /vol/test /vol/smtape/smtape_dump
Job 7 started.
# check status
vsim-7m-2*> smtape status
Job ID Seq No Type Status Path Device Progress
7 0 Restore Active /vol/test /vol/smtape/smtape_dump 1.632 MB
vsim-7m-2*> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
snapshot_for_smtape.392837df-b3ee-11e1-a8c5-123478563412.0 vsim-7m-2:test Snapmirrored 00:18:38 Idle
vsim-7m-2*> vol status test
Volume State Status Options
test online raid_dp, flex snapmirrored=on, create_ucode=on,
snapmirrored convert_ucode=on,
read-only fs_size_fixed=on
64-bit
# Confirm the file from the source is on the readonly target
vsim-7m-2*> ls /vol/test
.
..
file1
# Write another file to the source then do a snapmirror update to show that there is a common snapshot for update (can snap list and see it too, but test is below)
vsim-7m-1*> wrfile /vol/test/file2
vsim-7m-2*> snapmirror update -S 192.168.150.210:test test
Transfer started.
Monitor progress with 'snapmirror status' or the snapmirror log.
vsim-7m-2*> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
192.168.150.210:test vsim-7m-2:test Snapmirrored 00:00:14 Idle
# after update confirm both files
vsim-7m-2*> ls /vol/test
.
..
file1
file2
