Time finder VP snaps instead of Time finder clones

Hi All,

We are using time finder clones for backup.Target devices are to mapped netbackup server and backup takes place.We are on space crunch.

Can we use time finder VP snaps in the place of TFT clones.As snap uses less space.Is there any impact on this?

Every night tft clones are recreated and then backup starts.

Labels (1)
Tags (3)
2 Replies
3 Zinc

Re: Time finder VP snaps instead of Time finder clones

You'll want to read up on this in the EMC White Paper, Implementing TimeFinder VP SNAP for Local Replication.  There are some rules to implementing VP Snaps.  First, you'll need to be on the right version of Enginuity and Solutions Enabler.  Next, any additional VP Snaps (after the first) must all come from the same Thin Pool.

If you're really short on space, you might consider creating a traditional Snap Pool (and SAVEDEVs) and using traditional snaps.  The only space consumed will be space in the Snap Pool.

Let us know if that helps!


0 Kudos
2 Iron

Re: Time finder VP snaps instead of Time finder clones

Can you specify which code level you are running?  Change rate and performance requirements are also factors that should be considered to help you decide if you can use a copy-on-write mode like VP Snap or should stick with full copy Clones.

Write to a VP Snap source (and sometimes target) will require the original data to be copied from the source to target, which can have some overhead on performance.  Full copy clones will not have this effect once the background copy is complete, so they are considered the highest performing option.

As for the change rate, general rule of thumb (but not a hard rule) is if more than 30% of the total device will be copied to the snap target, then you may want to consider Clones as the better option.  Again, that is the starting point and not a hard rule.  Take the extreme example of 100% being copied, then that would be copy-on-write for every track, so better to just use full copy clones and let the background copy handle it without the overhead.  On the other end if you were only changing 5% then VP Snaps would save a considerable amount of space with little overhead.

Another thing to consider is that to keep as space-efficient as possible, VP Snaps targets are deallocated when the session is terminated or refreshed.  The dellocation process takes time.  So if the devices were large with a lot of % allocated, the recreate would take much longer than a clone refresh.  I talked to a customer who had like 98% of each target allocated, and the devices were huge.  So VP Snap wasn't saving them any capacity and refresh was taking longer, so Clones were a better option.  They also had only a single session per source, so they weren't getting the space savings of the shared allocations across the VP Snaps either.  If they had multiple VP Snaps, then that may have been a netter option than clone.

Hope this helps.  The paper Karl mentions has more good info.  Also keep in mind that you can use Clone and VP Snaps together, even on the same source device.  So you may find that moving to VP Snaps makes sense for some of your uses, but Cclones may be better for others.