backup with backup exec 12.5 cannot be performed on master DB

Question

Post reply

backup with backup exec 12.5 cannot be performed on master DB

fred2002

SSCrazy

Points: 2943
More actions
October 30, 2008 at 9:30 am

#128225

Hi

we just installed the new backup exec 12.5 software.

One of the new feature is the ability to backup DB in use (open).

But we got always error message concerning the master DB.

"Error category : Job ErrorsError : e00084a8 - A log backup was attempted on a database that is not currently configured to support log backups. To change the configuration use Enterprise Manager to set the recovery mode to FULL in SQL 2000 or turn off the 'trunc on chkpt' option in SQL 7. A new fullFor additional information regarding this error refer to link V-79-57344-33960"[/i]

Now it s recommanded to change the recovery model from simple to full.

And i have doubts about it.

Somebody has an idea about that?

Viewing 7 posts - 1 through 6 (of 6 total)

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

Jonathan Kehayias One Orange Chip Points: 26778 More actions · Answer 1

This is saying that you attempted a Log backup on the master database which is not supported by any tool including SQL native backup. You can only take a full backup of the master database. Remove the master database from the Netbackup backup policy that is running your transaction log backups and it should be fine.

fred2002 SSCrazy Points: 2943 More actions · Answer 2

fred2002

SSCrazy

Points: 2943

October 30, 2008 at 9:38 am

#891916

ok that is what we will do.

Thanks

Jonathan Kehayias One Orange Chip Points: 26778 More actions · Answer 3

This is a common problem I face when we add a new SQL Server to our environment. The Netbackup Admin sets the policy to work for all databases because it is easier, and then this error pops. It is not uncommon to see. If that doesn't solve your problem let us know, but I don't think we will hear back from you on this.

fred2002 SSCrazy Points: 2943 More actions · Answer 4

fred2002

SSCrazy

Points: 2943

October 30, 2008 at 9:54 am

#891930

Jonathan

i just read on your blog, you have experience on running sql server on esx.

I just did it now for a our new sql servers 2005.

Did you met issues concerning performances?

Jonathan Kehayias One Orange Chip Points: 26778 More actions · Answer 5

Not really. We had some headaches from time to time that we would also have experienced in a physical implementation when our SAN got overloaded. Adding a 4GB fiber switch and splitting/separating some of the load between separated paths to the SAN solved the problem. We run Exchange in ESX currently as well, although that is moving to a boot from SAN implementation in the next few weeks so that the servers can be sized larger than they would be able to be in ESX currently, though ESX 4.0 will allow for larger virtual machines to be built.

One of the problems with running in a virtual environment is really how large do you make your server. In ESX you can use VMotion to move a VM from one host to another in real time with only a 2-4 second hiccup in network while the packets shift from one host to the other. However, to do this, you have to have available headspace on the receiving host server, so if you move a 4 processor 8GB of RAM server, you need at least this amount of resources available or performance will be impacted immediately on the receiving host. For this reason, VM's tend to be smaller servers, 2 processor, 4GB RAM because you can easily accomodate this configuration when compared to a larger one.

We have a 300GB+ SQL Database running in a VM Server, with no real problems. It could certainly perform a lot better on a physical server with directly attached storage that is configured to best practices for SQL, no doubt about that, but it meets our business requirements.

fred2002 SSCrazy Points: 2943 More actions · Answer 6

fred2002

SSCrazy

Points: 2943

October 31, 2008 at 1:23 am

#892175

thanks for this infos