Server Data Recovery Singapore

When a production server fails — a RAID that won't come online, a corrupt VMware datastore, a SQL database that won't mount — every hour of downtime carries a real cost. The instinct to "just rebuild it" is exactly what turns a recoverable outage into permanent data loss.

CBL recovers enterprise servers across the full stack: hardware and software RAID, VMware ESXi and Hyper-V virtualisation, and SQL Server, Exchange and other databases. We work from disk images, reconstruct the array and virtual disks, and repair the databases — with priority and emergency turnaround, NDAs and proper invoicing for government, bank and enterprise clients.

One more belongs on that list: do not run the controller's own consistency check or "repair virtual disk" option. Those tools exist to restore service, not to preserve data.

What to do instead

• Power it down. A degraded array left running keeps writing, and every write narrows what can still be reconstructed.
• Label the bays before pulling anything. Masking tape and a marker is enough — disk order is part of the array geometry.
• Write down what already happened. Which disk dropped first, what the controller reported, what was attempted. It shortens the diagnosis considerably.

The causes we see most often

• Several drives failing at once in an ageing array. Disks bought together and worked identically for years wear out together. The array survives the first failure, then loses a second.
• A failed or interrupted RAID rebuild. A rebuild reads every sector of every surviving member — precisely when a marginal disk gives up.
• Controller and backplane failure. When a RAID card dies the array metadata effectively dies with it, and a replacement card often refuses to import the configuration — or offers to initialise it.
• Firmware or BIOS corruption. A controller or drive firmware update interrupted mid-flight, or a BIOS reset that clears the storage configuration and orphans the array.
• Power events and UPS failure. A brownout, a failed transfer to battery, or untested UPS batteries. Power lost mid-write leaves file systems and databases inconsistent.
• Accidental re-initialise of the array. Someone answers yes to the wrong prompt in the controller utility and the virtual disk is recreated empty.
• Ransomware. Live volumes encrypted, shadow copies deleted and, increasingly, the backup repository targeted first.
• A backup configured but never verified. The most common of all. The job reported success for months, but it pointed at the wrong volume, or nobody ever attempted a test restore.

The stacks we work on, and what recovery involves

• VMware ESXi and VMFS datastores. Rebuild the VMFS volume from images of the array, then carve out the VMDKs — snapshot chains included.
• Hyper-V VHD and VHDX. Extract the virtual disk from the host volume, then repair its header and block allocation table.
• Proxmox and ZFS pools. Import a pool that will not mount, reassemble it from the vdev labels, extract ZVOLs and qcow2 images.
• Microsoft Exchange (EDB). Recover the database and transaction logs, repair a dirty-shutdown store, or extract individual mailboxes.
• SQL Server (MDF/LDF). Recover the data and log files, repair page-level corruption, or extract tables and rows into a fresh database.
• Oracle. Datafiles, control files and redo logs recovered from the array, then reassembled against the tablespace layout.
• Veeam and Acronis backup chains. Backups fail too — we repair corrupt VBK/VIB and TIB/TIBX files and rebuild broken increment chains.
• LTO tape. Reading damaged, mis-tracked or unlabelled cartridges the original backup software can no longer index.

Virtual machine data recovery sits on top of the array rows above, not beside them — the array has to be right before the VM can be.

People arrive here typing very different things — server data recovery, server recovery Singapore, VMware data recovery, virtual machine data recovery — and they are usually describing one of three quite different situations.

Physical server, virtualised host, or one broken VM

A physical server is the box and the RAID array inside it. This is what most people mean by server data recovery: an array that will not come online, a failed controller, or disks that have dropped out of the set. The work happens at the array level and the operating system is almost incidental.

A virtualised host is the same hardware running ESXi, Hyper-V or Proxmox, with that array presented as a datastore holding a dozen or more virtual disks. When the array fails here, every VM on it goes at the same moment.

A single corrupt VM is a different animal. The host is healthy, the datastore mounts, and one virtual machine will not boot. Nothing needs dismantling — we usually only need a copy of that VM's files.

"VMware data recovery"

In practice this nearly always means one of two things. Either the VMFS datastore is lost or corrupt — ESXi sees the LUN, but the datastore is unmounted, inaccessible, or offering to be reformatted — or a VMDK has been deleted, often a snapshot consolidated badly or a VM removed from the wrong inventory. Both are usually recoverable, but they are not the same job.

Why virtual machine data recovery is a two-layer problem

Recovering a VM is two jobs stacked on each other. First the container: rebuild the array, reconstruct the VMFS or NTFS volume, carve out the VMDK or VHDX. Then that virtual disk is opened and treated as a disk in its own right — repairing the guest file system inside it, whether NTFS, ext4 or XFS. A perfectly recovered VMDK with a wrecked NTFS inside it is not a recovered server. Both layers have to come good, which is why we quote virtual machine work only after seeing both.

What confidentiality looks like in practice

• An NDA signed before any work begins. We sign yours on request, or provide ours — at intake, so the diagnosis itself is covered, not just the recovery.
• PDPA-aware handling of personal data. Access is restricted to the engineers on the case, and we do not browse recovered content beyond what verifying the file list requires.
• A documented chain of custody. Every disk is logged by serial number at intake, tracked through imaging and reconstruction, and signed out at handover.
• Controlled return media. Data goes back on media you keep, encrypted on request, collected from the lab or delivered by hand — not pushed through a public file-sharing service.
• Working copies wiped afterwards. Once you confirm the recovery is complete, we securely wipe our images and working copies to an agreed timeline and confirm the disposal in writing.

After hours, weekends, and servers that cannot leave the building

Production servers rarely fail at 10am on a Tuesday. We take emergency calls outside office hours and work weekends and public holidays on downtime-critical systems, with an engineer assigned to the case rather than the case queued behind routine work.

Where a server genuinely cannot leave the premises — data not permitted off-site, a sealed room, a regulated environment — we can attend on-site, image the disks in place and carry only the images back to the lab. That needs scheduling, so mention the constraint on the first call.

CBL Data Recovery (S) Pte Ltd (UEN 201101007Z) is the service provider — not a reseller, referral service or agent. We are a data recovery laboratory. You bring or ship your storage device to our own lab at 6 Harper Road, Leong Huat Building #05-02, beside Tai Seng MRT. Our own engineers image the media in our in-house cleanroom and return your recovered files.

We do not bypass encryption or account security. Where a device is encrypted, recovery requires the owner’s own password or key. Diagnosis is free, and all work is quoted in writing before it begins.