Skip to main content

NinjaOne Backup — Error 131: Connection Lost During Backup

Audience: T2 Use when: Backup fails with "Error 131: Connect lost during backup operation."


What This Error Means

Unlike Error 360 (which fires when the cloud is unreachable from the start), Error 131 means Lockhart established a connection to NinjaOne's cloud and began the upload — but the connection was dropped mid-transfer. The backup was in progress and then the network link broke.

Because NinjaOne uses block-aware incremental backups with resume capability, Error 131 does not mean all data is lost. The next backup attempt will resume from the last checkpoint, not restart from scratch.


Common Causes

Cause Signal
ISP instability during overnight backup window Intermittent connectivity; ping tests show drops late at night
Router/UDM rebooted or lost WAN during backup UDM uptime shows recent restart; ISP dropped
Upload throttling causing timeout Very large backup on a slow upload connection
MTU mismatch causing fragmented packets to fail Specific large-payload connections drop; small pings succeed
Firewall session timeout during long upload Stateful firewall drops long-lived TCP sessions

Step 1 — Check If This Is Recurring

A single Error 131 during a multi-hour first backup is normal — ISP connections fluctuate. The question is frequency:

  • Once or twice: Monitor — NinjaOne will resume automatically on the next backup cycle
  • Multiple consecutive nights: Investigate the network path
# Check NinjaOne activity log for pattern
# (Review in NinjaOne console: Device → Activities → filter by backup)
# Look at what TIME failures are occurring — does it correlate with a specific hour?

Step 2 — Check ISP Stability During the Backup Window

# Run a long ping test overnight to the ISP gateway and an external host
# Run before midnight and check results in the morning
ping 8.8.8.8 -n 3600 -l 1400 > C:\Temp\ping_results.txt

# Check for "Request timed out" entries in the output
Select-String "timed out" C:\Temp\ping_results.txt | Measure-Object

If packet loss occurs: ISP or modem issue. Flag to the AM — this needs a broader discussion with the client's ISP.


Step 3 — Check UDM Uptime and WAN Health

  1. Log into UniFi → Dashboard → check UDM uptime and WAN status
  2. Review the event log for any WAN disconnect/reconnect events during the backup window
  3. Check if the modem is in IP Passthrough mode (DTC standard) — if in bridge mode, there may be NAT session timeout issues

Step 4 — MTU Troubleshooting (If Pings Succeed But Transfers Drop)

If small pings work but large file transfers fail mid-stream, an MTU mismatch may be causing packet fragmentation failures:

# Test if large packets are getting through (adjust IP to your ISP gateway)
ping 8.8.8.8 -f -l 1472   # Standard MTU of 1500 minus 28 bytes for headers
ping 8.8.8.8 -f -l 1400   # Smaller test
ping 8.8.8.8 -f -l 1300   # Even smaller

# If 1472 fails but 1300 works: MTU is the issue

Set the UDM WAN MTU to 1400 or enable MSS clamping (Settings → Internet → Advanced → MTU). Standard UDM default (1500) can cause issues on PPPoE or certain ISP connections.


Step 5 — Firewall Session Timeout (Long Upload Kills)

Some firewalls or ISP equipment drops TCP sessions that are idle for extended periods. For a multi-hour backup upload, this can terminate the connection. Adjusting TCP keepalive settings on the device can help:

# Increase TCP keepalive on the device (reduces idle session drops)
# Run as Administrator
netsh int tcp set global keepalivetime=60000
netsh int tcp set global keepaliveinterval=1000

Note on Resume Behavior

NinjaOne's block-aware design means Error 131 does not require a full restart. On the next backup cycle, Lockhart picks up from the last successfully uploaded block. For a first backup on a slow link, multiple Error 131 occurrences before completion is expected behavior.


Escalate to T2 If:

  • Error 131 occurs every night for a week with no successful cloud completion
  • ISP stability is confirmed good but uploads consistently fail
  • MTU changes and session timeout adjustments don't resolve it