Guest Column | January 25, 2016

5 Reasons Why RMM Fails Backup Checks

By Patrick Leonard, Founder & CEO, Backup Radar

Any good managed services provider (MSP) will agree, remote monitoring and management (RMM) tools are not engineered to check the success of backups. The core competency of RMM is to make it simple and profitable for an MSP or IT services provider to remotely monitor and manage a client’s environment.

When the attempt is made, most RMM tools utilize SNMP or PowerShell to check backup jobs which experienced MSPs know can be quite buggy at times. We’ve seen hundreds of examples where the RMM tool reported a success yet the backup wasn't running for weeks. That’s not cool on so many fronts — especially if things hit the fan during this period, or if the client is within a highly regulated industry where fines and penalties can make or break the business.

Reliability Is Required, Not Recommended

SNMP and PowerShell will likely never be a reliable method for checking backups because they depend heavily on the server or computer working properly. Add to that the potential for an RMM agent to be unstable (never happens right?) and an MSP could be spending vast amounts of time on the phone with their RMM vendor trying to fix it. 

Trending Is Telling

Most RMM tools provide the quick and dirty on whether a server has a successful or failed backup in most cases. What they don’t offer is a real view into how often the backups are failing and if the same backups fail multiple times. Without the history, an MSP or IT service provider will never know the cause and will continue to have gaps in their backup processes and checking.

Prioritization Is Pivotal

RMM tools are black and white — they note success or failure. For backup administration custom thresholds are critical because they allow the provider to prioritize the backup checking processes and ensure the backup admin handles the most critical servers first. Without tagging those servers as mission critical and prioritizing the remediation time, an MSP or IT services provider is putting their client at risk for data loss, and the company at risk for breach of contract. A backup admin only has so much time in a day and needs to spend it making sure the client and the company’s critical data and systems are protected. 

Schedule-Based Tracking Plays Tricks

 When a backup is scheduled to run only during certain time periods, the unknowing RMM tool will report that as a failure, taking no account of the date and time period during which a successful backup should routinely occur. These failures will likely also show up on client-facing reports unless the MSP or IT service professional manually removes them — another time suck and opportunity for mishaps.

Multiplicity Matters

Many backup providers can backup multiple servers with one backup job. In this case if any server fails it will report a failure for the entire job. Now that’s a troubleshooting pain in the ass. This means no way of separating the devices into metrics per device that make sense. An RMM tool will see the entire job as a failure and the backup report will reflect the single job as a failure. 

At the risk of stating the obvious, RMM tools don’t do a great job of reporting on disparate backup systems. Though they can usually be tweaked to check results, they will almost always fail when it comes time to gather and report on backup data. What’s needed is an invisible, affordable, cloud-based layer of intelligent software that will work across the RMM, PSA, and backup solution of choice, to establish, centralize and control backup policies so the MSP or IT service provider is receiving a far more granular perspective of what’s really going on when it comes to any and all backups. 

Patrick Leonard has more than 15 years of IT experience and industry level engineering certifications. He holds certifications with Microsoft, Cisco, Citrix, VMWare among others. He has worked with the team at My IT, LLC to build a very successful MSP practice. As COO/VP at My IT, Patrick was instrumental in evaluating My IT's processes and inefficiencies regarding backup management which led to Backup Radar being developed internally.