If you got the tail of the log and your backup at the time
of doing the role change put the DB at the same state, if
you get the primary into STANDBY or NORECOVERY, you could
start just applying logs from the new primary.

However, if your secondary is not at the same point as the
primary, you have two problems.

1. If/when you can get back to the DB, do you want to see
what transactions exist that are not in the new primary
and export them? If so, do that first.
2. Even if you do #1, the only way in this scenario is to
take a full backup of the new primary (the original
secondary) and reinitialize the original primary, which
will be a new secondary.

So unless you can guarantee the DB on the secondary is at
the same point as the primary, you'll have decisions to
make.
[quoted text, click to view]
will use log shipping to maintain a backup server in case
the primary SQL 2000 goes down. I understand the
implications of using log shipping vs replication or
clustering, but one of the specs of the system is to have
the backup server be one to two hours behind the primary
server.
[quoted text, click to view]
has talked about how to get data from the primary to the
backup server, but it hasn't talked about synching the
primary to the backup server if the primary server does in
fact go down and the backup has to be promoted. Are there
any best practices on this subject? One of my concerns is
having to have both the primary and backup down at the
same time while resynching the primary to the backup, and
I want to minimize this time as much as possible.
[quoted text, click to view]