The laptop problem nobody put in the backup plan

Most small-business backup plans were designed for a building. The file server got backed up nightly, the workstations saved to a shared drive, and the office network quietly held everything together. Then the office emptied out.

Today a growing share of a company's important data lives on laptops that connect from kitchen tables, coworking spaces, hotel Wi-Fi and the occasional airport lounge. Those machines rarely, if ever, touch the office network. Many SMBs no longer run a domain at all, and even those that do can't rely on a laptop being reachable when the backup window opens.

The result is a quiet gap: the server is protected, the cloud apps are protected, and the device where your sales lead actually keeps her working files is protected by nothing but hope. This article covers what it takes to close that gap: how to back up endpoints without flooding home connections, how to make backups survive flaky links, how to get data back when a laptop is lost, and how to see what's happening across all of them when there's no central network to lean on.

Why endpoint backup is a different job

Server backup assumes a machine that is always on, always connected, and sitting next to fast storage. Laptop backup assumes the opposite on every count. Designing for that difference is most of the work.

Three principles fall out of this:

1. The backup must go to the data, not the other way round. The agent runs on the laptop and pushes to cloud storage directly. Anything that requires the laptop to reach an office server or VPN first will silently never run.

2. The agent must be polite. It shares a connection with video calls, a partner's work and the kids' streaming. If backups make Zoom stutter, users will find the off switch.

3. Status has to be pulled from the laptop, not pushed to it. With no domain and no inbound connectivity, the only reliable channel is the laptop calling out to a central service and reporting in.

Duplicati is built around exactly this model: a lightweight agent on each machine, backing up straight to the cloud storage you already use, and reporting to a central console over an outbound connection.

Bandwidth: don't become the reason the video call froze

Home upload speeds are the weak link. A 500 Mbit fibre line often comes with 50 Mbit upstream, and plenty of staff work on far less. A backup agent that grabs all of it will be noticed within minutes, and a user who notices will disable it.

Throttle upload speed as a rule, not an exception. Set a per-machine upload cap that leaves room for calls. A useful starting point is a quarter to a third of the slowest upstream you expect among your team; 2–5 Mbit/s is enough for daily incremental backups on most knowledge-worker laptops. Duplicati lets you cap upload and download bandwidth per backup job, so an aggressive limit for a travelling sales team and a looser one for the design team is a configuration choice, not a policy argument.

Schedule for when the connection is idle. Run backups at lunch, late afternoon or whenever the user tends to be away from calls, rather than at 9am when everyone joins the stand-up. Short, frequent runs (every few hours) beat a single large nightly job, because the laptop is far more likely to be awake and connected during the day.

Keep the first backup small. The initial full upload is the painful one. Point the first job at the folders that matter most (documents, desktop, project folders) rather than the whole user profile, and add more later. Deduplication and compression in Duplicati mean that the first upload is usually well under the raw size on disk, and every run after it sends only the changed blocks.

Exclude what you can get back elsewhere. OneDrive and Google Drive sync folders, Downloads, browser caches, package caches (node_modules, .nuget, .m2) and virtual machine images add gigabytes and seldom need protecting. A sensible exclusion list cuts upload volume more than any throttle does.

Backing up over connections that come and go

A laptop backup will be interrupted. The lid closes, the train enters a tunnel, the hotel Wi-Fi drops every twenty minutes. The question is not whether a run gets interrupted but what happens afterwards.

Upload in small pieces, not one big file. Duplicati splits data into fixed-size volumes (50 MB by default) and uploads them one at a time. When the connection drops halfway through a run, everything already uploaded is safe at the destination. The next run picks up where the last one left off instead of starting over. For very poor connections, a smaller volume size means less is lost on each disconnect.

Retry before failing. Transient errors from cloud storage providers and flaky networks are normal. Configure the agent to retry a failed upload several times with a short delay before it declares the run failed, so a thirty-second Wi-Fi hiccup doesn't produce a scary red alert. Duplicati exposes the retry count and delay as job settings.

Prefer frequency over size. A backup that runs every two hours and takes five minutes will complete far more often than a nightly run that needs an hour of uninterrupted connectivity. With block-level deduplication each run only sends what changed since the last one, so frequent runs cost little extra bandwidth.

Pick storage close to the user, not close to the office. Latency and packet loss matter more over consumer connections. Major object storage providers (Duplicati Cloud Storage, S3-compatible services, Backblaze B2, Azure, Google Cloud, Wasabi, and many more) are reachable from anywhere; there is no need to route traffic through a VPN to an office NAS that is itself a single point of failure.

Let the agent decide when to run. A backup scheduled for 02:00 never runs on a laptop that is asleep. Duplicati handles this automatically: a run that was missed because the machine was asleep or powered off starts the next time the machine is live, so the schedule describes how often you want backups, not a window that has to be hit exactly.

When the laptop is gone: recovery and damage control

Lost and stolen laptops are the most common endpoint disaster, well ahead of disk failure and ransomware. A good plan answers two questions at once: can we get the data back, and can anyone else get at it?

