Backup & Data Protection Standards
Backup & Data Protection Standards
This document defines DTC's backup philosophy, tiered service models, RPO/RTO commitments, retention policies, immutability requirements, and backup verification methodology. It is the authoritative reference for how we protect client data.
Tiered Backup Service Model
DTC offers three tiers of backup and data protection. The tier a client receives is determined by their service agreement and the performance characteristics of their environment.
Tier 1 — Availability (BDR + Replication/Failover)
Full BDR plus real-time or near-real-time replication to a secondary target (cloud or secondary appliance) with automated or semi-automated failover. This is the highest level of data protection DTC offers.
Prerequisite: Replication requires the client to have identical (or near-identical) servers at the replication target — matching hardware specs, storage capacity, and performance characteristics. The replica must be able to run the production workload at the same performance level as the primary. This is why Tier 1 is the most expensive tier and why not every client qualifies: you're paying for a second server that sits idle until failover. If the replica can't match production performance, the client drops to Tier 2 (BDR without replication).
Replication is not backup. Replication creates a running copy of the production environment that can take over immediately. Backup creates point-in-time snapshots for recovery. They solve different problems: replication solves uptime (the server dies and the practice keeps working), backup solves data loss (someone deletes a database and you need yesterday's version). Tier 1 clients get both because they need both.
RPO: 4 hours maximum, targeting 1 hour where achievable. Because replication handles the continuous data protection layer, backups only need to run once per day. Replication runs hourly (or more frequently) to meet the RPO objective independently of the backup schedule.
RTO: 2 hours.
Key distinction: Backups and replication serve different purposes here. Backups are for point-in-time recovery and long-term retention. Replication is for failover and continuity. Don't over-backup an Availability client just because you can... one clean daily backup plus hourly replication is the correct configuration.
Tier 2 — Backup & Disaster Recovery (BDR)
Full image-based backup with local appliance and cloud replication. This is the standard for clients who pay for BDR services.
RPO: 4 hours maximum. If the client's environment can sustain 1-hour backup intervals without performance degradation, we target 1 hour. If the application stack (Dentrix, Eaglesoft, etc.) cannot handle the I/O overhead of hourly snapshots, we fall back to 1 nightly backup as the hard floor. There is no middle ground... either the environment supports aggressive RPO or it gets one clean nightly image.
RTO: 2 hours.
What this means: If a server dies, we can have them running on the BDR appliance or restored from cloud within 2 hours. RPO determines how much work they lose... 1 hour in the best case, up to 4 hours standard, or 1 business day if performance constraints forced nightly-only.
Tier 3 — Hybrid Cloud Backup (HCB-MSP)
Cloud-based backup only, with local image cache. No availability, no quickboot, no failover functionality. This is the entry-level data protection tier.
RPO: 1 day (24 hours).
RTO: 1 week. HCB-MSP has no rapid-recovery path, so the recovery-time objective is always 1 week — never 1 day.
What this means: The client has backup protection but no rapid recovery path. Restoring from cloud takes time. This tier is appropriate for clients who need data protection but haven't purchased rapid recovery capabilities.
Retention Standards
The default retention policy is 14 daily versions plus weekly versions out to a 30-day total retention window, kept on both local (on-prem) and cloud. Extended retention beyond 30 days (additional weekly versions, monthly, yearly) is configured per-client upon request and is not part of the standard deployment.
Default — 14 Daily + Weekly to 30 Days
- Daily versions: 14 days, on both local (on-prem) and cloud
- Weekly versions: retained past the daily window to fill out a 30-day total retention window, on both local and cloud
The standard retention window is 30 days. The most recent 14 days are kept as daily versions on both local and cloud; once a backup ages past the 14-day daily window, it is rolled into a weekly version and retained out to the 30-day mark. This gives day-level granularity for recent recovery and weekly checkpoints for the rest of the month, with local and cloud configured identically.
NinjaOne Hybrid Cloud Backup: NinjaOne implements this model natively — its retention controls keep 14 daily versions on both local and cloud and automatically roll older versions into weekly versions to fill the 30-day (1-month) retention window. What used to be documented as a NinjaOne-specific behavior is now the DTC default. See the NinjaOne Image Backup Plan Configuration Standard for specifics.
Per-Client Request — Extended Retention
Retention beyond the standard 30-day window — additional weekly versions, monthly versions, and yearly versions — is not enabled by default. These are configured only when a client explicitly requests extended retention, typically for compliance, legal hold, or insurance requirements.
When a client requests extended retention, configure the following where the backup platform supports it:
- Weekly versions: Up to 6 weeks (extends the default weekly tier past the 30-day window)
- Monthly versions: Up to 6 months
- Yearly versions: Up to 3 years
Document the client's requested retention schedule and the reason for it in their client documentation. Extended retention increases cloud storage costs and must be accounted for in the client's billing.
Platform Behavior Notes
Some platforms (like NinjaOne) automatically roll daily versions into weekly versions as part of their retention model — which is exactly the DTC default. Other platforms (like Veeam) allow discrete GFS (Grandfather-Father-Son) configuration; configure GFS to produce the standard 14 daily + weekly-to-30-days result. Beyond the 30-day default window, configure only the extended retention the client has requested and the platform supports. Don't add retention tiers past the default unless the client has asked for them.
Immutability
Immutable backups are required wherever the technology supports it. This is a compliance requirement, not optional.
Where Immutability Applies
- Veeam Backup & Replication: Supports immutability natively. Enable it. This is non-negotiable for BDR and Availability clients.
- NinjaOne Backup (cloud only): Cloud backups are immutable via AWS S3 Object Lock. Confirmed directly by Jeff Hunter, NinjaOne Field CTO (April 29, 2026). Once a revision is written to the cloud, it cannot be modified or deleted by NinjaOne, by DTC, or by an attacker with NinjaOne console access. Important scope limit: the local NAS leg of a hybrid backup is a standard SMB share and is not immutable... treat it as a fast-restore convenience, not a tamper-proof layer. Separately, NinjaOne retains all backup data for 90 days after an endpoint is deleted from the management console, providing recovery from accidental or malicious endpoint deletion.
- Any solution with native immutability support: Enable it.
Where Immutability Is Not Available
- Other solutions without immutability: If a backup solution cannot provide immutability and the client requires it for compliance, that client must be moved to a BDR solution that supports it (e.g., Veeam). Do not try to engineer immutability into a platform that doesn't support it natively.
The Rule
If immutability is required and the technology can't do it, change the technology. Don't force a workaround.
Backup Network Throttling
Backup traffic must be throttled relative to the client's available WAN/LAN bandwidth to prevent impact on clinical operations.
During business hours (operational hours): Backup and replication traffic is limited to 20% of the client's available network bandwidth. Dental offices run latency-sensitive applications (Dentrix, Eaglesoft, imaging workflows, VoIP) and cannot tolerate backup jobs saturating the pipe during patient hours.
Outside business hours: Backup and replication traffic can use up to 80% of the client's available network bandwidth. The remaining 20% headroom accounts for overnight processes, updates, after-hours remote access, and any staff still working.
How to apply this: The exact Mbps values must be calculated per-client based on their ISP bandwidth. For a client with 100 Mbps, that's 20 Mbps during business hours and 80 Mbps after hours. For a client with 50 Mbps, that's 10 Mbps and 40 Mbps respectively.
This policy applies to all backup solutions (Veeam, NinjaOne) and all tiers (BDR, Availability, Hybrid Cloud). See the solution-specific configuration pages for how to implement the throttle in each platform.
Backup Verification & Testing
What a Backup Test Is NOT
A virtual machine booting from a backup image is not a complete backup test. A VM boot proves the disk image is structurally intact enough for the OS to start. It does not prove:
- Application databases are consistent and queryable
- Blob files (images, documents, attachments) are intact
- Line-of-business applications can start and serve data
- The backup contains the data the client actually needs to operate
What a Full Backup Test Requires
A full backup verification must test application-layer data, not just OS boot:
- Database availability: Spin up every line-of-business database (Dentrix, Eaglesoft, Open Dental, practice management, imaging, etc.) and verify they accept connections and return data. A SELECT query against key tables is the minimum.
- Blob/file integrity: Spot-check a representative sample of blob files (X-ray images, scanned documents, attachments). Open them. Verify they render correctly.
- Application functionality: Where possible, launch the application and verify it loads patient data or equivalent business records.
Automated Verification
Automated verification is the L1 rung of the ladder below. It catches gross failures — corrupted images, bad blocks, missing boot sectors, OS-level problems — without anyone touching a console. It is not a data test. Neither a booting image nor a passing checksum tells you whether the practice management database inside it is consistent or whether the imaging blobs open.
DTC runs two different automated methods, one per platform:
- NinjaOne — a bi-weekly cloud VM boot test of servers, built from the most recent cloud backup revision. Standing configuration on all NinjaOne-backed servers unless a ticket documented an exception.
- Veeam — automatic data integrity checks of the stored backup files, validating block checksums against what was written. SureBackup is not deployed, so Veeam clients are integrity-checked, not boot-tested.
See Current Standard below for the exact posture and the wording to use with clients.
Automated verification can be extended with scripts to:
- Connect to databases and check availability
- Query key tables for row counts or checksums
- Test blob file integrity if hashes are stored alongside the files
Future State: Hash-Based Verification
DTC's roadmap includes automated hash-based backup verification:
- Database integrity: Dump the database, hash the dump, store the hash. On boot verify, re-dump and compare hashes. If they match, the database survived the backup/restore cycle intact.
- Blob file integrity: For applications that store file hashes alongside their blob data, compare hashes post-restore. For applications that don't, a file watcher service could hash files offline and maintain a reference database. This is significant engineering effort and is not happening soon.
Current Standard
DTC's assurance activity is described using the five levels below. Use these names in tickets, in client conversations, and in this KB — do not use the bare word "test" without a level. The client-facing version of this section, with the reply wording and the compliance context, is the "Do you test our backups?" — Compliance and Testing Answer Playbook. This page remains authoritative; the playbook restates it.
| Level | Term | What it proves | Cadence | Included by default? |
|---|---|---|---|---|
| L0 | Backup Monitoring | A job ran and reported success, and how long since the last successful backup. Nothing about contents. | Continuous | Yes — every tier, every protected device |
| L1 | Backup Verification (automated, platform-level) | The stored backup data is intact — the image boots (NinjaOne) or the backup files pass a checksum integrity check (Veeam). Nothing about application data. | Automatic, per platform — see below | Yes — both platforms |
| L2 | Restore Test — file level | A named file or folder can be recovered from a specific revision and opened. | At deployment (mandatory), then on request | At deployment: yes. After that: on request |
| L3 | Restore Test — application level | The line-of-business database restores, starts, accepts connections and returns real records; blob files open and render. | On demand only | No — requires a written SOP, scoped and quoted |
| L4 | Disaster Recovery Exercise | The site can be returned to operation end-to-end inside its RTO, with a written result. | On demand only | No — project engagement, scoped and quoted |
Each level proves only its own line. A green console does not imply intact backup data. Intact backup data does not imply a working database. Short of a full environmental restore we are checking files, checksums, or that an image boots — the data is very likely fine, but it is never guaranteed, and DTC does not claim otherwise.
L0 — Monitoring. Routine monitoring measures job success/failure and the time since the last successful backup, on every protected device, continuously. This is the baseline and it is included in every tier.
L1 — Automated verification. Both platforms verify automatically. They verify different things, and the difference matters when you are answering a client:
| Platform | Method | What it actually checks |
|---|---|---|
| NinjaOne (HCB-MSP) | Bi-weekly cloud VM boot test of servers, built from the most recent cloud backup revision | The image is structurally sound enough to boot and bring up the OS |
| Veeam (BDR, Availability) | Automatic data integrity checks on stored backup files | The backup files are not corrupt — block checksums still match what was written |
- NinjaOne boot verification runs on all NinjaOne-backed servers by default. The only exceptions are sites where a ticket explicitly documented a change. Workstations are not boot-tested. If a server is not boot-verified, there must be a ticket saying why.
- Veeam SureBackup is not deployed at DTC. Veeam clients get automated data integrity checking, not automated boot testing. Do not tell a Veeam client their backups are boot-tested, and do not tell them they have no automated verification either — they have integrity checks. Be precise about which one.
- Open item: NinjaOne likely performs data integrity checking of its own, but this is not documented or confirmed. Do not claim it to a client until it is verified and written down here.
L2 — File-level restore test. Mandatory at every deployment (see below), and performed on request at any time. Procedure: NinjaOne Backup — Backup Integrity: Manual Verification & Spot-Check Procedure.
L3 and L4 — application-level restore testing and DR exercises. These are not performed proactively or on a standing schedule for any tier by default. DTC performs them on demand: when a client requests one, or when a regulator, auditor or insurer requires one. Because "test the backup" is a category rather than a task, DTC does not begin L3 or L4 work until a written procedure has been agreed between the client and DTC covering four things:
- Scope — which servers, applications and databases are in the test.
- Pass criteria — what specifically must be true for the test to pass. ("Dentrix opens and returns yesterday's appointments" is a criterion; "the backup works" is not.)
- Cadence — annual, semi-annual, quarterly, driven by the client's own obligation.
- Evidence — the document the client receives and who signs it.
L3 and L4 are not part of the standard managed services agreement and may carry additional service charges. Where a client has a standing compliance obligation, the agreed cadence lives in that client's documentation and overrides the default of "on demand only" for that client alone. Until automated hash-based verification exists, L3 testing is performed manually as described above; L1 verification supplements it but never replaces it.
Initial Deployment Verification
⚠️ Every new backup deployment MUST be restore-tested before the work is considered complete. Configuring a backup plan and watching the first job succeed is not enough. After the first successful backup (typically within a few days of deployment), perform a test file restore to confirm the backup is producing usable, recoverable data. The ticket for backup setup stays open until that restore test is completed and documented. A backup that has never been restore-tested is not a backup... it is a hope.
This applies to all tiers, all platforms, all new deployments and migrations. No exceptions.
Backup Credentials
All backup platforms (Veeam, NinjaOne, MSP360, etc.) must authenticate to local storage using the dtcbackup service account. Do NOT use NAS admin accounts, domain admin accounts, or any credential with broader access than the backup share requires. The dtcbackup account gets read/write access to the backup share and nothing else... zero trust, least privilege.
See the Client Credential Administration Standard for service account naming conventions, access restrictions, credential storage requirements, and rotation policy.
RPO/RTO Quick Reference
Tier | Service | RPO | RTO | Backup Frequency | Notes |
|---|---|---|---|---|---|
1 | Availability | 4 hrs (target 1 hr) | 2 hrs | Daily backup + hourly replication | Replication meets RPO |
2 | BDR | 4 hrs (target 1 hr) | 2 hrs | Hourly if achievable, nightly if not | Performance-dependent |
3 | Hybrid Cloud (HCB-MSP) | 1 day | 1 week | Daily | No failover capability |
Retention Quick Reference
Scope | Local (On-Prem) | Cloud | Default? |
|---|---|---|---|
Daily versions | 14 days | 14 days | Yes — standard |
Weekly versions | To 30 days total | To 30 days total | Yes — standard |
Weekly versions (extended) | Up to 6 weeks | Up to 6 weeks | Per-client request |
Monthly versions | — | Up to 6 months | Per-client request |
Yearly versions | — | Up to 3 years | Per-client request |
NinjaOne implements this default model natively — 14 daily versions plus weekly versions to fill the 30-day window, on both local and cloud. See the NinjaOne configuration standard.
Where This Is Heading
This page is the policy in force. The reasoning behind the shift away from image-first protection toward layered, application-aware capture in native formats — and the criteria that decide which model a site gets — is recorded separately in Backup Methodology & Direction. Nothing on that page is in force until it is ratified into this one.