Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
Sitka
Aged Yak Warrior
571 Posts |
Posted - 2004-08-26 : 07:55:10
|
| It was explained to me that when used in conjunction with the Disaster Recovery module. BrightStore will backup the locked database .MDF and .LDF files and all system files then allow a full recovery of a server. This seems like a gimic moving beyond the native foolproofness of log shipping to a standby server and would rely on having a standby piece of compatible hardware sitting idle waiting to be recovered "into" in order to have a chance of it working. I keep trying to explain the soundness of full backups and transaction logs, but the logical arguement from the other side continues as recovering from a backup of the .MDF's along with an imaging/ERD type solution. I figure now I could have things back up in under an hour with the warm standby, Server rename, Full recovery etc. all be it on a lower spec machine. My point is what are you going to recover into if this BrightStore concept is in place. If a shotgun blast or a fire on the backplane results in recovering into a non similar machine; to me; that is going to set up a whole lot of unknowns.Possessing a wide range of watered down skills. |
|
|
MuadDBA
628 Posts |
Posted - 2004-08-26 : 13:27:11
|
| Also, it will be difficult to do point in time recovery without a DB backup and tran log backups. |
 |
|
|
Sitka
Aged Yak Warrior
571 Posts |
Posted - 2004-08-26 : 15:50:02
|
| My understanding was that there are two cases here 1.) The latest point in time is represented by the time the whole "image" (for lack of a better word) is made by the BrightStore scheduled backup. This obviously makes NO sense to me. But that is how it is being sold or intrepreted by one of my coworkers. 2.) If you wanted to recovery to a point in time as a means to roll back in the case of pure foobar due to corruption or human error and you are relying only on the timing of this full (probably also has an incremental or differential option) "system to tape" method to enable disaster recovery. So yeah if you do not do regular Database backups the chance for excessive data loss is greater. This is screwed up for sure. I read the simple help file docs for this SQL AGENT and it seems to present nothing beyond the Backup command in terms of database management. How this ties into the full system recovery I don't understand. We do have the demo version so I guess that is the best way to figure it out. I'll bet it is a whole heap of work though to test it out, that is in my favour as far as the KISS approach. I need no more opinion forming influence than the fact that the folks on these forums here don't say "WOW, have you tried the new BRIGHTSTORE Agent". Not many things sneak by the SQLTeam.Possessing a wide range of watered down skills. |
 |
|
|
|
|
|