Forum Discussion

RicohNorway's avatar
12 years ago
Solved

Unable to backup SQL server with BE2012

Hi

 

As title is stating, i am strugling big time backing up SQL server. Here is some information first:

 

Server in Question:

Running OS Microsoft Windows 2003 SP2

Running SQL 2005 with multiple databases.

 

Backup Environment:

Backup Exec 2012 with SP3 installed. This is again running on a Windows 2003 R2 SP2 server.

 

 

As already mention, i have a SQL environment with multiple databases. Some of them are running on a Simple Recovery mode and some on Full.

My backup setup is as follows:

Full backup on Friday, Log backup at 17:00 from Monday through Thursday and then a Differential backup at 18:00 from Monday through Thursdag. 

 

Now when running the backups, it is creating multiple errors and exceptions. Below are a list of errors\exceptions it is creating:

 

 

For Full Backup:

  • It is completing but with exceptions. It is saying that the Sharepoint agent does not support the transaction log backups, hence change the recovery model to Simple. This goes to 5 sharepoint databases. But problem is that i can not change the recovery model to Simple, as they are critical databases which needs to have in time recovery setup.

For Log

  • For 5 of the Sharepoint database it is giving me the same error: The SharePoint database DATABASENAME is configured to maintain transaction logs. The SharePoint Agent does not support transaction log backups. Configure the database to use the simple recovery model using SQL Server Management Studio. Once you change the recovery model, you must run a full backup of the database before you can successfully run an incremental or a differential backup.
  • And then it is giving me the following error on SQL databases: A log backup was attempted on database DATABASENAME that is not configured to support log backups. To change the configuration, use the SQL administration tools to set the recovery mode to Full. A new full backup should be performed if this setting is changed before a log backup is run.
    Problem here is that i do understand that i need to deselect all the databases which have Simple recovery model, but some of them are greyed out so i am unable to deselect them.

For Differential

  • Giving me the same error for 5 sharepoint databases that it does not support the transaction log backups etc.

 

Apart from the issues above, i need to know the difference between the following 2 things which can be selected when setting up a SQL backup Job:

 

  • Microsoft Sql Server Instances
  • Microsoft Sharepoint Resources

