SQL Server state after Bridgehead restore

  • Hi, 

    We are in the process of testing our recovery readiness.  Does anyone use Bridgehead to backup the SQL servers? We are not using the Agent backup option. 

    We have restored the server using the bridgehead restore, OS and SQl are restored but the Master and all databases are not because they were open at the time and are missing.  SQL can not start but is restored from backup.  Has anyone successfully recovered a SQL server using bridgehead recovery?

    Bridgehead is not being helpful here.  They do not tell us how to restore but they can perform the recovery process.

    Thank you for any help.

     

  • Here's probably the trouble: We are not using the Agent backup option.

    I've never used Bridgehead, but I've used Veritas' Backup Exec and they also have an Agent for SQL Server.

    If you don't use the agent, then it just does a file backup which won't be restorable. You must use the agent or put the database offline before backing up the files.

    Why use a third-party tool? I would use SQL Server BACKUP DATABASE and BACKUP LOG commands to back up the dbs to disk, then use backup software to copy the backups to tape.

    -SQLBill

  • Master and MSDB are special cases... and perhaps the easiest way to have a backup is by shutting down the service and taking an OS level backup of the .mdl and .ldl files.  For most purposes, as long as you have the application DBs backed up, you should be able to restore them to another instance.

    I have also used Veritas, and our admins are using it here in the background; but I don't even know where those files go (and I am "the dba").  The agent does a good job of backing up the running DBs; but I have never restored master and/or msdb from Veritas backup files... and my general opinion is that untested backups are worthless about 80-90% of the time.

    Maintenance plans and out of the box backup work just fine... backup/restore/recover... I can see advantages to some third party tools under some circumstances; but not typically.  Compression is perhaps a big one for some clients.

    Also, I have found that maintenance plans (on 2000) need to be done for DBs in full or bulk recovery modes, and a separate one for simple mode.  When you include them all, the few DBs in simple mode get a report (if you select it in the plan) that says "could not backup <yada> ignored"... well, it IS ignored, and the files are otherwise there as per the plan; but the last step failed, and the purging of old files is not done... leaving, sometimes, 30,000 or so old log files on the disk before its discovered.

    separating these DBs into separate plans starts the purging again.  This was not a fluke, I have implemented it several times, and it always fixes the purge again.  You might THINK that the word "ignored" would mean that... it doesn't, in my experience.

    Good luck with Bridgehead... I would personally implement maintenance plans on the side... just in case... not a big fan of 3rd party anything... unless it really has value added.

    Thank-you,
    David Russell
    Any Cloud, Any Database, Oracle since 1982

  • I've never heard of Bridgehead.  We've used Idera's SQLSafe with good results. It compresses our 220 Gig backup down to 40 G, and runs in half the time as native backup. We also use Veritas on other backups, and native SQL backups to disk on severs that don't have Veritas or SQLSafe.

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply