This morning we came across an interesting issue with DPM 2012, something which is really trivial, but really annoying if you don't know what is wrong!
Recently I moved our DPM servers over to DPM 2012 - and was amazed by how smoothly it went (more because I'm used to upgrading Backup Exec and watching the earth cave in), and all seemed to be working well.
However, I'm VERY paranoid when it comes to backups - and so my colleague has responsiblity for making sure backups happen - reviewing reports and so on. We'd been using the reporting in DPM 2010 quite happily, he received and reviewed the reports on a regular basis.
Since 2012 he'd not been getting them... it seems that the reporting gets broken on an upgrade, and the SMTP Server settings were not right anymore - bizarrely each server we had seemed to have different states - one had no SMTP Server details anymore, one had them but complained they weren't right, and the other had half of the settings. All very strange.
In theory this wasn't an issue - back into SMTP Settings, repopulate and reconfigure the reporting part.
Or not...
Despite having all the details in the "SMTP Server" setting, and having those details set correctly (validated by the send test option and the receipt of a test e-mail etc) we couldn't setup any of the reports.
Why?
Error 3010
"DPM cannot setup an e-mail subscription for this report"
(and then advises you to go and setup your SMTP Server!)
It turns out that the issue is in fact that SQL Reporting Services doesn't actually have the details you entered - from what I can see, the system still looks in the DPM 2010 instance of SQL (because it doesn't remove it or the instance of old SQL it made) at upgrade, so it updates that instead. D'oh!
Whilst that's clearly a bug and should be fixed, the good news is that there is a quick fix.
Go into SQL Reporting Services Configuration, log into the DPM2012 instance, choose the "E-Mail Settings" and fill in the Sender Address and SMTP Server. Save that and you're golden.
Just some Sysadmin's view of the world of Backups for Small/Medium Businesses using Backup Exec and Microsoft Data Protection Manager. Experiences, tips, problems, rants and ideas. We eventually gave up with Backup Exec, so while this was "Backup Exec Hell - The Daily Torture of making Backup Exec 10d, 12d and 12.5 work..." it's now "The Joy of Microsoft DPM. Although it isn't perfect, it's a damn sight better.
Showing posts with label debugging. Show all posts
Showing posts with label debugging. Show all posts
Thursday, 23 August 2012
Tuesday, 18 August 2009
Debugging Mode for Remote Agent...
Right now I have a problem where a customers server just doesn't backup. Not for love nor money. The connection is over a WAN type connection, so not your average setup, but none the less, working fine previously.
First of all we suspected the comms - e.g. VPN, the Routers, the provider connection, and did the usual testing to be sure that isn't the cause. We saw a couple things that made us "think" the isuse was there but nothing too worrying.
Not a problem though, we've got multiple WAN links, and another way to get to the other end. A couple config changes, and the route now uses a different WAN link at both ends (e.g. BEWS Media Server and RAWS Enabled Server being backed up).
Problem still exists. So it's not comms then (given the other links switched to backup another server at the same site daily (40-60Gb/day without complaint).
So the issue is likely something with the server being backed up.
The point of the post though, is to let you know how to temporarily enable the debug backup logging on the Remote Agent (RAWS).
Stop the service, add "-debug" (no quotes) to the "startup parameters" in the services management in Admin Tools (or start > run > services.msc and hit enter...)
Start the service. You're good for logs until the next restart of services/server reboot.
Logs go in your backup exec install directory on the server being backed up, in the Logs subfolder named beremote... something...
(Oh yeah, and a warning, the debug logs are HUGEEEEEE)
First of all we suspected the comms - e.g. VPN, the Routers, the provider connection, and did the usual testing to be sure that isn't the cause. We saw a couple things that made us "think" the isuse was there but nothing too worrying.
Not a problem though, we've got multiple WAN links, and another way to get to the other end. A couple config changes, and the route now uses a different WAN link at both ends (e.g. BEWS Media Server and RAWS Enabled Server being backed up).
Problem still exists. So it's not comms then (given the other links switched to backup another server at the same site daily (40-60Gb/day without complaint).
So the issue is likely something with the server being backed up.
The point of the post though, is to let you know how to temporarily enable the debug backup logging on the Remote Agent (RAWS).
Stop the service, add "-debug" (no quotes) to the "startup parameters" in the services management in Admin Tools (or start > run > services.msc and hit enter...)
Start the service. You're good for logs until the next restart of services/server reboot.
Logs go in your backup exec install directory on the server being backed up, in the Logs subfolder named beremote... something...
(Oh yeah, and a warning, the debug logs are HUGEEEEEE)
Subscribe to:
Posts (Atom)