Backup of active log after db failure

Greetings,
I am seeking information related to this subject.

BOL suggests backing up the active transaction log immediately after a
failure, so that the backup can be used in a recovery scenario if necessary.

This is the relevant text from BOL "Transaction Log Backup":

--//
The transaction log backup created at 8:00 P.M. contains transaction log
records from 4:00 P.M. through 8:00 P.M., spanning the time when the
database backup was created at 6:00 P.M. The sequence of transaction log
backups is continuous from the initial database backup created at 8:00 A.M.
to the last transaction log backup created at 8:00 P.M. The following
procedures can be used to restore the database to its state at 10:00 P.M.
(point of failure).

Restore the database using the last database backup created.

1.. Create a backup of the currently active transaction log.

--// end of excerpt

If the failure results in loss of the instance and/or the log's parent db,
how would we back up that log? Even if we could, what confidence would we
have that the backed up log was not corrupted at failure time?

Thanks,
PSGThe standard configuration when loss of transactions is unacceptable:
put the log disk on a separate disk from the data. And mirror the log disk.

You would have to trust (hope) that your log disk didn't suffer loss of
data. That's the point of the mirroring.

If the instance was lost, then you'd have to rebuild/restore master before
you'd be able to issue the
BACKUP LOG WITH NO_TRUNCATE to harvest the tail of the log.

"JustaCowboy" <ppgoodingNOSPAM@.rocketmail.com> wrote in message
news:blj1rd$v1g$0@.pita.alt.net...
<snip
> If the failure results in loss of the instance and/or the log's parent db,
> how would we back up that log? Even if we could, what confidence would we
> have that the backed up log was not corrupted at failure time?
> Thanks,
> PSG|||"Anonymous" <noone@.anon.com> wrote in message
news:3f7f1411$1@.news.microsoft.com...
> The standard configuration when loss of transactions is unacceptable:
> put the log disk on a separate disk from the data. And mirror the log
disk.

Yes.

> You would have to trust (hope) that your log disk didn't suffer loss of
> data. That's the point of the mirroring.

Yes.

> If the instance was lost, then you'd have to rebuild/restore master before
> you'd be able to issue the
> BACKUP LOG WITH NO_TRUNCATE to harvest the tail of the log.

Will SQL backup an unattached log file? If not, to what is the harvested
log attached? I am having trouble understanding the steps that would lead
to being able to backup that log unless SQL will back it up unattached.
Has anyone actually tried the scenario described in BOL?

A local has suggested to me that we frequently back up the log and copy the
backups (along with the preceeding full db backup) to disk or device
external to the subject server. If this log backup/copy were done every 15
mins, then presumably no more than 15 mins' work would be lost after a
failure. Our assumption right now is that the BOL suggestion just won't
work. We'd try simulating it if we thought the simulation were valid, but
that seems very doubtful.

thanks,
PG

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