Difference between SnapVault and SnapMirror?

What does it mean that SnapVault is a backup solution?

Below diagram can help - 

SnapVault

Example has few assumptions:

• we’ve got filerX in one location and filerY in other location
• that customer has a connection to both filerX and FilerY, although all shares to customers are available from filerX (via CIFS, NFS, iSCSI or FC)
• all customer data is being transfered to the filerY via Snapvault

What we can do with snapvault?

• as a backup solution, we can have a longer snapshot retention time on filerY, so more historic data will be available on filerY, if filerY has slower disks, this solution is smart, because slower disk = cheaper disks, and there is no need to use 15k rpm disk on filer that is not serving data to the customer.
•  if customer has an network connection and access to shares on filerY he can by himself restore some data to filerX, even single files
• if there is a disaster within filerX and we lose all data we can restore the data from filerY

What we cannot do with snapvault?

• in case of an disaster within filerX we cannot “set” filerY as a production side. We cannot “revert the relationship” making the qtree on filerY as a source, and make them read/write. They are snapvault destinations so they are read-only.
• (having snapmirror license available on filerY we can convert Snapvault qtree to snapmirror qtree which solves that ‘issue’)

What does it mean that SnapMirror is a DR solution?
Lets add diagram :

SnapMirror

Example has few assumptions:

• we’ve got filerX in one location and filerY in other location
• that customer has a connection to both filerX and FilerY, although all shares to customers are available from filerX
• all customer data is being transfered to the filerY via snapmirror

What we can do with snapmirror?

•  as a backup solution we can restore the accidentally deleted, or lost data on filerX,  if the snapmirror relationship has not been updated meantime
• if there is some kind or issue with filerX (from a network problem, to a total disaster) we can easily reverse the relationship. We can make the volume or qtree on filerY, as a source, and make it read-write, provide an network connection to the customer and voila – we are back online! After the issue has been solved we can resync the original source with changes made at the destination and reverse the relationship again.