Table of Contents
Advertisement
Here are four remote sites replicating 2 TB and 10 TB backups daily into a central VLS9000.
The best approach in a many-to-one scenario is:
Size each of the individual links separately.
Ensure the links at the target at least match the total remote size replication capacity (in this
example 300 Mbits/sec).
If possible, allow 25% extra capacity for "catch up" in the event of a backlog or paused
replications should a link go down.
Each remote site could have different start time and replication window to ensure target device
is not overloaded and best use is made of inter-site link speeds.
Device Sizing
When sizing a replication target device, the replicated virtual cartridges on the target device take
up the same amount of disk space as the original cartridges on the source device, and they also
require the same amount of working disk space for deduplication. In other words, if you replicate
all of the cartridges in the source device then you need the target device to have the same capacity
as the source device. In a many-to-one deployment, add up all the source disk capacity and the
total capacity is what you need on the target device.
However, the target device is not just adding capacity; it also need to add sufficient extra nodes
to handle the replication target disk I/O. With a 24–hour replication window, you need as much
node performance on the target device as on the source devices. For example:
With an active-passive deployment, if you have a 4-node/4-array VLS9000 as the source
device and you are replicating all of its cartridges, you need a 4-node/4-array target device.
With a many-to-one deployment, if you have four VLS6600/24-disk source devices (which
are effectively approximately half a node of performance and half an array of capacity each),
you need a 2-node/2-array VLS9000 as the target device.
If you have an active-active deployment, you must combine the required source
performance/capacity and the replication target performance/capacity to give you the overall
device. If in each site you have a 2-node/2-array requirement for the source piece (backups),
you need 2-node/2-array for the target piece. Therefore, you would have a 4-node/4-array
device in each site.
VLS Replication Data Recovery Options
Replication on VLS enables easier recovery of data in the event of a major site disaster. The data
is not instantly available but has to be recovered through a standard restore process using a backup
application. These scenarios examine what happens with a total site disaster including losing the
server and the VLS appliance that was protecting it.
NOTE:
The VLS does not support reverse deduplicated replication to rebuild a replacement source
device from the data already on the target device.
In the event of a total disaster at a site where the VLS and the servers it is protecting are destroyed
or damaged, the replicated data at the disaster recovery (target) site can be accessed by means
of a backup server on the remote site and transferred either to an application or onto physical
tape for distribution. Alternatively, when the damaged site is repaired, the most recent backups
on the virtual tape library at the disaster recovery site can be restored over the LAN/WAN to the
virtual tape library at the previously damaged site.
Restore Directly from the VLS Target Device
The first method of recovery uses the fact that there are probably more trained IT personnel at the
data center and that spare servers, etc., are stored there. With VLS the virtual library containing
the replication target (on the target device in the disaster recovery site) is always available through
120 Replication
Advertisement
Table of Contents
