Backup Server

I would like to have a backup server ready to take over just in case I
experience an issue with one my SQL servers.
The idea is that if one server goes down, the other one is working in the
background and is seemless to the end user. I have the NLB manager running
with 2 ip address linking the 2 machines, however I am trying to figure out
the best way to SYNC the SQL data. Any ideas?
Thanks in advance!!
Mike,
this article might help clarify some of the considerations:
http://www.replicationanswers.com/Standby.asp
Cheers,
Paul Ibison
|||Have you investigated clustering? Microsoft site has all the info you need
to understand and get up and running with clustering.
Also, you could use logshipping with manual failover to maintain a standby
server.
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"Mike" <Mike@.discussions.microsoft.com> wrote in message
news:53C7587E-55BE-4D64-892D-4E5C523856D3@.microsoft.com...
I would like to have a backup server ready to take over just in case I
experience an issue with one my SQL servers.
The idea is that if one server goes down, the other one is working in the
background and is seemless to the end user. I have the NLB manager running
with 2 ip address linking the 2 machines, however I am trying to figure out
the best way to SYNC the SQL data. Any ideas?
Thanks in advance!!
|||"" wrote:
> I would like to have a backup server ready to take over just
> in case I
> experience an issue with one my SQL servers.
> The idea is that if one server goes down, the other one is
> working in the
> background and is seemless to the end user. I have the NLB
> manager running
> with 2 ip address linking the 2 machines, however I am trying
> to figure out
> the best way to SYNC the SQL data. Any ideas?
> Thanks in advance!!
I have a set up in a production environment where availability of the
DB at all times is paramount.
I have transactional replication running so that at any time if the
main DB server goes down, the backup server will only be about 4
seconds behind so its just a matter of pointing the applications to
the new server. The whole process of swapping to the second DB takes
about 30 seconds.
It has been a very reliable solution and whilst not as seemless as
having a cluster set up it is no way near as expensive.
Posted using the http://www.dbforumz.com interface, at author's request
Articles individually checked for conformance to usenet standards
Topic URL: http://www.dbforumz.com/Replication-...ict242154.html
Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.dbforumz.com/eform.php?p=842318

Backup methodologies

We have a backup plan that seems to be working quite well. My question is
more related to ease of using these in case of a restore. Currently we do
full backups weekly, diffs daily and hourly logs. This leaves alot of files
hanging around to manage. I've been testing on my workstation to try having
each days full backup or dif appended with the hourly logs in one file per
day. This is easily restored from script or GUI and seems so much more
manageable. Does it really matter either way functionally? I would worry
more about file corruption but if any single file had this in our current
scheme we'd have problems anyway.
Just curious how "most" prefer to do this....
Thanks!!
"Tim Greenwood" <tim_greenwood AT yahoo DOT com> wrote in message
news:u2GcJxefHHA.3928@.TK2MSFTNGP03.phx.gbl...
> We have a backup plan that seems to be working quite well. My question
> is more related to ease of using these in case of a restore. Currently we
> do full backups weekly, diffs daily and hourly logs. This leaves alot of
> files hanging around to manage. I've been testing on my workstation to
> try having each days full backup or dif appended with the hourly logs in
> one file per day. This is easily restored from script or GUI and seems so
> much more manageable. Does it really matter either way functionally? I
> would worry more about file corruption but if any single file had this in
> our current scheme we'd have problems anyway.
> Just curious how "most" prefer to do this....
Well most seem to prefer to ignore the problem until the DB crashes and the
CEO is breathing down their neck to restore everything. ;-)
If I can... I like to setup log-shipping (even if homegrown). This is a
real good way to make sure I can write AND read the files.
Otherwise, I tend to prefer separate files and then script stuff out.

> Thanks!!
>
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html

Backup methodologies

We have a backup plan that seems to be working quite well. My question is
more related to ease of using these in case of a restore. Currently we do
full backups weekly, diffs daily and hourly logs. This leaves alot of files
hanging around to manage. I've been testing on my workstation to try having
each days full backup or dif appended with the hourly logs in one file per
day. This is easily restored from script or GUI and seems so much more
manageable. Does it really matter either way functionally? I would worry
more about file corruption but if any single file had this in our current
scheme we'd have problems anyway.
Just curious how "most" prefer to do this....
Thanks!!"Tim Greenwood" <tim_greenwood AT yahoo DOT com> wrote in message
news:u2GcJxefHHA.3928@.TK2MSFTNGP03.phx.gbl...
> We have a backup plan that seems to be working quite well. My question
> is more related to ease of using these in case of a restore. Currently we
> do full backups weekly, diffs daily and hourly logs. This leaves alot of
> files hanging around to manage. I've been testing on my workstation to
> try having each days full backup or dif appended with the hourly logs in
> one file per day. This is easily restored from script or GUI and seems so
> much more manageable. Does it really matter either way functionally? I
> would worry more about file corruption but if any single file had this in
> our current scheme we'd have problems anyway.
> Just curious how "most" prefer to do this....
Well most seem to prefer to ignore the problem until the DB crashes and the
CEO is breathing down their neck to restore everything. ;-)
If I can... I like to setup log-shipping (even if homegrown). This is a
real good way to make sure I can write AND read the files.
Otherwise, I tend to prefer separate files and then script stuff out.

> Thanks!!
>
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||I always have the separate files - I like the reassurance of seeing separate
files accumulate and which can easile be sorted by date so I know things are
happening correctly. Like Greg I like log shipping when the kit is
available, but in your cast this won't be an option if you want the
differentials to be used also.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com

Backup methodologies

We have a backup plan that seems to be working quite well. My question is
more related to ease of using these in case of a restore. Currently we do
full backups weekly, diffs daily and hourly logs. This leaves alot of files
hanging around to manage. I've been testing on my workstation to try having
each days full backup or dif appended with the hourly logs in one file per
day. This is easily restored from script or GUI and seems so much more
manageable. Does it really matter either way functionally? I would worry
more about file corruption but if any single file had this in our current
scheme we'd have problems anyway.
Just curious how "most" prefer to do this....
Thanks!!"Tim Greenwood" <tim_greenwood AT yahoo DOT com> wrote in message
news:u2GcJxefHHA.3928@.TK2MSFTNGP03.phx.gbl...
> We have a backup plan that seems to be working quite well. My question
> is more related to ease of using these in case of a restore. Currently we
> do full backups weekly, diffs daily and hourly logs. This leaves alot of
> files hanging around to manage. I've been testing on my workstation to
> try having each days full backup or dif appended with the hourly logs in
> one file per day. This is easily restored from script or GUI and seems so
> much more manageable. Does it really matter either way functionally? I
> would worry more about file corruption but if any single file had this in
> our current scheme we'd have problems anyway.
> Just curious how "most" prefer to do this....
Well most seem to prefer to ignore the problem until the DB crashes and the
CEO is breathing down their neck to restore everything. ;-)
If I can... I like to setup log-shipping (even if homegrown). This is a
real good way to make sure I can write AND read the files.
Otherwise, I tend to prefer separate files and then script stuff out.
> Thanks!!
>
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||I always have the separate files - I like the reassurance of seeing separate
files accumulate and which can easile be sorted by date so I know things are
happening correctly. Like Greg I like log shipping when the kit is
available, but in your cast this won't be an option if you want the
differentials to be used also.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com