Planning for Disaster Recovery in second data center..

We are planning on using Database Mirroring internally within the data
center for HA and since its used, I am left now with log shipping or
possibly some SAN replication.
I think either one will work with log shipping being very affordable.. Free
!!!
Does anyone see any pros to SAN replication as the strategy compared to Log
shipping to have the data to the remote site. We are looking at RTO and RPO
of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
a disaster.
On 3 Apr, 05:04, "Hassan" <has...@.hotmail.com> wrote:
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable.. Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to Log
> shipping to have the data to the remote site. We are looking at RTO and RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
> a disaster.
The replication is simpler, in the sense that you have one thing to
monitor, and in theory preferrable. We went for log shipping on the
basis that we were unsure about the burden of the extra data across
the network and some reservations about knowing the state of disk
writes to the data centre. Log shipping gives certainty in the sense
that the database is written to a known transaction at a known point,
even if it may not restore to the last possible moment before failure.
And as you say, it's cheap.
|||Hello Hassan,
Better approach for high availability is create a cluster in local data
center for the production SQL Server machines and for disaster recovery site
use Mirroring/Replication or Logshipping.
To plan the disaster site you should do a capasity planning on data growth,
network bandwidth...
If you have enough budget you could take a look into options like EMC's
SRDF.
http://www.emc.com/products/networking/srdf.jsp
Thanks
Hari
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
|||"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
Personally in a case like this, I'd probably go with log-shipping over SAN
replication.
It's cheaper. It's also easier to ensure a consistent transactional point
in time.
And you can run log-shipping "behind" by some fixed amount of time
(basically do't update unless log is older than X minutes.)
This can save you when someone says, "oops, I just deleted this data, can we
get it back?" As long as they let you know in time, it's fairly trivial.
Then when you have a real disaster just apply the more recent logs, and
voila, you're up to date.
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
|||Hari,
If I use mirroring or Log shipping, why would one consider storage
replication like EMCs SRDF ?
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23jtZWkedHHA.4624@.TK2MSFTNGP03.phx.gbl...
> Hello Hassan,
> Better approach for high availability is create a cluster in local data
> center for the production SQL Server machines and for disaster recovery
> site use Mirroring/Replication or Logshipping.
> To plan the disaster site you should do a capasity planning on data
> growth, network bandwidth...
> If you have enough budget you could take a look into options like EMC's
> SRDF.
> http://www.emc.com/products/networking/srdf.jsp
> Thanks
> Hari
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
>
|||The main difference between SAN mirroring and Database Mirroring/Log
Shipping has to do with which machines are left online at the DR site.
By mirroring the SAN, you can mirror the entire Data Center only need to
keep the remote SAN turned on, no hosts.
In Database Mirroring/Log Shipping, you have to have the remote site fully
operational: Domain Controllers, network, DNS servers, SAN, etc., etc., etc.
And, you have to perform Database Mirroring/Log Shipping on a database per
database configuration. If you have an installation with, say, 50 or more
databases, it is going to be a real pain attempting to mirror or ship logs
for each of them.
If you extrapolate this for the entire Data Center, you will see that
mirroring the disks to remote hosts is going to be more efficient,
administratively at least.
Be careful though. SAN mirroring comes in at least 3 flavors: Synchronous,
Asynchronous, and Snap Copy. Each has its purpose and potential drawbacks.
You need to understand how each works.
Sincerely,
Anthony Thomas

"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to
Log
> shipping to have the data to the remote site. We are looking at RTO and
RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
of
> a disaster.
>
>
|||We will most likely go with Asynchronous. What are drawbacks to that other
than latency ? Would there be integrity issues ? Are there chances that when
you bring the secondary site online, some databases may be corrupt ?
Does it impact the primary site while you setup Storage replication? Does it
impact performance on the primary ?
I am no SAN expert but have heard some SAN horror stories. Care to share ?
We will use the HDS Storage.
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
> The main difference between SAN mirroring and Database Mirroring/Log
> Shipping has to do with which machines are left online at the DR site.
> By mirroring the SAN, you can mirror the entire Data Center only need to
> keep the remote SAN turned on, no hosts.
> In Database Mirroring/Log Shipping, you have to have the remote site fully
> operational: Domain Controllers, network, DNS servers, SAN, etc., etc.,
> etc.
> And, you have to perform Database Mirroring/Log Shipping on a database per
> database configuration. If you have an installation with, say, 50 or more
> databases, it is going to be a real pain attempting to mirror or ship logs
> for each of them.
> If you extrapolate this for the entire Data Center, you will see that
> mirroring the disks to remote hosts is going to be more efficient,
> administratively at least.
> Be careful though. SAN mirroring comes in at least 3 flavors:
> Synchronous,
> Asynchronous, and Snap Copy. Each has its purpose and potential
> drawbacks.
> You need to understand how each works.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> Free
> Log
> RPO
> of
>
|||"Hassan" wrote:
> Hari,
> If I use mirroring or Log shipping, why would one consider storage
> replication like EMCs SRDF ?
This has to be looked at from the whole data center infrastructure
perspective. If you are talking about a few machines and a few databases on a
single platform, sure use database mirroring or log shipping by all means.
But if you have a large data center with a lot of servers, a lot of
databases, and different platforms, setting up and maintaining database
mirroring or log shipping for each of the databases would be very
inconvenient. So because of the expenses, nobody would go out to buy a SAN
with SRDF just for a few databases. But if you already have a significant SAN
infrastructure in place, a SRDF-like technologies become very appealing to
consider because it is at the storage level and the DBAs are freed to
concentrate on the database issues.
Imagine if you only have a few houses in a place, having individual
generators to provide power probably makes sense. But if the place starts to
get populated, it may make more sense to get a power grid in and have the
power supply managed centrally by professionals.
Linchi
|||"Hassan" wrote:

> Does it impact the primary site while you setup Storage replication? Does it
> impact performance on the primary ?
> I am no SAN expert but have heard some SAN horror stories. Care to share ?
There is a performance penalty with synchronous storage replication just
like there is a performance penalty with full-safety (or synchronous)
database mirroring. I/Os (or transaction records) have to travel across the
distance, and that has inherent delay. There is no free lunch. But the issue
is whether the performance impact is too severe for the app response
requirements. Current state of the art is that most of the apps can live with
the performance penalty. For a specific app, one has to evaluate it
specifically.
This is like buying storage. You don't always go out buying the fastest
storage. You buy least expensive storage that meets your all requirements.
Linchi

> We will use the HDS Storage.
> "Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
> news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
>
>
|||"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:FFC68E76-BF64-4C98-9A42-FA5A87A7E959@.microsoft.com...
> "Hassan" wrote:
> This has to be looked at from the whole data center infrastructure
> perspective. If you are talking about a few machines and a few databases
> on a
> single platform, sure use database mirroring or log shipping by all means.
> But if you have a large data center with a lot of servers, a lot of
> databases, and different platforms, setting up and maintaining database
> mirroring or log shipping for each of the databases would be very
> inconvenient. So because of the expenses, nobody would go out to buy a SAN
> with SRDF just for a few databases. But if you already have a significant
> SAN
> infrastructure in place, a SRDF-like technologies become very appealing to
> consider because it is at the storage level and the DBAs are freed to
> concentrate on the database issues.
> Imagine if you only have a few houses in a place, having individual
> generators to provide power probably makes sense. But if the place starts
> to
> get populated, it may make more sense to get a power grid in and have the
> power supply managed centrally by professionals.
Thank you for the excellent analogy.
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
The next ClusterHelp class is:
April 30, 2007 - Denver