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 Boot Verification
VM boot tests (like Veeam SureBackup or NinjaOne boot verification) are a useful automated first pass. They should be enabled on every backup plan as a baseline. They catch gross failures... corrupted images, missing boot sectors, OS-level problems.
Boot 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
Until automated hash verification is built, human-performed backup testing is required, but the cadence depends on the client's tier (see below). Where full application-layer testing is performed, technicians must manually verify application data as described above. Automated boot verification and per-job integrity checks supplement but do not replace a full restore test.
HCB-MSP (Hybrid Cloud Backup) — routine testing: For clients on HCB-MSP, the VM boot test is the only backup-layer test DTC performs on a routine basis. Server VMs are boot-tested every two weeks (bi-weekly) against the most recent daily backup versions, confirming the image boots as a VM and the OS comes up; workstations are not boot-tested. In addition, the platform runs an integrity check daily on every backup job. Together these form the standing verification layer for HCB-MSP — daily per-job integrity checks plus bi-weekly server VM boot tests, and nothing further on a routine basis. The bi-weekly VM boot schedule applies to NinjaOne-backed servers; it is not performed for Veeam BDR clients, which use SureBackup and other automated verification methods per their own standards.
Full backup testing (the full application-layer restore test described above — databases, blob files, and application functionality) is not part of the routine HCB-MSP schedule. For HCB-MSP, DTC performs a full application-layer backup restore test on demand: when a regulator or compliance audit requires it, or when the client requests it — for example, a cyber-insurance verification request. For higher tiers (BDR, Availability) and clients with standing compliance obligations, full backup testing is performed on a schedule determined by the client's tier and compliance requirements.
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.