Skip to main content

NinjaOne Backup — Architecture Deep Dive: Lockhart, Cloud Storage & Hybrid Model

Audience: T1 / T2 Use when: You need to understand how NinjaOne Backup actually works before troubleshooting a failure — or when a tech asks "why isn't the backup running?"

This page goes deeper than the setup SOP (page 1062). Understanding the architecture is what lets you correctly diagnose whether a failure is a local issue, a NAS issue, or a cloud issue.

The Two Services on Every Backed-Up Machine

Every device with NinjaOne Backup has exactly two services running:

Service Display Name What It Does
NinjaRMMAgent NinjaOne Agent The main RMM agent — monitoring, patching, remote access
Lockhart NinjaOne Backup (codename: Lockhart) The backup agent — takes snapshots, writes to NAS, uploads to cloud

These are independent. The NinjaOne agent can be online while Lockhart is stopped (and vice versa). A device showing "online" in NinjaOne does not mean backups are running — always check the Lockhart service separately.

# Check both services at once
Get-Service | Where-Object {
    $_.DisplayName -like "*NinjaRMM*" -or
    $_.DisplayName -like "*Lockhart*" -or
    $_.DisplayName -like "*NinjaOne Backup*"
} | Select DisplayName, Status, StartType

How a Backup Job Actually Runs

Understanding the sequence tells you exactly where to look when something breaks:

[Scheduled time hits]
        │
        ▼
[Lockhart wakes up]
        │
        ▼
[Contacts NinjaOne cloud to retrieve NAS credentials]  ← Error 317 if this fails
        │
        ▼
[Connects to NAS share via SMB]  ← Error 303/305/315/316 if this fails
        │
        ▼
[Requests VSS snapshot from Windows]  ← Error 132/307/309/327 if this fails
        │
        ▼
[Reads changed blocks since last backup]
        │
        ├──► Writes changed blocks to NAS (local leg)  ← Error 319/342/344/345 if this fails
        │
        └──► Uploads changed blocks to NinjaOne cloud (AWS)  ← Error 360/131/10053/10054 if this fails
        │
        ▼
[Job completes — NinjaOne marks as Success]

This sequence is why error codes map to specific legs of the job. When you see an error, place it on this diagram — that tells you exactly what layer to investigate.

The Three Backup Destinations

Mode What Gets Backed Up When to Use
Local (NAS only) Writes to NAS share only — no cloud Only used for devices without cloud entitlement (rare at DTC)
Cloud only Uploads to AWS only — no NAS Roaming laptops or devices with no on-site NAS
Hybrid Writes to NAS first, then syncs to cloud DTC standard — all stationary dental workstations and servers

DTC standard (per page 1421): Hybrid, daily at midnight, 1 month retention, 14 daily revisions locally and in cloud.

Leg dependency — local failure blocks cloud: Hybrid is sequential — NinjaOne writes the backup to the NAS first, then syncs that local copy to the cloud (per NinjaOne's Network Storage documentation). The cloud copy is built from the completed local backup, not captured independently from the source. Consequence: if the local NAS leg fails, there is nothing to sync, so the cloud leg does not run and the device gets no backup — neither local nor cloud — for that cycle.

Where Data Lives

Local (NAS):

\\NAS-HOSTNAME\backups\ninjaone\
  └── [DeviceName]\
        └── [revision folders...]

Accessible directly via file browser. Useful for fast local restores without pulling from cloud.

Cloud (AWS S3): Managed entirely by NinjaOne. DTC has no direct access to the S3 bucket. Access is only through the NinjaOne console restore interface. Data is AES-256 encrypted at rest and in transit.

Cloud immutability (AWS S3 Object Lock): Backups stored in NinjaOne's cloud are immutable for the duration of the retention period via AWS S3 Object Lock. Once a revision is written, it cannot be modified or deleted — not by NinjaOne, not by DTC, and not by an attacker who has compromised admin credentials. Confirmed directly by Jeff Hunter, NinjaOne Field CTO (April 29, 2026).

Why this matters:

  • Ransomware recovery — even if a site's local NAS is encrypted or wiped, cloud revisions remain intact and restorable.
  • Insider threat / compromised admin — a bad actor with NinjaOne console access cannot purge backup history; the object lock is enforced at the AWS storage layer.
  • Cyber insurance — most carriers ask whether backups are immutable. For NinjaOne cloud backups the answer is yes, and object lock satisfies that control.

Scope and limits: Immutability applies to the cloud copy only. The local NAS leg of a hybrid backup is a standard SMB share and is not immutable — it should be treated as a fast-restore convenience, not a tamper-proof layer. Per-NAS protections (read-only snapshots, snapshot retention, restricted SMB ACLs) are configured separately and are independent of NinjaOne.

Image Backup vs. File/Folder Backup

Type What It Captures Restore Options DTC Use
Image Backup Full volume snapshot (block-level) — OS + data + config Full bare metal restore, volume restore, or cloud mount for file-level Servers and key workstations
File/Folder Backup Specific paths only Individual file/folder restore Targeted data protection; not used for full system recovery

DTC standard: Image backup for all devices in scope. File/folder is an addition when specific paths need more frequent protection.

Retention: How Old Data Gets Removed

NinjaOne uses incremental, block-level backups with deduplication. The retention policy defines how many revisions are kept:

  • DTC standard: 1 month / daily for 14 days (both local and cloud)
  • Trimming runs automatically — old revisions are removed as new ones come in
  • On NAS: trimmed revisions are deleted from the share — unless the NAS recycle bin is enabled (which causes Error 344/345 accumulation — always disable the recycle bin on the backup share)

Key Terminology Reference

Term Meaning
Lockhart Codename for the NinjaOne Backup agent service. Named for future white-labeling.
Hybrid Local NAS + cloud — the DTC standard backup mode
Revision A single point-in-time backup snapshot
Block-level Only changed data blocks are backed up after the first full run — not the whole disk every time
dtcbackup The service account DTC uses for NAS authentication — not the NAS admin account
Boot verification NinjaOne's feature that periodically boots a VM from the backup image to confirm it's bootable
Back to top