none
DPM backup and truncate of SQL Log file causes problems with SharePoint RRS feed

  • Question

  • Hi all,

    We are using DPM 2012 to backup our database server running SQL Server 2005. On that server we are also hosting our SharePoint databases. Recently, our DB admin has enabled hourly log file backup and truncation for all SharePoint databases.

    This appears to have caused issues with our SharePoint farm, where write operations would fail intermittently, (e.g. metadata changes to a file).

    Can someone clarify if DPM is actually locking the log file during the back up / truncate action?

    Many thanks.

    Andrew

    Tuesday, November 13, 2012 3:07 AM

All replies

  • Hi Andrew,

    Does your DPM also protect your SharePoint ?

    Does your protected SQL databases are in dedicated SQL instance ?

    How your Protection Group is configured ?

    Stephane 


    Please remember to click “Mark as Answer” on the post that helps you. This posting is provided "AS IS" with no warranties. knowledge is valid only if it is shared by All.

    My DPM blog Yet Another DPM Blog

    Tuesday, November 13, 2012 9:04 AM
  • Hi Stephane

    Thanks for your response. We currently only have SQL backup configured for the SharePoint databases, no SharePoint backups.

    Protection group is configured for short-term protection to disk and long term protection using tape.

    Short term protection
    Retention is 5 days
    Synchronization frequency Every 15 minutes
    Full backup 8:00pm every day.

    Long term protection:
    Retention range: 1 month
    Full backup to tapes Every Fri 11pm
    Every 1 month on 1st day 11:00pm

    Tape options: Compress Data

    Run a consistency check if a replica becomes inconsistent - Ticked
    Run a daily consistency check according to the following schedule: Start 7:00pm for max duration of 12 hours.

    Hope that helps.

    Wednesday, November 14, 2012 12:48 AM
  • The truncation should be performed either by DPM (using Full Recovery Model for the database) or by SQL using a maintenance plan but not by both.

    If you want to disable log truncation you should perform only Full Express Backup on your database and do not configure synchronization (the sync truncates the logs).

    Or you could put the Sharepoint database to simple recovery mode and there won't be any logs.

    Why don't you use Sharepoint protection instead of SQL protection? That would allow you to perform Item Level Recovery inside the Sharepoint farm.

    Wednesday, November 14, 2012 9:19 AM
  • Hi Andrew,

    Could you clarify "This appears to have caused issues with our SharePoint farm, where write operations would fail intermittently, (e.g. metadata changes to a file)."

    Do you have any DPM error message when running your SQL Protection ?

    If you are running both DPM protection and SQL backup you will have DPM error message like "The SQL log backup job has detected a discontinuity in the SQL log chain for  SQL Server 2005 database ..." and all your incremental backup jobs will be in fail state.

    Is this true ?

    Stephane


    Please remember to click “Mark as Answer” on the post that helps you. This posting is provided "AS IS" with no warranties. knowledge is valid only if it is shared by All.

    My DPM blog Yet Another DPM Blog

    Wednesday, November 14, 2012 10:45 AM
  • DPM reports that SQL backups are OK / replica is consistent. The issue that I have is that when 'synchronization' occurs, it appears to temporarily lock the log files so that any further write operations from the SharePoint production system fail with a SQL block / deadlock / access denied error.

    I was wondering if this is normal behaviour, if so then I would reconfigure the synchronizations to happen after-hours.

    Thanks.

    Thursday, November 15, 2012 3:13 AM
  • Hi Andrew,

    It's a strange behaviour.

    During Sync your SQL server only transfert commited transaction to DPM server.

    Do you have any other SQL process that running during your Sync ? You should use SQL profiler to see what's happen.

    Edit: from SLQ query you could run DBCC TRACEON  (1204, -1) to activate trace of deadlock in your SQL logs. When finished run DBCC TRACEON  (1204, -1)

    Stephane


    Please remember to click “Mark as Answer” on the post that helps you. This posting is provided "AS IS" with no warranties. knowledge is valid only if it is shared by All.

    My DPM blog Yet Another DPM Blog


    Thursday, November 15, 2012 10:34 AM