Backup, Disaster Recovery and Business Continuity
Backups you have actually tested — Rubrik architecture, restore drills, DR runbooks, and recovery-time validation, so recovery works the day you need it.
Almost every shop I walk into has backups. Jobs run, the dashboard is green, and everyone assumes recovery is handled. Then I ask one question: when did you last restore a production system from those backups and time how long it took? The room goes quiet. Backups that have never been restored are a guess, not a safeguard. You find out whether they work on the worst possible day, under pressure, with the business waiting.
The other half of the problem is the disaster-recovery plan itself. Usually it is a document someone wrote two years ago, full of hostnames that have since changed and steps nobody has ever walked through. Nobody knows the real recovery-time objective or recovery-point objective, so when an outage hits, the answer to how long until we are back is a shrug. I close that gap for clients across Fort Worth and the wider DFW area, and remotely anywhere, by turning untested assumptions into measured, repeatable recovery.
What done looks like
Done is a recovery you have actually performed and can perform again. It means a restore drill that ran against a real target, with the elapsed time written down next to the RTO you committed to, and the amount of data loss measured against your RPO. It means a DR runbook that someone other than the original author can follow, step by step, because it has been rehearsed instead of just filed. You should be able to point at a backup tier sized correctly on NetApp storage, a restore order that respects application dependencies, and a clear answer to how long recovery takes and how much data you stand to lose. No surprises left for the outage.
How I work it, and why me
I work change deliberately. I write the runbook before I touch anything, so the plan exists in your repository before the first job is reconfigured. I put validation gates between steps and I own the rollback, which means every change has a tested way back if it does not behave. When I run a restore drill, the procedure and its results stay in your repository, in your hands, so your team can repeat it without me. I am not interested in being a dependency. I am interested in leaving you with something that works when I am gone.
I have around four years of production experience doing exactly this kind of work on real systems with real downtime windows, not lab exercises. I hold CompTIA Security+ and RHCSA, which keep me honest on both the security posture of the backup tier and the Linux storage layer underneath it. I lead with your problem and the outcome you need, then prove it with a recovery you can watch run.
- Rubrik backup architecture designed and tuned around your real recovery targets, not defaults.
- Restore drills performed against production-equivalent systems, timed and documented.
- DR runbooks written, rehearsed, and kept in your repository for your team to own.
- RTO and RPO validation so the numbers you report are measured, not hoped for.
- NetApp storage for a backup tier that is sized and protected correctly.
If you have backups but have never proven you can recover, that is the gap worth closing first. I will show you where you actually stand, then leave you with a recovery you have tested with your own eyes.
Common questions
Will you actually test a restore, not just configure backups?
Yes. That is the whole point of how I work. A backup job that runs green every night tells you the data was copied, not that you can get it back. I run real restore drills against a defined target, time them, and document the result. You end up with proof that recovery works, not just a dashboard that says it should.
Do you work fully remote?
Yes. I run nearly all of this remotely over your existing access tools, and I am based in Fort Worth so I can come on site for clients in the Dallas-Fort Worth area when something genuinely needs hands on hardware. Most backup, DR, and restore-testing work does not require it.
Do you work with our existing Rubrik or other backup tool?
Yes. Rubrik is where I spend most of my time, but I will work inside whatever you already own rather than push a rebuild. The goal is a tested, documented recovery on your current stack. If your tooling is leaving real gaps I will tell you plainly and show you the impact.
Have a project like this?
Tell me the environment, the timeline, and your constraints. I reply the same business day with a fit assessment and either a quote or a referral.