I understand that Microsoft Sharepoint Resources lists the Sharepoint databases, but i also see them under Microsoft Sql Server Instances, does it mean that i am selecting them twice?


 

 

 

 

 

 

 

 

  • You cannot backup a Sharepoing farm by backing up the component SQL databases and restoring them.  You would probably end up with an inconsistent farm.  This is why you backup your Sharepoint farm using the Sharepoint agent.  When you do a restore using the Sharepoint agent, you will end up with a usable farm.  See my blog below in the details of why this is so.

    https://www-secure.symantec.com/connect/blogs/can-i-backup-sap-database-sql-or-oracle-agent

    By the same reasoning, you cannot do PIT restores of the component databases.  As such, the document is correct in recommending that you switch all the Sharepoint component databases to simple recovery mode because there is no point in maintaining logs if you are not going to do PIT restores

    With BE 2012, it is not possible to do log backups by themselves.  You need to have two sets of jobs, with log backup jobs for the databases with full recovery mode and another job, without log backups, for the databases with simple recovery mode.

    For your Sharepoint farm, you should select the resources from under Sharepoint and not under SQL databases.

  • Ok any database in Simple Recovery Model cannot do log backups - as such you will need to adjust/split your jobs for which databases in in Simple Recovery and which are in Full.

    Sharepoint databases should be backed up via the Sharepoint agent selections and not using SQL selections and (EDITED) this tech article applies http://www.symantec.com/docs/TECH187768

  • Thanks for the reply. I know log backups can not be performed on Simple Recovery model, but when you are saying splitting the job, do you mean the log job? or the entire backup setup.

     

    For the sharepoint databases, so am i suppose to select them through Sharepoint resource selection, and not Sql Instance selection? Once i hace selected them through Sharepoint Resource, should i deselct them from Sql Instances ?

    1. I know simple recovery can not have log backups setup. For splitting the job, do you mean only the Log Backup or the entire backup setup for this SQL server?
    2. Sharepoint Database. Do you mean i should only select it through Sharepoint Resources, and deselct them from Sql Instances? The article you are refering to does not provide any solution, it simply tells me to change the recovery model to Simple, which i can not.
  • You cannot backup a Sharepoing farm by backing up the component SQL databases and restoring them.  You would probably end up with an inconsistent farm.  This is why you backup your Sharepoint farm using the Sharepoint agent.  When you do a restore using the Sharepoint agent, you will end up with a usable farm.  See my blog below in the details of why this is so.

    https://www-secure.symantec.com/connect/blogs/can-i-backup-sap-database-sql-or-oracle-agent

    By the same reasoning, you cannot do PIT restores of the component databases.  As such, the document is correct in recommending that you switch all the Sharepoint component databases to simple recovery mode because there is no point in maintaining logs if you are not going to do PIT restores

    With BE 2012, it is not possible to do log backups by themselves.  You need to have two sets of jobs, with log backup jobs for the databases with full recovery mode and another job, without log backups, for the databases with simple recovery mode.

    For your Sharepoint farm, you should select the resources from under Sharepoint and not under SQL databases.

  • Thanks for the reply. I have read your Blog, but i still dont understand why PIT can not be performed on Sharepoint databases? What if it realy is very critical databases which needs to be backup all the time?

     

    Currently i have the following jobs setup for the SQL server in question here:

     

    1 Full job on Fridays, basically everything selected, And i think sharepoint resources are selected twice, as i also have same databases selected in SQL instaces aswell.

    1 Differential job from Mon-Thu Everything selected

    1 Log job from Mon - Thu everything selected

     

     

     

    So you are suggesting me to do the following. Please correct me if i am wrong.

     

    1 Full Job on Firdays with only databases with Simple Recovery module selected

    1 Differential job from Mon-Thu with only databases with Simple Recovery module selected

     

    1 Full Job Fridays with only databases with Full Recovery module selected

    1 Differential job from Mon-Thu with only databases with Full Recovery module selected

    1 Log job from Mon-Thu with only databases with Full Recovery module selected

     

     

    So basically splitting the databases with difference Recovery module selected. Please let me know.

     

     

  • I hope you understand from my blog why you cannot backup the component databases and restore them. Doing a PIT restore or restoring a full/differential backup makes no difference, you cannot hope to get a consistent farm after the restore because you cannot coordinate the restores so that every transaction is consistent across all the component databases. For your important database question, using the SharePoint farm as an example, you will do more frequent full backups using the SharePoint agent. If the SharePoint agent allows differential backups, then you can also make use of them to save some time. What you said that I am suggesting is correct, but you might also want to do a log backup after the full backup
  • I have been sick so have not been on job for past 4-5 days. Hence a late response.

     

    So you are suggesting this?

     

     

    1 Full Job on Firdays with only databases with Simple Recovery module selected

    1 Differential job from Mon-Thu with only databases with Simple Recovery module selected

     

    1 Full Job Fridays with only databases with Full Recovery module selected

    1 Log job Fridays with only databases with Full Recovery module selected

    1 Differential job from Mon-Thu with only databases with Full Recovery module selected

    1 Log job from Mon-Thu with only databases with Full Recovery module selected

     

     

    As for understanding the backing up component database, i do understand that you simply can not do that because restoring it wont give you complete farm, but is this limitation only for Backup Exec 2012? If i were to take sharepoint backup using the SQL itself, would i be able to backup then?

  • Yes. Your schedule is correct. This is not a BE thing. It is a SQL thing
  • Thanks for your help so far PKH. Even though i will leave this thread open until i give you a final confirmation towards the end of this week, i feel splitting the job and setting sharepoint resources recovery modul to simple did the job. Now i almost have freed over 60GB with space on the SQL server in question. Seems like truncation of log files are working fine aswell for the jobs with Full recovery modul.

  • Have been running for 1 week, and its working. Will open a new thread if i encounter antything in future. Thanks for your help buddy,