Configuring a failsafe or backup server

I am not sure exactly which newsgroup to post this to so I will ask here
with the hopes that someone either can answer or at least point me to a
better newsgroup to pose the question.
We have a single SQL Server 2000 server machine. We are increasingly adding
more and more db's and applications and more and more users are depending on
this data being available. We have a sales force and dealers that access the
data remotely 24/7 from varios time zones. Now I am starting to think in
terms of data availability - making sure that if the server goes down or we
need to take the server offline for any period of time, we can move the db's
over either manually or automatically to another server. We do also have a
Win2K small business server that includes SQL server - and it is really
sitting idle so we could use that machine as the backup SQL server in a
pinch. Then we'd have to repoint all users to the new machine which would
allow them to be back up and running again in a decent time frame. Then when
we are back online with the actual SQL Server, the db would have to be
migrated back over...
There are a couple of options I am thinking...
1) to implement a complete failover system so that if one server goes down,
up comes the other one almost instantly? I doubt we really need to go to
this level but perhaps someone could elaborate on exactly what
hardware/software would be needed to implement such a scheme. I am thinking
Win2K3 R2 DFS or a Doubletake solution?
2) Manually backup and restore from one machine to the other and back again
when the other machine is back on line. This would mean that if the SQL
server went down in the afternoon, and we were unable to access the drives
for whatever reason, we would have to restore from the previous nights SQL
server backup (on disk). meaning a loss of almost a full days work
potentially..
What other options are there out there? What have other folks been doing?
Should we be backing up transaction logs every hour possibly? That way we
could restore from previous night and then play back all the transaction
logs to get current within an hour at least...
Thanks, Brad
Log shipping is another option for maintaining a warm
standby. You can write your own and don't necessarily need
to be using SQL Server 2000 Enterprise Edition. That edition
just gives you a GUI to setup and monitor the log shipping.
There are other options - depending on the business needs.
This article does a good job of going though the different
options and their advantages, disadvantages:
http://vyaskn.tripod.com/maintaining_standby_sql_server.htm
-Sue
On Mon, 28 May 2007 16:34:34 -0400, "Brad Pears"
<bradp@.truenorthloghomes.com> wrote:

>I am not sure exactly which newsgroup to post this to so I will ask here
>with the hopes that someone either can answer or at least point me to a
>better newsgroup to pose the question.
>We have a single SQL Server 2000 server machine. We are increasingly adding
>more and more db's and applications and more and more users are depending on
>this data being available. We have a sales force and dealers that access the
>data remotely 24/7 from varios time zones. Now I am starting to think in
>terms of data availability - making sure that if the server goes down or we
>need to take the server offline for any period of time, we can move the db's
>over either manually or automatically to another server. We do also have a
>Win2K small business server that includes SQL server - and it is really
>sitting idle so we could use that machine as the backup SQL server in a
>pinch. Then we'd have to repoint all users to the new machine which would
>allow them to be back up and running again in a decent time frame. Then when
>we are back online with the actual SQL Server, the db would have to be
>migrated back over...
>There are a couple of options I am thinking...
>1) to implement a complete failover system so that if one server goes down,
>up comes the other one almost instantly? I doubt we really need to go to
>this level but perhaps someone could elaborate on exactly what
>hardware/software would be needed to implement such a scheme. I am thinking
>Win2K3 R2 DFS or a Doubletake solution?
>2) Manually backup and restore from one machine to the other and back again
>when the other machine is back on line. This would mean that if the SQL
>server went down in the afternoon, and we were unable to access the drives
>for whatever reason, we would have to restore from the previous nights SQL
>server backup (on disk). meaning a loss of almost a full days work
>potentially..
>What other options are there out there? What have other folks been doing?
>Should we be backing up transaction logs every hour possibly? That way we
>could restore from previous night and then play back all the transaction
>logs to get current within an hour at least...
>Thanks, Brad
>
|||Thanks for that...
Brad
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:vbkm53lfq2197a3ah6tfasd2q2ie875n62@.4ax.com...
> Log shipping is another option for maintaining a warm
> standby. You can write your own and don't necessarily need
> to be using SQL Server 2000 Enterprise Edition. That edition
> just gives you a GUI to setup and monitor the log shipping.
> There are other options - depending on the business needs.
> This article does a good job of going though the different
> options and their advantages, disadvantages:
> http://vyaskn.tripod.com/maintaining_standby_sql_server.htm
> -Sue
> On Mon, 28 May 2007 16:34:34 -0400, "Brad Pears"
> <bradp@.truenorthloghomes.com> wrote:
>