MSP360 Backup

OpsMerge integrates with MSP360 Backup (formerly CloudBerry) to surface backup status across your fleet inside the OpsMerge dashboard. Failed backups become alerts and tickets via your normal alert rules.

What you get

• Backup state per endpoint — last successful backup, next scheduled, status, size.
• Backup failure alerts — pulled from MSP360 and emitted as OpsMerge alerts with alert_type = msp360.
• Restore-point summary — how many restore points exist per endpoint, going how far back.
• Per-client backup health — rollup of backup state across all the client's endpoints.

Setup

What you need

• An MSP360 Backup tenant.
• API credentials (username + password for MSP360's API, or a dedicated API user).

Connection

Settings → Integrations → MSP360 → Connect.

Fields:

• API endpoint: https://api.mspbackups.com (default; override only for non-cloud deployments).
• Username and password — these are the MSP360 API credentials, separate from your dashboard login.

Click Test connection. OpsMerge attempts login and reports back.

Per-tenant credential storage

We encrypt MSP360 credentials at rest using a per-tenant key. Same model as the Bitdefender integration. The credential is never logged or returned to the UI in clear.

Hostname matching

MSP360 reports devices by hostname. OpsMerge matches MSP360 devices to OpsMerge agents by hostname (not by HID — MSP360's internal device identifier).

This is the right approach for most cases but worth knowing: a renamed device in MSP360 will appear "lost" to OpsMerge until either MSP360 catches up or you manually re-link.

Sync cadence

Adaptive polling:

• Hourly when no recent activity at the client.
• Every 10 minutes when active.
• On-demand: client → MSP360 tab → Sync now.

No webhooks (MSP360's webhook surface isn't comprehensive enough).

What backup state flows in

For each backed-up device:

• Last backup status: Success / Failed / Skipped / Warning.
• Last backup time and duration.
• Next scheduled backup (per-plan).
• Backup size for the latest set.
• Restore points count and oldest available.

Backup failures become alerts. Default alert rule (shipped):

• Trigger: alert with type = msp360 AND status = Failed.
• Action: create ticket, priority = High, assign to assigned-account-tech.

You can scope, disable, or replace this rule like any other alert rule.

The wire shape (worth knowing)

If you've worked with MSP360's API directly, OpsMerge handles five gotchas that bit us during initial integration:

1. Login response shape differs between docs and live API — we use the live shape.
2. /Monitoring endpoint fields are a slightly different set than docs suggest.
3. Timestamps come back in mixed formats (ISO-8601 most of the time, some Unix epochs); we normalise.
4. PlanType enum has values not in the public docs; we handle the unknowns gracefully rather than failing the row.
5. ErrorMessage JSON shape is sometimes a string, sometimes an object. We treat both as strings for our purposes.

None of these are visible to you — they're internal — but they mean the integration is more robust against MSP360 quirks than a naive REST client would be.

Common patterns

"Daily 'who didn't back up last night' report"

Filter the OpsMerge MSP360 view by status = Failed and time = last 24h. The report's exportable.

You can also build a recurring Reports run that emails this to you at 09:00 daily.

"Per-client backup health for monthly client reviews"

Each client has a Backup tab (when MSP360 is connected and the client is mapped). The tab shows aggregate health, failed backups, restore-point summary, and an exportable PDF report.

"Backup alert escalates if not resolved within 24h"

Standard alert escalation rules. Settings → RMM → Alert rules → MSP360 failure → add "if unresolved after 24h, re-fire at Critical".

Common issues

Devices in MSP360 don't appear in OpsMerge. Mapping not set, or hostname mismatch. Settings → Integrations → MSP360 → Mappings — set the client mapping; then check if the MSP360 device hostname matches the OpsMerge agent's hostname.

Login fails despite correct credentials. MSP360 has session limits per credential — if the same credential is being used elsewhere (e.g. another tool), OpsMerge can be locked out. Use a dedicated API user.

Status updates lagging behind MSP360 UI. Adaptive polling — for quiet clients, hourly. Force a sync from the client's MSP360 tab to pull immediately.

Alert fires for a backup that succeeded. Look at the alert details — sometimes MSP360 reports a backup as Failed when only one plan among several failed, even though the "main" plan succeeded. OpsMerge surfaces the most recent run for each plan; if your alert rules don't filter by plan, you'll get noise. Add a plan filter to the alert rule.

MSP360 docs say field X exists but OpsMerge doesn't show it. Could be a docs/live mismatch (see "wire shape" above). Tell us which field; we'll check whether to expose.

Disconnect

Settings → Integrations → MSP360 → Disconnect.

Stops polling. Existing backup-history alerts stay; ongoing data flow stops.

To re-enable: connect again. Existing mappings are remembered.

Next

• Monitoring & alerts — how backup failures become alerts
• Tickets — backup failures as tickets