Encrypt before it leaves the machine. Backups should be encrypted on the laptop, with a key the storage provider never sees. Duplicati encrypts every volume with AES-256 before upload, so a compromised storage account or a leaked bucket exposes nothing readable. Combine this with full-disk encryption on the laptop itself (BitLocker, FileVault, LUKS), and a stolen device becomes an expensive paperweight rather than a breach.

Make restore independent of the lost machine. The point of a backup is that it can be restored to a different computer. Duplicati can restore directly from the backup files at the destination with nothing more than the storage credentials and the encryption passphrase. No local database, no configuration export, no access to the old laptop. Test this once with a spare machine so the procedure is known before it's needed.

Keep the passphrase somewhere other than the laptop. This sounds obvious and is a very common failure. Store encryption passphrases in the company password manager, or let the central console hold them for you, so that an IT admin or the user's replacement can run a restore. A backup with a passphrase that only lived in the lost laptop's memory is not a backup.

Onboard the replacement from the backup. The fastest recovery flow is: hand the user a new laptop, install the agent, restore their working folders from the last backup, and re-point the backup job at the same destination so history continues. With a central console the job configuration can be pushed to the new machine rather than rebuilt by hand.

Revoke what the old device could reach. Rotate the storage credentials the lost laptop held, and revoke its enrollment in your backup console and identity provider. Scoped, per-machine credentials make this a one-device change rather than a company-wide key rotation.

Knowing it works: central status without a domain

The hardest part of endpoint backup isn't running it, it's knowing it ran. With servers you check a dashboard. With twenty laptops that are never on the same network, nobody checks twenty dashboards, and a job that quietly stopped in March is discovered in October when someone needs a file.

The traditional answer was Active Directory: push the configuration by group policy, collect logs on a domain controller. That doesn't work for laptops that never join the domain, for companies that have no domain, or for the Mac and Linux machines that a modern team inevitably includes.

The approach that does work is the one every SaaS tool already uses: the laptop calls home. Each agent makes an outbound HTTPS connection to a central service, reports the result of every run, and picks up any configuration changes. No inbound ports, no VPN, no domain join, and it works from a coffee shop as well as from the office.

This is what the Duplicati Console provides for Duplicati agents:

• One view of every machine. See which laptops backed up, when, how much they sent, and which ones have gone quiet. A machine that hasn't reported in days is the signal that matters most, and it's visible at a glance.

• Alerts on failure, not just logs. Get notified when a backup fails or a machine stops reporting, so problems surface before anyone needs a restore.

• Central configuration. Define backup jobs, throttling, schedules and destinations once and push them to machines, rather than configuring each laptop by hand or trusting users to do it.

• Remote troubleshooting. When a user's backup breaks, connect to their Duplicati instance through the Console and fix it, without asking them to screen-share or ship the laptop in.

• Your storage or ours. Keep backing up to the storage you already pay for, or use Duplicati-provided storage. Either way data is encrypted on the device before it is uploaded, and the Console sees status and metadata, not file contents.

• Works across operating systems. Windows, macOS and Linux laptops report into the same view, with no dependency on a Windows domain.

For an MSP or a one-person IT function this turns endpoint backup from a recurring chore into something that only needs attention when the Console says so.

A rollout checklist

A workable endpoint backup checklist for a small team can be set up in an afternoon. The order below avoids the common traps.

1. Decide what to protect. Documents, desktop, and project folders for everyone; add role-specific folders (design assets, code checkouts without build artifacts, accounting exports) as needed. Write the exclusion list at the same time.

2. Choose a destination. One cloud storage account with a separate bucket or folder per machine, or Duplicati-provided storage if you'd rather not manage it. Give each machine its own credentials so a lost laptop can be cut off individually.

3. Set the defaults once. Upload throttle, schedule (frequent, during the day), retry count, volume size, and encryption. Put them in a Console template so every new machine inherits them.

4. Store the keys. Encryption passphrases go in the password manager before the first backup runs. No exceptions.

5. Enroll the machines. Install the agent, enroll it in the Console, and let the first backup run over a day or two with the throttle in place. Don't wait for it to finish over a weekend on the office LAN; the point is that it works from wherever the laptop is.

6. Test a restore to a different computer. Pick one machine, restore a folder to a spare laptop using only the storage credentials and passphrase. If this step is skipped, nothing above counts.

7. Turn on alerts and define who acts on them. A failed backup or a silent machine should reach a named person within a day. The Duplicati console has this configured by default.

8. Review quarterly. New hires enrolled, leavers revoked, exclusion list still sensible, storage spend in line with expectations.

The office network isn't coming back

For most small businesses the distributed laptop fleet is now the normal state, not a temporary arrangement. Backup has to be designed for it: agents that push data to the cloud from wherever they are, throttled so nobody notices them, resilient to connections that drop, encrypted so a lost device isn't a breach, and reporting to one place so you know, every day, that it worked.

Duplicati gives you the agent, and the Duplicati Console gives you the single place to watch it. If you're ready to close the laptop gap, start with the Console and enroll your first machine today; the open-source agent is free, and the first restore test is the one that lets you sleep.