Skip to main content

Speed Linx

Talk to an expert
Managed servers

Backups you can actually restore.

Backup and disaster recovery means keeping safe copies of your systems and having a tested plan to bring them back if something goes wrong. We back up whole servers and individual applications, store the copies off-site, write down exactly how to recover, and regularly test that the backups restore — because a backup nobody has restored is only a hope.
Our approach
  • Two layersWhole-server + application backups
  • Off-siteStored in a separate location
  • EncryptedIn transit and at rest
  • Restore-testedProven on a schedule
The difference

What is the difference between backup and disaster recovery?

A backup is a copy of your data. Disaster recovery is the plan, the people and the practice that turn that copy back into a working system. Plenty of businesses have backups; far fewer know how long a full restore takes, who does it, or whether the copy is even complete.

We cover both. Backups are scheduled for each system, stored away from the server they protect, and encrypted. Recovery is written down as a step-by-step runbook and practised, so on a bad day we follow a plan instead of improvising. If you want to check your current setup yourself, start with our guide on how to check your backups actually work.

Two layers

What do you back up?

Whole serversA full image of each server, so a lost machine can be rebuilt as it was.
Websites & hosting accountsFiles, databases and settings for each site, restorable one at a time.
Odoo & business appsThe database and file store together, so records and attachments match.Learn more →
DatabasesPostgreSQL and MariaDB backed up consistently, not copied mid-write.
ConfigurationServer settings and our build notes, so a rebuild is repeatable.
Off-site copiesStored in a separate location from the server they protect.
Restore your way

Backups you control.

Restore to a staging copyBring any backup back as a test copy — check it, then go live.
Your choice of storageKeep backups with us or in your own Amazon S3, Google Cloud, Azure or SFTP storage.
Restore anywhereBack to the same server, a new one, or another provider.
Planning

How do you decide how often to back up?

Two questions drive every backup plan: how much recent work could you afford to lose, and how long can the system be down? We agree the answers with you for each system, then design the schedule around them.
QuestionWhat it is calledWhat it decides
How much data can we afford to lose?Recovery point objective (RPO)How often backups run.
How long can we be down?Recovery time objective (RTO)How restores are prepared — from a quick restore to a standby server.
What must come back first?Recovery priorityThe order in the runbook: ERP, store, website, internal tools.
The schedule and targets we agree are written into your plan, not left as a verbal promise.
The plan

Ready before you need it.

01AssessWhat matters most and how fast it must return.
02ProtectBackups scheduled at the right frequency.
03DocumentA written, step-by-step recovery runbook.
04TestRestores practised so recovery is routine.
Common gaps

What usually goes wrong with backups?

Backups that fail when needed
  • Stored on the same server they protect
  • Database copied while it was changing
  • Nobody has ever tried a restore
  • Recovery steps only in one person’s head
Backups run by Speed Linx
  • Off-site, in a separate location
  • Applications backed up consistently
  • Restores tested on a schedule
  • A written runbook anyone on our team can follow
FAQ

Questions we get asked

How often are backups taken?
It depends on how much data you can afford to lose; we agree the schedule with you and write it into your plan.
Can we get a copy of our backups?
Yes. Your data is yours. You can download copies, or have backups sent straight to your own cloud storage.
Are the backups encrypted?
Yes — in transit and at rest, so a copy stored off-site can’t be read by anyone who gets hold of the storage.
How do you test that backups restore?
We restore real backups to a separate, private copy on a schedule and check that the system starts and the data is complete — not just that a backup file exists.
What happens if our whole server is lost?
We follow the recovery runbook: rebuild the server from its whole-server backup, or on new hardware or another provider if needed, then check every application before you go back to work.
Can you back up servers we host elsewhere?
Yes. We can back up Linux servers on any major cloud or in your own data centre, as part of a managed plan.
Do backups protect us against ransomware?
Off-site copies that the main server can’t change or delete are one of the best protections, because an attacker on the server can’t reach them. We combine that with hardening, so an attack is less likely to start.
Do we need disaster recovery if we are on a big cloud provider?
Yes. Cloud providers keep their hardware running, but they don’t protect you from deleted data, a bad update, a hacked account or a mistake in your own server. Your data, and getting it back, remain your responsibility — or ours on a managed plan.
Something else on your mind? Ask us directly →
Keep exploring

Related services

Server managementLinux and cPanel servers, watched daily.Explore →
Security audits & hardeningBenchmarked, plain-English report.Explore →
Private Odoo hostingYour own Odoo server, in your region.Explore →

Let’s talk about your project.

A free 30-minute call with the people who would do the work. No obligation, no sales script.