Backup & Data Resilience

Design for recovery, retention, and proof.

45 min3 lessons3 retrieval drills

The promise

What you will be able to do by the end of this module

Separate backup from recoverability in a way that changes what the customer measures, and scope the two backup workloads accurately.

  • Separate a backup job that ran from a restore you have proved, and make the customer feel the difference.
  • Name the two backup types and the four restore paths, and say which ones customers have never tested.
  • Explain why device backup and SaaS backup are different products protecting different workloads.
  • Ask for RPO and RTO separately for an endpoint and for a mailbox, and know what different answers reveal.
  • Keep archive and backup distinct so legal and security stakeholders stay in the room.
  • Confirm the tenant's backup region before a network team writes an allowlist that silently breaks backup only.
Start from what you already know

Green backup jobs are not recoverability. The distance between a successful job and a proved restore is where the bad quarter lives, and most customers have never measured it.

01

Portfolio map

Three products, three jobs

Device Backup protects endpoint and server workloads. SaaS Backup protects Microsoft 365 and Google Workspace data. Email Archiving retains searchable email for governance and discovery.

  • Recovery asks how fast and how granularly data must be restored.
  • Retention asks how long data must remain and under what policy.
  • Scope asks which endpoints, servers, tenants, services, users, and locations matter.
  • Operations asks who monitors, tests, approves, and reports.
02

Design method

Start with workload and business consequence

Define RPO and RTO intent, data volume, connectivity, retention, security boundary, recovery location, and evidence requirements before selecting a policy.

Credibility rule

A green backup job is not recovery proof. Include a restore test and record the result.

03

Demo

Show the recovery moment

A data-protection demo should spend less time on policy creation and more time on finding the right recovery point, choosing restore scope, controlling access, executing recovery, and verifying the outcome.

Mechanics

How it actually behaves

Each item is tagged with how far it can be trusted. Verified means checked against official documentation; field means it is our recommendation, not a vendor claim; unpublished means NinjaOne does not state it at all.

Two backup types with different jobs

verified

Image backup for full system recovery, and file/folder backup for selective protection. They answer different questions and have different restore paths.

Destinations are cloud, network storage, or hybrid

verified

Hybrid gives a fast local restore path plus an offsite copy. When a customer says 'we back up to a NAS', the missing half of the sentence is offsite.

Four restore paths, and they are not equivalent

verified

File-level recovery, image restore, bare metal recovery, and recovery to virtualization. Bare metal and virtualization are the ones that matter in a real disaster conversation, and they are the ones customers have never tested.

Boot verification exists as a distinct capability

verified

Validating that a backup actually boots is the difference between a job status and a recoverability claim. Make them ask for it by name.

Backup regions are separate S3 estates

verified

Distinct buckets for us-west-1, us-west-2, us-east-1 and us-east-2. Allowlisting the wrong region breaks backup while everything else keeps working — a uniquely confusing failure.

Not an official source: NinjaOne's canonical allowlist article (ninjarmm.zendesk.com/hc/articles/211406886) requires an authenticated support account and returns HTTP 403 to anonymous requests, so it could not be cited directly. This is a partner's published mirror of that list. Treat the hostnames as a starting point and re-verify inside your own tenant before handing them to a network team.

Device backup and SaaS backup are different products for different workloads

verified

Device backup protects the endpoint. SaaS backup protects data in platforms like Microsoft 365. They fail for unrelated reasons and should never be described interchangeably.

Backup Alerts are conditions

verified

Backup Job Duration Alert and Backup Job Last Success Threshold Alert make backup health part of the same alerting model as everything else, rather than a separate console someone remembers to check.

What NinjaOne does not publish

Exact retention periods, revision counts, and storage quotas are not published on the public documentation index. Confirm them in the tenant or with NinjaOne rather than quoting a number.

Discovery

Ask these, then listen

When did you last do a real restore, not a job status check?

Listen for: Silence is the answer you are looking for. Do not fill it.

What is your RPO and RTO for a lost laptop versus a lost mailbox?

Listen for: Different answers prove they need two different products. Same answer means they have not thought about it.

If your file server died right now, what is the actual sequence?

Listen for: Vagueness after step two is where bare metal recovery enters the conversation.

Demo path

Three moves, in this order

  1. 1

    A file-level restore.

    This is the ninety percent case — someone deleted something.

  2. 2

    Boot verification.

    This is the difference between a backup and a recovery you can promise.

  3. 3

    SaaS backup next to device backup.

    Two workloads, two failure modes, one console.

Objection handling

What they say, what you say, how you prove it

Microsoft 365 already backs up our data.

It replicates and has limited retention windows. Retention is not the same as recovery from a deletion you discover months later.

Proof method: Ask what their retention window actually is and what happens on day after. Most do not know.

Is this an archive?

No. Archive is durable retention optimised for search and governance. Backup is operational recovery. Different products, different questions.

Proof method: Making this distinction unprompted is how you keep legal and security stakeholders in the room.

Where SEs blow it

Do not say these

  • Never use backup and archive interchangeably.
  • Do not quote retention or revision limits from memory — NinjaOne does not publish exact figures on the open documentation index.
  • Confirm the tenant's backup region before the network team writes the allowlist.

From NinjaOne's channel

Watch it explained

Short clips from NinjaOne's own channel that reinforce the mechanics above. Each one says why it is here and what it backs up. These are supporting context, not product demonstrations — the sourced claims stay in the mechanics section.

Why this is here: The two backup types and their different jobs. Transcript-verified and directly on point: file/folder is faster and more storage efficient, image takes a complete system snapshot.Watch on YouTube ↗
Why this is here: Backup is not recoverability. Transcript-verified: 'your backup is only as good as its ability to recover data' — the exact distinction this module is built on.Caveat: Walks through Synology Active Backup, not NinjaOne. Use it for the principle and the test method, never as a NinjaOne product demonstration.Watch on YouTube ↗
Why this is here: 'Prove' is the operative word — the same standard as boot verification over a green job status.Watch on YouTube ↗
Why this is here: Immutability as a ransomware control, and why retention design is a security decision.Caveat: Azure-specific walkthrough rather than NinjaOne backup configuration.Watch on YouTube ↗

Retrieval practice

Rapid fire

Answer aloud before opening each response.

01Backup versus archive?

Backup is optimized for recovery after loss or corruption; archive is optimized for durable retention, search, and governance.

02SaaS is already redundant - why backup?

Service availability and customer-controlled recovery/retention are different concerns.

03Best proof point?

A successful, timed, verified restore that meets an agreed recovery objective.