Flamingo Raises $4.5M Seed Round

Skip to content

Updated: October 2026

Both backup types copy only what changed, so on a dashboard they look almost the same. The difference shows up twice: in how much storage the week eats, and in how many files a restore needs when something breaks. Here's what each one copies, a worked week of storage math, what a restore depends on, and how to pick.

The Short Version

A full backup copies everything. An incremental backup copies what changed since the last backup of any kind. A differential backup copies what changed since the last full backup.

FullIncrementalDifferential
What it copiesEverythingChanges since the last backupChanges since the last full
Size of each backupLargestSmallestGrows every day until the next full
Backup speedSlowestFastestSlows as the week goes on
What a restore needsOne fileThe full plus every increment sinceThe full plus the latest differential
Where it hurtsStorage and backup windowOne bad file breaks the points after itStorage late in the cycle

How a Full Backup Sets the Base

Every scheme starts with a full backup. It's the base that both incrementals and differentials depend on, so if the full is missing or damaged, nothing built on it restores.

That's why fulls get scheduled on a cycle, weekly or monthly, even when changes are small. A new full starts a new chain and caps how far a restore has to reach back.

PowerCert's short animated explainer shows the three types side by side, if you want the picture before the math.

Incremental Backup: Small Files, Long Chains

An incremental backup copies only the blocks or files that changed since the previous backup, whatever type that was. Monday's increment holds Monday's changes, Tuesday's holds Tuesday's, and so on.

That makes each run fast and small, which is why incrementals fit tight backup windows and frequent schedules. The cost comes at restore time. To get back to Saturday, the software needs the full plus every increment from Monday to Saturday, applied in order.

Differential Backup: Files That Grow Until the Next Full

A differential backup copies everything that changed since the last full backup. Microsoft's SQL Server documentation puts it plainly: "A differential backup captures only the data that has changed since that full backup," and the full it depends on is called the base.

The catch is growth. Each differential includes everything since the base, so Tuesday's contains Monday's changes too. Microsoft notes that differentials "can eventually approach the differential base in size," which is why it recommends a new full at set intervals to reset the base.

The upside is the restore. You need two files: the full, and the most recent differential. Nothing in between.

The Storage Math Over One Week

Here's an illustrative example, not a benchmark. Take a 500 GB server with a full backup every Sunday, and assume 2% of the data changes each day, about 10 GB. Assume each day changes different blocks, which is the worst case for differentials.

DayIncremental sizeDifferential size
Sunday (full)500 GB500 GB
Monday10 GB10 GB
Tuesday10 GB20 GB
Wednesday10 GB30 GB
Thursday10 GB40 GB
Friday10 GB50 GB
Saturday10 GB60 GB
Week total560 GB710 GB

The differential week costs 150 GB more, about 27% on top of the incremental week. Stretch the full to monthly and it gets worse: by day 30 a single differential in this example is 300 GB, 60% of the full itself.

Now the restore. Getting Saturday back reads 560 GB either way, the full plus 60 GB of changes. The difference is how many files it takes: seven for the incremental chain, two for the differential.

What Each Restore Needs

File count matters because every file in a chain has to be readable. With incrementals, one damaged or missing increment breaks every restore point after it. With differentials, a bad file costs you that one day, and the next differential still restores against the full.

In this r/msp thread, an MSP running continuous incrementals checked its chains every week and still hit a wall: the recent recovery points wouldn't mount, and the last clean one was the start of a fresh chain four weeks earlier.

Incrementals are still the right tool for frequent backups. Keep the chains short, verify them automatically, and restore from them on a schedule, so a broken link shows up on a Tuesday afternoon instead of during an outage. The disaster recovery testing guide sets out a cadence for those restores.

Synthetic Fulls and Forever-Forward Chains

Modern backup tools blur the line between the two types. A synthetic full is a full backup built on the backup storage from the last full plus its increments, without reading the production server again. You get a fresh base and a short chain without a long backup window.

Forever-forward incremental goes a step further. Veeam's retention documentation describes it: when the chain exceeds its retention, the oldest increment is merged into the full and then removed, so the full "moves" forward one step. The chain never grows past the retention you set.

