A routine NetBackup policy review caught something I hadn’t expected to find: three VMs running with a missing backup policy for nearly a month. Nothing had crashed, no alert had fired — the servers were just quietly running with a NetBackup backup policy that was never created in the first place.
The Setup
A client in our GA client group requested three new servers to support their operations. The process seemed straightforward: build the VMs, hand them over, move on to the next ticket.
What I didn’t realize was that in this environment, bringing a new VM online and adding it to a NetBackup policy are two separate steps — the second one has to be done manually. Nobody told me that, and it wasn’t in the handoff documentation either.
What Actually Went Wrong
I assumed the backup policy would be handled automatically, based on how some of my other environments are configured. It wasn’t. Whoever originally managed this environment knew to add new servers to a policy by hand — it was just part of their routine. That knowledge never made it into what I was handed.
The three new servers went live, ran normally, and backed up nothing.
From the operating system’s perspective, nothing was wrong. From a recovery perspective, those servers effectively didn’t exist.
How I Caught It
About a month later, I was doing a routine NetBackup policy review — not chasing an alert, just working through the client’s policies as part of regular maintenance. I checked the policy list against the VMs that had been provisioned recently, and the three new hostnames weren’t in it anywhere.
No policy. No backup job. No backup history.
Fortunately, nothing had to be restored during that window. But the gap had sat there, unnoticed, for close to a month.
The Timeline
- Day 0: Three new servers created for the client
- Day 0: NetBackup policy step missed
- ~30 days later: Routine policy review catches the missing VMs
- Same day: Policy created, full backup run
What I Changed After This
I stopped treating handoff documentation as the full picture. Now, when I take over an environment, I check what’s actually configured — not just what I was told is configured.
And for new servers specifically: backup policy gets created the same day the server goes live. I don’t wait for the next review cycle to find out something was missed.
The Lesson
The real problem wasn’t a failed backup job. There wasn’t a backup job to fail in the first place. The gap came from assuming a manual step was automatic, simply because nobody had said otherwise.
Related reading: This wasn’t the first time a backup issue in this environment caught me off guard — the full media disk incident that eventually took down the backup server entirely is the other half of that story. And if “the servers effectively didn’t exist” from a recovery standpoint sounds familiar, it’s the same blind spot our first DR test exposed — a policy nobody checks is just as risky as a restore nobody tests.
Frequently Asked Questions
Does NetBackup automatically create a backup policy for new VMs?
Not necessarily — it depends on how the environment is set up. In this case, new servers had to be added to a policy manually, and that step wasn’t part of the handoff documentation I received.
How do I check whether a server is covered by a NetBackup policy?
Compare your list of active VMs or servers against the policies currently configured in NetBackup, and confirm each one has recent backup history — not just that it’s listed somewhere. That comparison is exactly what caught the gap in this case.
Related reading: