A backup you have never restored is a hope, not a plan.
Backup, replication and disaster recovery designed around how long you can actually be down and how much data you can afford to lose, then tested, on a schedule, with a written result.
Engineering offices in Egypt, delivering on site across Egypt and Saudi Arabia, and supporting clients remotely across the Gulf, Africa, Europe and the United States.
Most people call. It is faster, and you speak to an engineer, not a form.
What a free restore test looks at
How backups fail, in our experience
Almost never because nobody bought a backup product. They fail quietly, and the failure is usually discovered on the worst possible day.
It was never restored
The job reports success every night for two years. The first real restore attempt is during the outage, in front of the board, and it is the first time anyone has tried.
Every copy is on the same site
Production and backup in the same rack, on the same power, behind the same door. Fire, flood, theft and ransomware all take both at once.
One admin account can delete everything
The backup console uses the same domain credentials as the servers it protects. Ransomware goes for the backups first, and it usually finds them.
Nobody agreed how long down is acceptable
Without an agreed RTO and RPO, the design is a guess. Then a four-hour expectation meets a two-day restore, and the argument happens after the damage.
What we design, build and then prove
The order matters. We start from what the business can tolerate, not from a product, and we finish with evidence rather than a green tick.
RTO and RPO, agreed in writing
How long you can be down, and how much data you can lose. Every other decision follows from these two numbers.
- Per-system targets, the ERP is not the file server
- The cost of downtime, so the spend is proportionate
- Which systems must come back first, and in what order
- Retention: how far back you need to go, and why
- Legal and contractual retention requirements
- Sign-off from the business, not just from IT
We would rather argue about these numbers now than during an outage.
Backup design and implementation
Three copies, two media, one off site, and an immutable copy that ransomware cannot reach.
- Veeam or the platform-native tool, sized to your data
- Immutable or air-gapped copy, separated from domain credentials
- Virtual machines, physical servers, databases and file shares
- Microsoft 365 mailboxes, OneDrive, SharePoint and Teams
- Off-site replication to a second site or to cloud storage
- Encryption in flight and at rest, with the keys held properly
Microsoft 365 is not backed up by Microsoft in the way most people assume. We cover it explicitly.
Disaster recovery, not just backup
Backup is copies. Disaster recovery is a plan for running the business while production is gone.
- A DR runbook with named roles and a call order
- Replication for the systems that cannot wait for a restore
- A documented failover and, just as important, failback
- Dependencies mapped: DNS, licensing, identity, network
- Communication plan for staff, clients and suppliers
- Where people work from if the office itself is unavailable
The runbook is written so somebody who is not you can follow it at 3am.
Testing, on a schedule, with a written result
This is the part that gets skipped, and it is the only part that proves anything.
- Scheduled restore tests: file, mailbox, database, full server
- Time each restore and compare it against the agreed RTO
- A written test record you can hand to an auditor or a client
- Failures raised as actions with an owner and a date
- Retest after any significant infrastructure change
- An annual full DR exercise where that is justified
If it has not been restored, we do not call it a backup.
Monitoring and the day it actually happens
Alerting that a human reads, and an engineer who answers the phone when it matters.
- Daily job monitoring with failures chased, not just logged
- Capacity tracked so the repository does not quietly fill
- Regular reporting on success rate, restore tests and gaps
- Incident response when data is lost or encrypted
- Support through the restore itself, on site if needed
- Post-incident review, and the design changed if it was wrong
Day-to-day operation can sit inside Managed IT if you would rather not run it.
Environments where losing data was not an option
Real Stark work. Client identifiers are withheld under confidentiality. Sector and scope only.
National data centre
Designed and built with resilience, replication and controlled access as part of the programme rather than something added afterwards.
National e-payment platform
A live payment service monitored around the clock, where an unrecoverable outage is a national story rather than an internal one.
Replication between sites
Production in one location with a replicated copy in another, so a site-level failure is an inconvenience rather than an extinction event.
Mail, OneDrive, SharePoint and Teams
Third-party backup added for cloud data that clients assumed was already protected. It usually is not, in the way they expect.
References can be provided directly, on request, with the client’s agreement.
Three things we will tell you not to do
The questions we get asked most
Is Microsoft 365 not already backed up?
Microsoft protects its own infrastructure and offers a short retention window; it does not offer the long-term, point-in-time recovery most businesses assume they have. If a mailbox is deleted and the retention window passes, it is gone. We add third-party backup for 365 as standard.
How often should backups be tested?
It depends on how much change the environment sees, but a file-level restore monthly and a full server restore quarterly is a reasonable starting point for most of our clients. What matters more than the interval is that the result is written down and the failures are chased.
What is the difference between backup and disaster recovery?
Backup is copies of data. Disaster recovery is the plan for continuing to operate while production is unavailable, which systems come back first, who does what, and where people work from. You can have excellent backups and still have no disaster recovery.
Can you protect us against ransomware specifically?
Partly, and we will be clear about the limits. An immutable or air-gapped copy that is separated from your domain credentials means the backups survive even if production is encrypted. Stopping the encryption happening in the first place is a different job. See Cyber Security.
Do you take over an existing backup system or replace it?
Whichever is honest. If what you have is sound and simply untested or unmonitored, we would rather fix and prove it than sell you a replacement. If it cannot meet the targets you have agreed, we will say so and show you why.
When did you last restore something?
If the answer is ‘I am not sure’, that is the answer. Ten minutes on the phone and we will tell you what to test first.
Sunday to Thursday, 9am to 6pm · Egypt, and remote worldwide
Our other IT services
Every service below is delivered by the same team, under the same agreement.