106
Offload to Tape requirement
In this example the customer wants to know: “What is the best practice to make monthly copies to physical tape
from Site E?”
One fundamental issue associated with the deduplication process used on D2D is that the data is “chunked” into
nominal 4K pieces before it is stored on disk. When data is read from D2D for a restore or for a copy to tape,
the files must be re-assembled from millions of 4K chunks so, inherently, the restore or copy process from D2D
can be slower than expected for a single stream.
In this worked example the customer has two options for the copy to tape.
Use your backup application to perform a tape-to-tape copy. This can be used at the Central Site E to copy
both the local backups on VTL and the replication data from sites A, B, C and D onto physical tape. It is easy
to administer within the backup application but the streaming performance will be slow because of the reasons
explained above. Be sure to allocate this over a long period, such as a weekend, or allocate a specific time
during the day to do this. Because the data is being read back into the media server and then copied to
physical tape it will also add to network load.
Another way to copy the unique data at Site E to physical tape is for the Local VTLs is to send the data directly
from the sources to physical tape once a month, that is without reading the data from the D2D and so not
incurring any performance limitation.
See Tape Offload on page 75 for more information.