Skip to main content

NinjaOne Backup — Backup Integrity: Manual Verification & Spot-Check Procedure

Audience: T2 Use when: Verifying that a specific device's backup is genuinely usable, not just "green" in the console — or investigating whether a backup that's been running for months has actually been producing reliable data.

Why Console Green Isn't Enough

A backup job can report success while producing partially usable data if:

  • Files were skipped due to open file VSS warnings
  • The cloud leg succeeded but the local NAS leg was silently failing
  • Revisions exist but the most recent one is weeks old due to a misconfigured schedule
  • The backup has been running in file/folder mode rather than image mode

This page walks through confirming actual data quality, not just job status.

Step 1 — Confirm Revision Count and Recency

# In NinjaOne console:
# Device → Backup → Manage → Image Backup Plan
# Check:
# - How many revisions exist?
# - What is the timestamp of the most recent revision?
# - Is the most recent revision from within the last 24 hours?

# Expected: 7–14 revisions within the retention window, most recent < 24 hours old

If the most recent revision is more than 48 hours old: the backup schedule may have stalled. Check Lockhart status and backup plan assignment.

Step 2 — Confirm Both Legs Are Succeeding

For hybrid backup (DTC standard), both the local and cloud legs must complete:

  1. NinjaOne → device → Backup → click the most recent job entry
  2. Expand the detail — both "Local" and "Cloud" should show success
  3. If cloud shows "Skipped" or "Failed" while local shows success: cloud upload is broken — investigate Error 360/131

Step 3 — Test File Restore (The Real Verification)

This is the only definitive proof the backup is usable:

  1. NinjaOne → device → Backup → Manage → select the most recent revision
  2. Navigate the file tree to C:\Windows\System32\drivers\etc\hosts (small, always present, easy to verify)
  3. Click Download or Restore to alternate location
  4. Confirm the file downloads successfully and has content
  5. Delete the test file from the alternate location

If this works: the backup is producing usable data. If it fails: investigate per the restore troubleshooting page.

Step 4 — Spot-Check Critical Dental Data Paths

For servers running dental software, verify the backup captured the data that matters:

# Paths to verify are present in the most recent revision
# Browse in NinjaOne's restore file browser to confirm these exist:

# Dentrix
C:\Dentrix\

# Eaglesoft
C:\EagleSoft\

# Open Dental
C:\OpenDentalData\   # or wherever OD data is hosted

# CS Imaging
C:\ProgramData\Carestream\   # or the configured image repository path

# DEXIS / DTX Studio
C:\ProgramData\DEXIS\

# General: confirm the dental server's D: or E: data drive is included
# (many dental databases live on secondary drives)

If these paths are missing from the file browser: the backup plan may have incorrect volume inclusions. Review the backup plan settings against page 1421.

Step 5 — Verify Open Files Were Handled via VSS

Dental databases are always open during business hours and often after. Confirm VSS handled them:

  1. NinjaOne → device → Activities → find a recent successful backup job
  2. Click to expand — look for VSS-related entries
  3. "VSS snapshot created successfully" = databases were captured in a consistent state
  4. If the job completed but shows "VSS snapshot warnings": some open files may have been skipped — investigate

Spot-Check Documentation Template

When performing this check for a ticket or migration verification, document:

Device: [hostname]
Date checked: [date]
Most recent backup: [timestamp]
Revision count: [number]
Local leg: [Success/Failed]
Cloud leg: [Success/Failed]
Test restore: [Performed / Not performed]
Test file restored: [filename]
Test result: [Success/Failed]
VSS status: [Clean/Warnings]
Critical paths verified: [Yes/No — list any missing]
Technician: [name]
Back to top