When a server goes down, it’s rarely just one thing that’s broken — it’s the RAID array, and the file system on it, and the virtual machines it was running, and the databases inside those. Recovering a server means working back through those layers, carefully and in the right order, without letting anything ‘repair’ itself into a worse state. We recover physical and virtual servers of every make for businesses across the UK, with priority handling when you’re stopped. Disks in by courier.
A server recovery lives or dies on the disks underneath. Power it down and image them before any rebuild or repair.
A single server usually stacks several systems on top of each other, and a serious failure can involve all of them. At the bottom is a RAID array spreading data across disks. On that sits a file system — NTFS, VMFS, ext4, ZFS. On that run virtual machines, each a large container file with its own file system inside. And within those live the things the business actually depends on: SQL and Exchange databases, mailboxes, file shares.
Recovering a downed server means peeling those layers back in order: reconstruct the array, mount the file system, extract and repair the virtual machines, then recover the databases within them. Each layer has to be sound before the next makes sense, and a shortcut at any level — letting the array rebuild, forcing a datastore to mount, running a database repair — can corrupt everything above it. It’s methodical, layered work, and it’s what server recovery demands.
RAID array failure. The commonest root cause — multiple disk failures in a degraded array, or a dead RAID controller that takes the array configuration with it. Everything above depends on rebuilding this correctly.
Hypervisor and virtual-machine problems. A corrupt VMware VMFS datastore, a VM that won’t power on, a damaged VMDK or Hyper-V VHDX, or snapshots that grew out of control and broke the chain. The data is usually recoverable from the underlying storage even when the hypervisor can’t see it.
Database corruption. A SQL Server or Exchange database that won’t mount after a crash, a power loss, or a storage failure — often repairable at the page level to get the business back online.
Physical failure of the server. A dead power supply or mainboard with the disks intact — a matter of reading the disks outside the machine.
Deleted or reconfigured. A VM, datastore or volume deleted or reformatted by mistake, or a reconfiguration that went wrong — recoverable if the disks haven’t been overwritten since.
The instinct under pressure is to make the server work again as fast as possible — and that’s exactly what loses data. Before anything else:
Don’t let the RAID controller rebuild onto a replacement disk if the array is degraded or inconsistent — a rebuild can write bad parity over good data permanently. Don’t force a VMFS datastore to mount or resignature it, and don’t run repair on a corrupt datastore. Don’t run database repair with data loss (such as a forced repair) as a first move — it can discard recoverable records. Don’t reinitialise the array or recreate volumes, and don’t reorder the disks — label each with its slot. Power the server down, note the RAID and storage configuration, and get the disks imaged before any rebuild or repair. On a server, the safe move is almost always to stop.
We begin by imaging every disk read-only, giving any mechanically failing disk clean-bench attention first, so the foundation is solid. Nothing is written to the originals. From the images we reconstruct the RAID array offline and mount the file system, then extract the virtual machines — repairing damaged VMDK or VHDX containers and broken snapshot chains as needed — and open the file systems inside them. Finally we recover the databases, repairing SQL, Exchange or other stores at the page level where required to bring them back to a mountable, consistent state. Every layer is verified before we build on it, and the whole process runs on copies, so it can be worked through as carefully as the job needs without risking your data.
We recover from every major server brand — Dell PowerEdge, HP/HPE ProLiant, Lenovo ThinkSystem, Supermicro and custom builds — running Windows Server or Linux. On the virtualisation side, VMware ESXi / vSphere (VMFS), Microsoft Hyper-V and Proxmox; and the applications on top including SQL Server, Exchange, MySQL and PostgreSQL. Any RAID level and controller, SAS, SATA and NVMe disks, plus SAN and NAS storage and legacy tape. If it’s server storage, we can reconstruct it.
Server recovery starts with a free diagnostic: we image and assess the disks, establish which layers can be reconstructed, and give you a fixed written quote before any chargeable work. Because a downed server usually means a business is stopped, a priority and emergency service is available, with round-the-clock progress on critical jobs, and NDAs and confidential handling as standard — we deal with sensitive business and client data every week. Pricing is per case, reflecting the layers involved. Disks come in by insured courier, and we recover servers for businesses right across the UK and Ireland.
In most cases, yes. Even a serious server failure usually leaves the data intact on the disks — the problem is that the RAID, the file system, the virtual machines or the databases above it can’t be read in their current state. We reconstruct those layers from images of the disks, in order, and recover the data. The key is to stop and have the disks imaged before anything is rebuilt or repaired.
Not if there’s any doubt about the array. If it’s degraded or inconsistent, a rebuild can overwrite recoverable data with bad parity, and everything running on top — VMs, databases — goes with it. When the data matters, image every disk first and reconstruct offline. Power the server down and ask before rebuilding.
Yes. We recover VMs from VMware ESXi, Hyper-V and other hypervisors — reconstructing the underlying storage, repairing corrupt VMFS datastores, and extracting and repairing the VMDK or VHDX files, including broken snapshot chains. We can then recover the data inside each VM, right down to the databases it was running.
Usually, yes. A database that won’t mount after a crash or storage failure can often be repaired at the page level to bring it back to a consistent, mountable state — recovering tables, records or mailboxes. Avoid running a forced repair-with-data-loss yourself as a first step, as it can discard recoverable data; let it be assessed first.
Yes. We know a downed server can halt a business, so we offer a priority and emergency service with round-the-clock progress on critical jobs, ahead of the standard queue. Get in touch as soon as it happens — the faster the disks are imaged, the faster we can work, and the less chance of further damage.
No. Our lab is in Belfast, but server recovery is done by courier, so we work with businesses right across the UK and Ireland. Send the disks or the server in by insured courier, with NDAs and confidential handling as standard — the service and pricing are the same wherever you are.
Power it down, note the configuration, and get in touch. We’ll image the disks, work out which layers can be reconstructed, and give you an honest, fixed quote before any chargeable work — priority and emergency service available, NDA as standard.