There are ten working days left. The backups will keep running after the last day. The harder question is whether the people who stay can restore what the business runs on.
When your backup administrator is leaving, use the notice period to confirm who owns recovery decisions and which critical systems the remaining team can prove it can restore. A green backup dashboard won’t answer either question.
Editorial note: The distributor and events below are hypothetical. They describe a realistic scenario, not a Dataprise client or project.
Your backup expert knows which systems need special handling, which recovery steps have changed, and what to do when the usual process fails. That knowledge rarely lives anywhere else.
After they leave, jobs will still complete and reports may still show green. But during an outage, someone else will be making the restore decisions.
Recruiting a replacement takes weeks. The more urgent problem for an IT director is whether the current team can restore the systems the business depends on, within the time the business expects. One IT director has ten working days to find out.
Day 10 · Thursday, 4:12 p.m. The resignation email
The IT director gets the resignation email while reviewing next quarter’s infrastructure budget.
The engineer who has run the company’s backup systems for seven years is leaving for another job. Their last day is in two weeks.
The director thinks about recruiting first. The company has 430 employees, two distribution centers, and a four-person IT team. Finding someone who knows the older warehouse systems will take time.
Next, the director opens the backup dashboard. Everything looks normal. Jobs are green, offsite copies are being made, and last night’s report shows no urgent issues.
What the director wants to know is whether anyone else could restore the order-management system before the next shipping deadline. That answer should be on record somewhere, without having to ask the departing engineer. No one in the room knows where to look.
Day 8 The 30-minute handover meeting that took two hours
The handover starts with the basics: admin accounts and documentation. Another engineer will take over monitoring, and the service desk will handle first-line alerts. The director expects the departing engineer to walk through any exceptions.
Within thirty minutes, the discussion turns to the warehouse inventory database.
The nightly backup works. But the last recovery test only restored a supporting file server. The database depends on a unique service account (a non-human login the application uses to run), and its recovery environment uses a different network address.
The engineer knows these details because they helped build the system. Until now, the rest of the team never needed to.
The director asks whether the warehouse application was restored after last year’s firewall change. The engineer remembers a test, but no one can find a record showing staff completed a transaction afterward. There’s an unsigned test note somewhere. The dashboard can’t fill in the rest.
The meeting runs two hours. No one has been careless. The team has kept a complex operation running through hardware refreshes, new applications, and vendor changes. Many decisions just stayed informal, and a resignation exposes the gap between what the backup system records and what the business can actually recover.
The handover question that changes the conversation
“If our most experienced administrator couldn’t be reached during an outage, what could the rest of the team prove they can recover?”
Backup knowledge transfer: what the console can’t tell you
A new administrator can see the backup schedule and the restore points. That’s useful. It doesn’t answer the questions that come up in the middle of a recovery:
- Why is one workload restored from a different repository than the others?
- Who approves access if the main directory service is down?
- Which application has to work before the warehouse can ship orders?
These details decide the order of recovery. A server can boot while the business process stays down. A backup can exist while the team lacks the access to restore it.
The director sketches it on a whiteboard: one column for what the backup software shows, one for the decisions people made around it.
The right-hand column is much shorter than a full handover manual. Its job is to show leadership what the software can’t answer on its own.
The director has approved infrastructure spending for years. This is the first time anyone has asked whether the company can meet its recovery goals without one specific person.
Day 6 Operations asks when the first truck can leave
At the weekly operations meeting, the vice president of distribution asks who will own recovery after the engineer leaves.
The IT director says the remaining team can monitor backups. Operations pushes further: if order processing stops at 9 a.m., can the first truck leave by noon?
The technology plan sets a four-hour recovery time objective (RTO), the target time to restore a service after an outage. A target isn’t a guarantee. It doesn’t mean every application comes back in four hours, or that anyone has tested it.
The vice president cares about when warehouse staff can release orders. The infrastructure document tracks when the underlying systems come back. Those two milestones can be hours apart.
The director doesn’t promise noon. Instead, they name the uncertainty: the last test record doesn’t show that the full order process can be recovered from start to finish.
That admission changes the budget conversation. Leadership now has a specific decision in front of it instead of a general worry about hiring. The business can absorb a short disruption, but it can’t make sensible risk decisions without knowing which processes are tested and who can run recovery.
Larger organizations show the same gap. In Veeam’s Data Trust & Resilience Report 2026, 90% of respondents said they were confident they could recover within their RTOs, but only 69% said those RTOs were fully aligned with business continuity goals. The survey covered 906 IT, security, and risk leaders at director level or above in organizations with 1,000 or more employees, so read it as a signal, not a midmarket estimate.
For a 430-person distributor, the lesson is about evidence. A restored server and a restored business service are different milestones, and leadership needs to know which one a test actually proved.
How IT key person risk builds up
Nobody at the company decided to depend on one person. It happened through a series of practical choices.
Years ago, the engineer took ownership because the team was small. As the company grew, it added a new backup repository. A network change required a special recovery step. An application upgrade changed how restores had to be validated.
Each time, the engineer solved the problem and the team moved on. Other work always came first, so the fix never became a shared procedure or a repeatable test.
A resignation makes that history visible, but the exposure exists any time the specialist is out sick, on vacation, or unreachable on a Saturday. A new hire fills the seat. Repeatable recovery takes more: clear ownership, the right access, practiced steps, and time set aside from daily support work.
NIST’s contingency planning guidance (SP 800-34 Rev. 1) covers recovery roles, exercises, and plan maintenance. It’s written for federal information systems, so treat it as a planning reference, not a legal requirement for a private distributor.
Day 4 The team checks what it can actually prove
The director stops asking the departing engineer to recall every past decision. Four days are left, and the team still has its normal workload.
They start with order management, because a failed recovery there stops customer shipments. The operations lead defines success in business terms: an authorized employee can process and release an order.
The engineers find a recent backup, an older test report, a vendor contact, and a recovery runbook written before the firewall change. That’s useful evidence, but it doesn’t prove recovery. The director logs each open question, assigns an owner, and schedules a technical review to confirm whether the runbook still works.
That’s a better position than assuming everything is fine because the dashboard is green. The uncertainty is now specific enough for leadership to act on.
One more gap surfaces. A restore test from months ago says nothing about whether today’s backup copies are protected from ransomware, or whether they’re reachable if the identity system (the directory that controls logins, such as Active Directory or Microsoft Entra ID) is down. Those safeguards need attention no matter who runs backups.
Day 2 Covering the gap becomes an operating decision
Recruiting hasn’t produced a replacement yet, which is normal. The role could stay open for weeks, and backups still need to run, and be recoverable, every day.
The director gives leadership two realistic options:
- Cover with the current team. This needs enough staff and cross-training to handle an incident, and it means fewer hours for projects.
- Bring in outside specialists for defined backup and recovery work. This needs a clear contract, access set up in advance, and a tested split of who does what.
Neither option removes all risk. Most companies will want to keep ownership of their applications either way. The warehouse team knows the order process, and the IT director knows the internal dependencies and the decisions executives will face during an outage.
Outside help makes the most sense for specialized work the company can’t staff consistently, such as backup monitoring, offsite copies, recovery infrastructure, or coordinated recovery testing. What’s included depends on the provider and the agreement.
What managed backup services cover, and what stays with the business
Two service types cover different parts of the problem. Backup as a Service (BaaS) protects your data and keeps recoverable copies available offsite. Disaster Recovery as a Service (DRaaS) provides the infrastructure and operations to bring systems back online after a disruption.
At Dataprise, both services run on Veeam, including cloud backup through Veeam Cloud Connect, and the scope of each engagement is set in the contract.
Whichever provider you use, the agreement should state who handles each part of recovery, how often tests run and how they’re scored, and who approves a restore. The business still decides what gets restored first and how much downtime it can accept.
That leaves the director with one practical question for leadership: which recovery tasks can our team own, and where do we need outside help?
Day 1 The last day isn’t the finish line
On the engineer’s last day, the position is still open. But the company has something more useful than a packet of passwords and screenshots.
The order workflow is confirmed as the top recovery priority. Test evidence is separated from assumptions. Leadership can see the ownership gap and knows which work needs technical review.
Not every recovery test is done, and nobody is pretending otherwise. The progress is that hidden knowledge is now written down and each next step has an owner.
The engineer leaves on good terms. The next morning, there are orders to ship.
What should you do when your backup administrator is leaving?
Confirm who owns restore decisions, and check which recovery claims have recent test evidence behind them. Start with the business service where downtime would hurt most, and define success as a completed business transaction rather than a server that boots. If your team lacks the authority, capacity, or support to run recovery, schedule a technical review and decide which tasks need outside help.
This week, pick your most critical application and ask someone who’s staying to walk through its restore without help from the person who’s leaving. Write down every step where they get stuck. For a structured look at your technical controls, take the Backup Resilience Scorecard, and if you need ongoing backup management or tested recovery, talk to an expert about backup and disaster recovery as a service.