Both push work onto the backup storage, so slow repositories make them slow. In this r/sysadmin thread, admins compare how often they run active fulls against synthetic ones, and why fast storage changes the answer.

Backup Types Against Ransomware

Ransomware changes what "restore" means. You rarely want the newest restore point, because it may already contain the attacker. Mandiant's M-Trends 2026 puts the global median dwell time at 14 days, so the clean point you need can sit two weeks back.

That puts pressure on retention, not type. An incremental chain has to keep every link back to that clean point, and a differential scheme has to keep the full it was built on. Either way, store the chain where the attacker's credentials can't reach it, on immutable or offline storage, and make sure the retention covers more than two weeks.

Which One Fits, and Where RPO Comes In

Start by separating two decisions that get merged. How much data you can lose, your recovery point objective (RPO), is set by how often the backup runs, not by its type. An incremental every hour and a differential every hour both give you a one-hour RPO. Our RTO vs RPO guide covers setting those targets.

The backup type decides the other trade-offs. Pick incremental when backups run often, bandwidth or the backup window is tight, and your tool verifies chains and builds synthetic fulls. Pick differential when restores need to be simple and fast, storage is cheap, and the data changes slowly enough that differentials stay small between fulls.

For a lot of servers the answer is both: incrementals through the day, a synthetic full each week, and a restore test that proves the chain works.

Pick the Chain You Can Restore

Incremental saves storage and differential saves restore steps, and synthetic fulls let you keep most of both. Whatever you pick, the chain is only as good as the last time you restored from it.

For the tools that run these schedules, our roundup of MSP backup solutions is the next read.

Conrad Lunderstedt

Conrad Lunderstedt

Solution Architect

I'm Conrad, Solution Architect at Flamingo. I've spent about 26 years in IT, roughly half of it inside MSPs and the rest in enterprise environments, so I've watched vendor decisions get made on both sides of that line. Now I spend my days talking with MSPs about the stack they already run, and helping them work through the requests and issues that come with it.

Related Content

Blog Posts

Product Releases

Podcasts

Webinars

Case Studies

Events

Onboarding Guides

Frequently Asked Questions

Backup Types

A full backup restores fastest because it is a single file. Between the two partial types, a differential restore is simpler: it needs only the last full and the latest differential, while an incremental restore needs the full plus every increment since, applied in order.
Restores depend on every file in the chain, so one damaged or missing increment breaks every restore point after it, and long chains take more steps to restore. Short chains, automatic verification and regular synthetic or active fulls keep that risk down.
A synthetic full is a full backup built on the backup storage from the last full plus its increments, without reading the production server again. It resets the chain and gives you a fresh base without a long backup window.
Neither type decides the outcome on its own. What matters is keeping enough retention to reach a restore point from before the attacker got in, and storing the chain on immutable or offline storage the attacker cannot reach.

About OpenFrame

OpenFrame isn't built to plug into your stack. It replaces it. Instead of duct-taping a dozen tools together (RMM, MDM, SIEM, patching, remote access, each its own login and bill), we bundle it into one unified platform: RMM, MDM, monitoring, automation, remote access, patch management, security monitoring, and ticketing, plus built-in AI copilots. So "does it integrate with X?" usually means: you won't need X anymore.
Most platforms give you one piece and expect you to bolt the rest on. OpenFrame unifies the whole stack in one place, with AI copilots built in. Fewer logins, fewer bills, less duct tape.
In the cloud, on US soil. Your data stays stateside.
Both. It's built for MSPs and MSSPs alike.

MSP AI Agents

Yes. In production MSP shops today, 10% to 25% of tickets close before a human opens them. Thread alone has processed 173 million tickets across 750-plus MSP partners at 96% triage accuracy, handing back 490,000-plus technician hours. Agents own the low-risk, high-volume work (password resets, MFA enrollment, known installs, onboarding and offboarding) and flag anything that touches production data or needs judgment for a human to take.
On a five-person desk, reported deployments show $78,000 to $130,000 in annual direct labor savings, roughly 30% fewer escalations, and 15% to 20% better SLA compliance. Broader MSP adoption data adds ticket handling time cut by 45% and five to 12 points of margin, all from reclaimed capacity rather than headcount cuts.