Backup design
What gets backed up, how often, how long copies are kept, and where they live. Built around your actual tolerance for data loss rather than whatever the software defaulted to.
Home › Backup & Disaster Recovery
Backup & Disaster Recovery in Dallas, TX
Backups that have actually been restored from — because a backup nobody has tested is a belief, not a safeguard, and you find out which one you had on the worst day of the year.
Almost everyone has backups. Far fewer have recovery.
The two are not the same thing, and the difference only becomes visible at the exact moment it matters most.
When we assess a new environment, we usually find a backup system that reports success every night. Then we ask when someone last restored from it. The answer is often that nobody has, or that it was tried once during setup two years ago.
That gap is where businesses lose everything. Backup jobs succeed while silently skipping a critical database. Retention is set to seven days, so a problem discovered in week three has no clean copy to return to. The backup drive sits on the same network the ransomware just encrypted. Every one of these looks fine on a dashboard.
Our work is making recovery something you have observed rather than something you assume.
What we cover
Designed around what you can afford to lose and how long you can afford to be down.
Restore testing
Scheduled test restores with documented results. This is the part almost everyone skips and the only thing that turns a backup into a guarantee.
Ransomware-resistant copies
Immutable or offline copies that an attacker with full network access cannot alter or delete. Without this, your backups are just more files to encrypt.
Microsoft 365 backup
Email, OneDrive, SharePoint, and Teams protected independently of Microsoft's retention windows — the gap most businesses don't know they have.
Recovery planning
A written plan naming who does what, in what order, with what credentials. Discovering that the only person who knows the recovery process is unreachable is a common second disaster.
Business continuity
How you keep operating while systems are being restored. Some businesses can pause for a day; others need a path to working within hours. The answer changes the design.
Two questions decide everything
Before any product discussion, backup design comes down to two numbers that only you can set.
How much work can you afford to lose?
If backups run nightly and a server fails at 4pm, you lose the day. For some businesses that's an inconvenience. For one processing transactions continuously, it's unacceptable. This number sets how often backups run — and it's the main driver of cost.
How long can you afford to be down?
Restoring a file takes minutes. Rebuilding a failed server from a backup can take a day or more. If you need to be operational within hours, that requires a different design and a bigger budget. Deciding this deliberately beats discovering it during an outage.
Most vendors skip these questions and sell you a product. The product then determines your recovery capabilities by accident. We'd rather establish the targets first and build backward from them — including telling you when your current setup already meets them and doesn't need replacing.
How backups fail in practice
Not theoretical. These are the patterns we find repeatedly in real environments.
The job succeeds but the data is incomplete. A database in use gets skipped, or a new server was never added to the backup scope. The dashboard stays green for months.
Retention is too short. Corruption or a quiet deletion goes unnoticed for weeks. By the time anyone looks, every retained copy already contains the problem.
The backup shares the fate of the original. A backup drive on the same network, reachable with the same credentials, gets encrypted alongside everything else.
Nobody knows how to restore. The backup is fine. The recovery takes four days because the process was never documented and the person who set it up left last year.
Common questions
Isn't Microsoft 365 already backing up our data?
No. Microsoft replicates data for their own resilience and keeps deleted items for a limited window, but that isn't a backup. If something is deleted or encrypted and nobody notices until retention expires, it's gone. Microsoft's own terms recommend third-party backup.
How often should backups run?
It depends on how much work you can afford to lose. Tolerable to lose a day? Nightly is fine. Losing an hour would be serious? You need more frequent snapshots.
How do we know backups actually work?
By restoring from them on a schedule and documenting the result. A job reporting success only proves it ran, not that the data is recoverable.
Will backups protect us from ransomware?
Only if the backups can't be encrypted too. Modern ransomware targets backup systems and network shares first. Immutable or offline copies are what make recovery possible instead of paying.
How long would recovery take?
That's a design decision, not a fixed number. A single file takes minutes; rebuilding a failed server can take a day or more unless you've planned for faster recovery.
Do we need this if we're fully cloud-based?
Yes. Cloud platforms protect against their hardware failing — not against your staff deleting things, an attacker with valid credentials, or a departing employee wiping a shared drive.
Related services
Managed IT Services
Ongoing support and monitoring — including watching that backups actually complete.
Cybersecurity & Threat Protection
Reducing the chance you need to recover in the first place.
Cloud & Microsoft 365
Secure configuration of identity, email, and collaboration tools.
Find out if your backups would hold
Tell us what you're running today. We'll review what's protected, what isn't, and whether a restore would actually work — including when the answer is that you're already in good shape.
Gap-focused
What isn't covered, in plain terms.
Tested, not assumed
Restores we verify rather than take on faith.
Fast follow-up
We respond within 1 business day.
Call (214) 785-1766 or email
info@xentztechnologies.com