On 08/03/2010 01:56, Neil Truby wrote:

If your bandwidth is < 1 mbyte/sec you will start to fall behind
immediately and never catch up

Is that simple enough?

--
Clive

--
This message has been scanned for viruses and
dangerous content by OpenProtect(http://www.openprotect.com), and is
believed to be clean.

On Mar 8, 9:09*am, Clive Eisen <cl... (AT) serendipita (DOT) com> wrote:
Clive,

Recover Point is doing compression at a level that positively
surprised me when I first saw it. So, actually, your bandwidth for
Recover Point's remote replication doesn't have to be exactly the same
as your average of data change. Of course, those two measures are
proportionate.

Out-of-box, Recover Point provides at least crash recovery consistency
for perhaps any application. I've tested it with Informix and it is
functioning. For those that EMC considers most important (Oracle, MS
SQL Server and Exchange, I think DB2 also,...), there are automated
mechanisms provided for application level consistency. One can make
such a mechanism himself/herself, using the API that is available. It
would be in a way similar to the mechanism that is described by OP of
this thread with LVM snapshots, but instead of creating LVM snapshots,
one should notify Recover Point that it is the point of consistency.
What is important is that Recover Point provides write order
preservation over a group of LUNs.

The question if some acceptable lag may implicate lower bandwidth
needed is very interesting one. Since Recover Point is relying on
strong compression, there may be dependence between lag and bandwidth.
Some compression algorithms can get higher compression rates if they
have larger sample before doing the compression. When I started
initial synchronization (file systems, databases), achieved
compression rates were in the range of up to 6 times. Such rates were
never achieved in later stages, when data is compressed and transfered
due to changes on a live system.

Darko Krstic

"Clive Eisen" <clive (AT) serendipita (DOT) com> wrote

Well, it's simple enough. But it's bollocks ... ;-)

If your Recovery Point Objective is, say, a strict 5 seconds then each time
the replicate would threaten to lag by more than this, operation of the
primary would be affected. To avoid that lag your bandwidth would have to
be sufficient always to handle any peak that would take more than 5s to
clear.

If your RPO is 5 minutes, the bandwidth requirement must be sufficient
always to handle any peak that would take more than 5 mins to clear.

Hence my original comment: " ....the more seconds you allow the remote SAN
to lag, the lower the bandwidth requirement of course".

"darko" <darko.krstic (AT) gmail (DOT) com> wrote

On Mar 8, 9:09 am, Clive Eisen <cl... (AT) serendipita (DOT) com> wrote:

mechanisms provided for application level consistency. One can make
such a mechanism himself/herself, using the API that is available. It
would be in a way similar to the mechanism that is described by OP of
this thread with LVM snapshots, but instead of creating LVM snapshots,
Indeed, the absence of Informix integration for Informix is very
regrettable, and another indication of the way Informix is viewed by the big
players.