When Your Backup Client Lies About Its Name

The dashboard was green. That’s the part that still bugs me.

A customer calls because a workstation died and they need yesterday’s file back. Easy day. I pull up the backup server, find the machine, and go to restore. Except there’s nothing to restore. Last successful backup: never. Not “stale.” Not “failed.” Never.

But the agent was online. Heartbeat OK. Service running OK. Sitting there reporting in like a good little soldier. It just hadn’t backed up a damn thing the entire time it had been installed.

The investigation

First instinct: blame the agent. So I remoted in and read the client logs. The agent was happily completing runs. No errors. It thought it was doing its job.

So now I’ve got an agent that says “I backed up” and a server that says “this machine has never backed up.” Both swear they’re telling the truth. When two systems disagree about reality, the disagreement is almost always about identity.

I checked what name the agent was registered under on the server. Then I checked the machine’s actual OS hostname.

They didn’t match.

┌──────────────────────────┐        ┌──────────────────────────┐
│      THE WORKSTATION      │        │      BACKUP SERVER        │
│                           │        │                           │
│  hostname:  WS-FRONTDESK  │        │  client:  frontdesk-pc    │
│  agent runs OK            │        │  keyed by name ───┐       │
│  "backup complete" OK     │        │                   ▼       │
└───────────┬──────────────┘        │   ┌───────────────────┐   │
            │  reports as            │   │ frontdesk-pc      │   │
            │  WS-FRONTDESK ─────────┼──►│ (PHANTOM CLIENT)  │   │
            │                        │   │ last backup: none │   │
            ▼                        │   └───────────────────┘   │
   bytes go ►►► nowhere              │   WS-FRONTDESK: not found │
└──────────────────────────┘        └──────────────────────────┘

The agent identified itself by the machine’s real hostname. The server had the client filed under a different, hand-typed name from install day. So the agent checked in as WS-FRONTDESK, the server looked for a client called WS-FRONTDESK, found nobody, and the actual data went into the void. Meanwhile the frontdesk-pc entry someone created manually just sat there forever, eternally “waiting for first backup,” looking close enough to green that nobody clocked it.

The “aha”

Backup identity is the hostname. Not a label you pick. Not a friendly name. The hostname.

The server keys everything — auth, storage path, history — off the client name. If that name doesn’t equal what the OS reports as hostname, the agent and server are two ships passing in the night, both convinced they’re docked.

Agent saysWS-FRONTDESKServer expectsfrontdesk-pc≠no match= hostname= typed at installidentity mismatch -> silent backup failure
Two systems, two names, zero backups — and a green light the whole time.

The fix

Stop guessing. Ask the machine its own name, on the box itself:

# On the workstation — what does the OS actually call itself?
hostname

# Verify what the agent will report
[System.Net.Dns]::GetHostName()

That gave me WS-FRONTDESK. The server had frontdesk-pc. So I deleted the phantom client, re-registered the machine under its real hostname, and pushed the server’s preconfigured installer — the one that bakes the correct identity in instead of trusting a human to type it right:

# Remove the dead phantom entry, register the machine by its true hostname,
# then build the preconfigured client installer the server signs.
backup-admin client remove   --name "frontdesk-pc"
backup-admin client add      --name "WS-FRONTDESK"
backup-admin installer build --client "WS-FRONTDESK" --out ./install-WS-FRONTDESK.exe

Ran the signed installer on the box, kicked off a manual run, and watched the server. First full backup completed. Restore point exists. The phantom is gone.

(The other valid fix is to rename the machine to match the registered name — but renaming a production workstation is a bigger blast radius than fixing a backup entry. Match the agent to the host, not the host to a typo.)

Why it happened

Someone registered the client by hand and typed a “nicer” name than the ugly auto-generated hostname. The installer was generic, so identity was never enforced — it trusted the typed name. Two sources of truth, no reconciliation, and a monitoring view that treated “client exists and pings” as “client is protected.” Existence isn’t protection. A backup you can’t restore is just a process eating CPU.

Takeaways

  • Backup identity is the hostname. The registered client name must equal hostname on the machine — verify it, don’t assume it.
  • A green agent proves nothing. Online does not mean backing up. The only real green is a recent, restorable recovery point.
  • Use the server’s preconfigured installer. Hand-typed client names are how phantom clients are born. Bake identity in.
  • Alert on silence. Add a “no successful backup in N hours” check so an empty backup history screams instead of sitting there looking calm.
  • When two systems disagree about reality, suspect identity first. Auth, naming, and keys cause more “impossible” failures than disk or network ever will.