Data Protection Manager and SQL Server Failure
BBigford last edited by scottalanmiller
Hey pros, I need your help.
I'm beating my head against a wall now, as I've nearly exhausted ideas for this. On our System Center Data Protection Manager 2010, there are some inconsistencies. We get errors on the SQL databases/protected members saying "Replica is Inconsistent". This is happening on SQL2014 on a 2012R2 box, as well as a SQL version that is a few years old on a 2008R2 box. Through a lot of online research, I've:
*Enabled Windows Backup Services on both the source and target.
*Ran a consistency check.
*Checked the drive space (expanded it another 150GB last night).
*Rebooted the hosts.
*Deleted/re-added to the protection group.
The only thing we haven't done is completely delete the protection groups and start from scratch. That obviously is not ideal but we're getting there. Everything online that I've read, I've tried. Can't think of anything else!
Dashrender last edited by Dashrender
What happens when you run a manual backup of the SQL DB in SQL Manager? Maybe the DB has some corruption.
BBigford last edited by BBigford
I didn't use Studio, I did it via command line (System, then bare metal). System state took up a bunch of space, then got an error was not enough space available. I increased the size and the command executed successfully, but still same issue. I can try a manual backup via Studio though, shouldn't be any different though...? The only thing left I could think of is that box has 32GB and there is something to the tune of 30DBs on that VM. DPM has only 4GB allocated to it, which is pegged. I was thinking maybe the backup was queuing up and timing out. The consistency check fails within 10 seconds though. I do understand that SQL and Exchange are much alike and will peg any amount of ram on a server but I questioned the amount of ram in that config. Right now, we don't have more in place to allocate. It is on order, but looking for an answer sooner than that. That server only has SQL running on it.
I should also note, not all the DBs on that VM are failing checks. Only about 1/3 of the DBs are not backing up successfully.
Reid Cooper last edited by
32GB seems like enough RAM that the system should not be corrupting because it is out of RAM.
Long shot, but have you looked in the logs to see if there is anything sticking out in there as potentially being a problem?
BBigford last edited by
@Reid-Cooper Nothing that was sticking out like a sore thumb. I also went ahead and ran a vssadmin list writers and it processed zero errors (thinking maybe there was a problem with shadow copy). At this point, they basically have no backups so I'm debating moving the backups and replicating a fresh start.
BBigford last edited by
Got it solved. I started pointing them at a new server (basically starting from scratch). Still got some inconsistencies but that was resolved by toggling the agent to the new server (after I already pointed it at it). Then I fixed the last couple with a disk allocation mod. What a mind-blowing, super frustrating piece of software.