Skip to main content

NinjaOne Backup — Post-Migration: Confirming Cloud Sync is Working

Audience: T1 / T2 Use when: Verifying that NinjaOne's cloud upload leg is working correctly after migration — not just the local NAS leg.

A common post-migration failure mode: the local backup runs fine (NAS writes succeed) but the cloud sync never completes. The device shows "Success" but the cloud leg silently fails. This page confirms the cloud leg is actually working.

Why Cloud Sync Can Fail Silently After Migration

During the MSP360 era, cloud credentials were managed by DTC (Backblaze S3 keys). In NinjaOne, cloud credentials are managed by NinjaOne — the device must be able to reach NinjaOne's AWS endpoints. If the site has anything blocking outbound HTTPS to *.amazonaws.com or *.ninjarmm.com, the local backup runs but cloud upload silently fails or retries indefinitely.

Step 1 — Confirm the Cloud Leg Is Actually Succeeding

This is not the same as confirming the overall job succeeded:

  1. NinjaOne → device → Backup → click the most recent job entry
  2. Expand the detail — look for separate "Local" and "Cloud" leg statuses
  3. Both must show Success — not just the top-level job result

If Cloud shows "Skipped," "Failed," or is missing entirely: the cloud leg is not working. Proceed to Step 2.

Step 2 — Confirm Cloud Revisions Exist

Revisions visible in the restore browser come from either local or cloud:

  1. NinjaOne → device → Backup → Manage
  2. In the revision list, check the source indicator — some revisions are local-only, some are cloud-synced
  3. For full disaster recovery capability, you need cloud revisions — not just local NAS revisions

Step 3 — Test Cloud Connectivity From the Device

$endpoints = @(
    "backup.ninjarmm.com",
    "app.ninjarmm.com",
    "s3.amazonaws.com",
    "s3.us-east-1.amazonaws.com"
)

$endpoints | ForEach-Object {
    $r = Test-NetConnection -ComputerName $_ -Port 443 -WarningAction SilentlyContinue
    [PSCustomObject]@{
        Endpoint  = $_
        Reachable = $r.TcpTestSucceeded
    }
} | Format-Table -AutoSize

Any False result: cloud upload cannot work. Fix the firewall/DNS issue first.

Step 4 — Trigger a Manual Backup and Watch the Cloud Leg

  1. NinjaOne → device → Backup → Run Backup Plan
  2. Monitor Activities tab — watch for the job to complete
  3. When complete, expand the job detail and confirm both legs show Success
  4. Note: the cloud leg completes after the local leg — allow extra time on slow uplinks

Step 5 — Confirm Initial Cloud Upload Is Not Stuck

For a newly migrated site, the first cloud upload is a full image — this can take hours or days on a slow connection. It is not stuck if:

  • The job is showing "In Progress" with an active cloud upload percentage
  • Lockhart is running and consuming network I/O
  • The NinjaOne activity log shows upload progress updating

It may be stuck if:

  • The job has been "In Progress" for more than 48 hours with no percentage change
  • Error 360 or 131 keeps firing and the percentage never advances
  • Lockhart is idle (no CPU/network activity) but the job shows In Progress

If stuck: restart Lockhart and trigger a fresh run. NinjaOne's resume capability will pick up from the last successful block.

Expected Timeline for First Cloud Upload

Data Size Upload Speed Estimated Time
50 GB 10 Mbps upload ~12 hours
100 GB 10 Mbps upload ~24 hours
200 GB 10 Mbps upload ~48 hours
500 GB 10 Mbps upload ~5 days
500 GB 50 Mbps upload ~24 hours

Most dental sites have 10–25 Mbps upload. Plan accordingly and don't flag slow initial uploads as failures.

Back to top