NinjaOne Image Backup Plan Configuration Standard
⚠️ WARNING: ALL BACKUPS MUST BE TESTED AFTER SETUP. Configuring a backup plan is not the end of the job. After the first successful backup completes (typically within a few days of deployment), perform a test file restore to confirm the backup is producing usable data. Your ticket for this work stays open until the restore test is complete and documented. A backup that has never been restore-tested is not a backup... it is a hope.
This page defines the standard NinjaOne image backup plan configuration for all endpoints receiving Hybrid Cloud Backup service. Every NinjaOne-backed endpoint must match these settings unless a documented exception exists.
For the overarching backup philosophy, RPO/RTO targets, and retention standards, see Backup & Data Protection Standards in Pillars of Technology.
Image Backup Plan Settings
Device Selection
DO NOT CHECK "ALL SERVERS" OR "ALL WORKSTATIONS". When assigning the backup plan to devices, select workstations and servers individually. Checking "All Servers" will include Hyper-V hosts, which DTC does not back up as a whole... ever, with any product. Hyper-V guest VMs are backed up individually at the VM level through NinjaOne. Backing up the host itself creates massive, useless images and wastes storage and bandwidth. Checking "All Workstations" risks enrolling machines that should not be backed up (loaners, staging machines, decommissioned endpoints still in NinjaOne).
Select only the specific devices that should receive NinjaOne image backup. For servers, this means the guest VMs running Dentrix/Dexis, domain controllers, or standalone file servers... never the Hyper-V host itself. For workstations, select only the machines confirmed for backup service + any exec/vip/manager/financial/imaging workstation. Never bulk-select all devices in an organization without reviewing what's enrolled.
Local Backup Path
The local backup destination for every NinjaOne image backup must be the site NAS:
\\$NAS_NAME\backups\ninjaone$NAS_NAME is the hostname of the NAS at that location. This path must exist and be accessible from the endpoint before the backup plan is enabled. If the NAS share doesn't exist, create it before deploying the plan.
General
Setting | Value |
|---|---|
Plan Status | Enabled |
Backup destination | Hybrid (local image + cloud image) |
Schedule | Daily |
Time | 12:00 AM local device time |
Exclude weekends | Unchecked (backups run 7 days/week) |
Retention
Setting | Local | Cloud |
|---|---|---|
Keep backups for | 1 month | 1 month |
Keep daily for | 14 days | 14 days |
After daily window | Weekly until 1 month limit is reached | Weekly until 1 month limit is reached |
These values align with DTC's retention standard: 14 days of daily granularity, then weekly versions until the 1-month retention ceiling.
Volume Exclusion
All volumes are included by default. Do not exclude specific drive letters. Every volume on the endpoint gets backed up unless it contains data that is re-creatable or temporary (optical drives, removable media, scratch disks). The only setting to configure here is:
Setting | Value |
|---|---|
Exclude removable disk | Checked |
If a volume needs to be excluded, document the reason in the client's documentation. A technician who excludes a data volume is responsible for the gap.
Power Options
Setting | Value |
|---|---|
Prevent device from sleeping | Checked |
Attempt to wake device if sleeping | Checked |
Run plan immediately if missed | Checked |
"Prevent device from sleeping" ensures the backup window completes without the OS suspending mid-job. "Run plan immediately if missed" handles cases where the endpoint was off or unreachable at the scheduled time... the backup fires as soon as the device comes online.
Pre/Post Plan Automations
Setting | Value |
|---|---|
Run script before backup job | Unchecked (no pre-plan scripts by default) |
Run script after backup job | Unchecked (no post-plan scripts by default) |
Pre/post scripts may be configured per-client if specific application quiescing or notification requirements exist. The default is no scripts.
Boot Verification
Setting | Value |
|---|---|
Test the Windows OS volume for ability to boot image backup | Checked |
Boot verification must be enabled on every image backup plan. This is a baseline automated integrity check... it confirms the backup image can boot a VM. It does not constitute a full backup test (see Backup & Data Protection Standards for what a full test requires), but it catches gross image corruption automatically.
⚠️ MANUAL VM BOOT TESTING IS FOR SERVERS ONLY. DTC does not perform manual VM boot testing on workstations... ever. Workstations are protected by the automated boot verification checkbox above and nothing further. Manual VM boot testing is a server-only activity.
Two separate things — do not confuse them:
- Automated boot verification (the plan setting above) runs on every image backup plan — servers and workstations. NinjaOne verifies the image can boot as a VM as part of the backup job.
- Manual VM boot testing is a server-only human-performed bi-weekly check (described below). Workstations are excluded entirely from this step — there is no manual boot-test equivalent for workstations.
Bi-weekly Manual Server VM Boot Testing: Every two weeks, a technician boots the most recent daily backup image of each server as a VM, confirms the OS starts, and documents the result. This tests the daily versions to verify they're producing viable server restore points. See the Backup & Data Protection Standards for the full backup testing philosophy.
Disabling vs. Removing Backup Deployments
Disabling a backup plan only disables the schedule. The plan still exists, the machine still appears in backup reporting, and the existing backup data remains tied to the endpoint. If you are decommissioning a machine from backup entirely, disabling the plan is not enough.
To fully remove a machine from NinjaOne backup (including removing it from backup reporting and releasing associated data after the 90-day orphan retention window):
If you only disable the plan, the machine will continue to show as a backup-enrolled device with a stale last-backup date... creating false reporting and confusion about what is and isn't actually protected.
Immutability Note
NinjaOne does not offer an explicit immutability setting. However, NinjaOne retains backup data for 90 days after an endpoint is deleted from the management console. This provides orphan-data protection against accidental or malicious endpoint deletion. This is documented in the Backup & Data Protection Standards immutability section.
Bandwidth Throttling
Per the Backup & Data Protection Standards, backup traffic must be limited to 20% of client bandwidth during business hours and 80% outside business hours.
NinjaOne does not offer per-plan or per-endpoint bandwidth throttling controls within the backup plan configuration. Bandwidth limits for NinjaOne Backup are managed at the NinjaOne organization policy level or via network-level QoS on the client's firewall/router.
Implementation options:
- NinjaOne org-level throttle: If NinjaOne provides a global bandwidth cap in the organization or policy settings, set it to 20% of the client's WAN upload bandwidth as the safe default. This ensures business hours are protected. The tradeoff is that after-hours backups also run at 20%, which is acceptable for Hybrid Cloud Backup's 1-day RPO... the backup will complete overnight regardless.
- Firewall/router QoS: Configure traffic shaping on the client's firewall to throttle NinjaOne cloud backup traffic (destination IPs/ports) to 20% during business hours and 80% after hours. This is the more precise approach but requires per-client firewall configuration.
- Scheduling as implicit throttle: Since NinjaOne image backups are scheduled at 12:00 AM, the bulk of backup traffic naturally falls outside business hours. The "Run plan immediately if missed" catch-up is the main risk for daytime bandwidth... if a missed backup fires during patient hours, it will run unthrottled unless QoS is in place.
Document the chosen approach and calculated bandwidth values in the client's documentation.
Configuration Checklist
Prerequisite: Before configuring any backup plans on endpoints, you must add the local backup storage location to the client's NinjaOne organization. Without this, endpoints have nowhere to write local image backups.
Adding a Backup Storage Location to the Organization
Important: Verify the path is reachable from at least one online endpoint at the site before saving. If the path is wrong or the credentials are stale, backup plans assigned to endpoints in this org will fail silently on the local leg.
Deployment Checklist
When deploying or auditing a NinjaOne image backup plan, verify every setting matches this page:
- Devices selected individually (NOT "All Servers" or "All Workstations")
- Backup storage location configured at org level
- Plan enabled
- Backup destination: Hybrid
- Schedule: Daily at 12:00 AM local device time
- Weekends included (not excluded)
- Local retention: 1 month, daily for 14 days
- Cloud retention: 1 month, daily for 14 days
- All volumes included (only exclude re-creatable/temporary data)
- Removable disk excluded
- Prevent device from sleeping: checked
- Run plan immediately if missed: checked
- Boot verification: checked
- No unexpected pre/post scripts
- Storage location credentials use
dtcbackupservice account (NOT NAS admin) - After first successful backup: test file restore completed and documented
- Ticket remains open until restore test passes