Multi-Location Clients Need a Different Backup Plan Than Single-Site Ones

When MSPs develop a backup strategy, they tend to follow a similar pattern:

• Figure out what's on the server
• Pick a schedule
• Set retention
• Done.

This works great when your customer has one office with one server. But what about businesses that operate across multiple physical locations?

Throughout the blog, we will use All Smiles Dental as an example. All Smiles Dental is a dental group that manages the IT for multiple dental offices. They have five practices spread across the region. Each practice was opened or acquired at a different time and has its own systems and IT history. In theory, they are one customer. In reality, however, the only things they have in common are a shared name and one invoice.

What actually changes once a business looks like that, and what does it mean for how you set up and manage their backups?

Table of Contents

1. One Console, Not Five Logins
2. Infrastructure Won't Match Across Sites
3. Practice Management Software Fights the Backup Job
4. Encryption Has to Be Consistent
5. Naming Conventions
6. Retention Isn't One-Size-Fits-All Across Sites
7. Recovery Priorities Need to Be Decided Before an Incident Occurs
8. Onboarding and Offboarding a Single Location Cleanly
9. Alerts Need to Be Specific
10. Billing Gets Harder to Track
11. Frequently Asked Questions
12. The Takeaway

One Console, Not Five Logins

Assuming you don't only check your customers' backups when an alert is sent via email — because that would be suboptimal, no matter how many clients your customer has — checking the backup status of a single-site client usually takes about five seconds. However, if the client has five locations, you either have to log into five separate systems or find them all in your dashboard (more on how to simplify that under naming conventions).

For All Smiles Dental, the MSP needs a single view showing all backup jobs, alert statuses, and encryption states. A setup that requires logging into each site's console separately is not scalable past two or three locations. This is the same problem discussed in our blog article, "What Managed Backup Actually Looks Like in Practice".

Infrastructure Won't Match Across Sites

Customers with multi-location businesses rarely have identical setups at every location, especially if some locations were acquired over time rather than set up by you from scratch. For example, one All Smiles Dental location might use Hyper-V for its practice management server, another might use a physical server, and a third might use a combination of the two plus a NAS that was added a few years ago.

That inconsistency must be planned for. This means that the backup policy must account for working on a VM in one location and a physical server in another, while ensuring that the RTO and RPO agreed upon with the customer align across all sites.

VM backup deserves its own line item because snapshot consistency and VM-aware backup require a different approach than physical file servers. Therefore, the backup plan requires different configurations for retention and the schedule at which backup jobs run, among other things.

Practice Management Software Fights the Backup Job

This one is specific to companies that rely on database-driven applications, such as dental and medical practices. For example, All Smiles Dental's practice management software (Eaglesoft, Dentrix, etc.) typically keeps its database open continuously. If a backup job doesn't handle open files correctly, it may report success every night. Yet, the database wouldn't start once recovered because fractions of the data are missing.

This is a known failure mode of databases. Open-file handling (VSS or an application-aware agent) must be verified in every location using this type of software. We also discussed this scenario in more detail in our blog post, "Why backups fail in SMB environments". The article also explains how a job can appear to run properly for weeks while missing a critical folder because the folder was moved, and the backup job does not include the new location.

Encryption Has to Be Consistent

For a HIPAA-regulated business like a dental group, encryption at rest and in transit isn't optional. The real question, though, is whether every site enforces the same standard and manages encryption keys as a process rather than handling them ad hoc by whoever is on site that week.

It's not unusual for an encryption passphrase to be sent via email or chat during a reset or tech handoff because it's the fastest way to unblock someone (although, we recommend not doing that). But if this is the only record you or your customer have, it becomes problematic once the person who sent it moves on to a different account or company.

Patient records are kept at every All Smiles Dental location. Therefore, the group's compliance posture must include documentation of who owns the encryption keys, as well as their rotation and handoff when staff or subcontracted technicians change.

Further reading

Demystifying HIPAA Compliance for Medical Practices and Dentists

A full breakdown of what HIPAA compliance actually requires beyond encryption alone.

Read the guide

Naming Conventions

This may sound minor, but it can make backup management much easier.

For environments with one server per customer, a naming convention can be as simple as ClientName-Server. For clients with multiple sites, a different naming convention that also includes location information is needed. Having an agreed-upon, intuitive naming convention ensures that, for example, if oversight ever changes hands between technicians or MSPs, everyone will still know which backup job belongs to which customer.

Retention Isn't One-Size-Fits-All Across Sites

Not every location generates the same volume or type of data. For example, one medical practice with in-house imaging generates far more data than a satellite office that mostly handles scheduling and billing. Applying one blanket retention policy to both would be wasteful at the small site and insufficient at the imaging-heavy site.

Our blog, "Creating a Backup Plan? Ask These Questions First," walks you through setting retention by data classification rather than by default settings. This logic applies per location, not just per customer.

Recovery Priorities Need to Be Decided Before an Incident Occurs

If a customer has only one server, it's easy to decide which server should be prioritized for recovery. Multiple servers across multiple locations, on the other hand, require you to decide in advance which location gets restored first.

All Smiles Dental customers may have considered what would happen if their locations went down simultaneously. Should the practice with imaging equipment get priority, or the one seeing the most patients that day? It's important to have that conversation with your customers ahead of time so that you know what to do immediately and don't have to wait to hear from them about which location to check on first.

Onboarding and Offboarding a Single Location Cleanly

Acquisitions, opening new locations, and closing locations all require defined processes for onboarding and offboarding, especially if resources are shared across locations.

This can get messy when multiple devices or sites point to the same cloud storage account to save on costs or simplify setup. Deleting an agent is straightforward. Untangling one site's data from a storage bucket that several other active sites still depend on? Not so much.

That's why All Smiles Dental has standard naming and retention procedures to quickly incorporate new locations into the same backup system. If a location ever closes, its backup data must be extracted cleanly without becoming tangled in a cloud account that is still in use by other sites. This is why they set up unique accounts for every machine in every office they back up.

Alerts Need to Be Specific

Instead of a generic email that simply says, "All Smiles Dental backup warning," the alert should specify which location failed, which goes back to the naming convention. When the alert specifies the location and system that ran into an issue, your technicians have an easier time fixing it.

Billing Gets Harder to Track

Per-location usage reporting is more important here than for a single-site client. Five locations generate five different data volumes, so the MSP might have to show what's being backed up and billed for at each site rather than presenting one invoice line for "All Smiles Dental" that no one can reconcile.

Additionally, when several clients have the same product that is renewing around the same time, an invoice or renewal notice that lists only the product name, not the client name or location, becomes difficult to reconcile. Usage-based reporting tied to the client and site by name avoids that entirely.

Frequently Asked Questions

The Takeaway

A multi-location client isn't just a larger version of a single-site client. It's five (or however many) points of failure that require one point of visibility, one consistent policy, and a process to maintain consistency as the client grows or changes while considering the unique environment of each location.

If you're onboarding a multi-location client and want guidance on setting this up correctly from the start, talk to a NovaBACKUP expert. We can review your specific setup, site by site, before problems arise.

Worth Reading

Für Kunden mit standortübergreifenden IT-Umgebungen reicht ein Standard-Backup-Plan nicht aus

Best Practices

Für Kunden mit standortübergreifenden IT-Umgebungen reicht ein Standard-Backup-Plan nicht aus

23.09.2026, 08:00:00 7 min read

Antworten auf die 9 häufigsten Backup-Fragen von MSPs (2026 Update)

Backup Software

Antworten auf die 9 häufigsten Backup-Fragen von MSPs (2026 Update)

03.09.2026, 08:00:01 10 min read