Server Data Recovery: Stopping Business Downtime on Physical and Virtual Servers

When a server goes down, you do not just lose files. Billing stops, email stops flowing, the field team cannot see orders, and every passing minute turns into real money. At DSET we have stood beside businesses in exactly these moments since 2003 in Ankara. This page explains the physical and virtual server data recovery process honestly: what to do, and more importantly what to never do, in the first minutes of a failure.

Quick Answer

The first rule of a server failure is to shut the system down safely and stop touching it. Do not rebuild the RAID, do not initialize disks, do not run format or rebuild operations. A wrong move turns recoverable data into permanent loss. Preserve the disks as they are and request a read only diagnosis from a professional laboratory that works under a confidentiality agreement. The first diagnosis is free.

Why Server Recovery Demands Separate Expertise

Pulling data from a desktop drive and pulling it from a server are not the same job. On servers, data is usually spread across multiple disks in a RAID array, a virtualization layer runs on top, that layer holds virtual disk files, and inside those sit database engines. To reach a single Oracle table you must first decode the array geometry, then the file system, then the virtual disk, and finally the database structure. A guess at any of these layers risks corrupting the one beneath it.

Our approach is summed up in one sentence: copy first, solve second. We never write to the original disks. We take a sector by sector read only image of each disk and run all analysis and reconstruction on those image copies. So even if an attempt fails, the original data sits untouched, exactly as it was on day one.

Common Server Failure Scenarios

RAID Array and Disk Failure

This is the most common reason for a call. A single disk failure usually keeps the array alive, but when a second disk drops the array collapses, moving from degraded to offline. The most damaging mistake here is panicking and rebuilding the array from the controller. If the rebuild starts writing to the wrong disk, it overwrites parity and destroys recoverable data irreversibly.

The correct path is to remove all disks while labeling and preserving their order, then reconstruct the array parameters (block size, parity layout, disk order, left or right synchronous) backward from the image. For RAID 5, RAID 6, RAID 10 and nested setups we perform this reconstruction in software, bring up a virtual array, and read the file system from there. You can find the array specific process in detail on our RAID data recovery page.

Database Corruption: SQL Server, MySQL, Oracle

Databases can become inconsistent after a sudden power loss, a full disk, file system damage, or a failed update. We inspect the internal structure at page level: MDF and LDF files for SQL Server, InnoDB tablespaces (ibdata and ibd) for MySQL, and DBF datafiles for Oracle.

The critical warning here: running repair commands on a corrupt database without supervision often loses more rows. Some repair modes deliberately drop corrupt pages to open the database, meaning they sacrifice data to gain access. We work on a copy first, identify which tables are intact and which are fragmented, and recover the highest possible number of rows.

Exchange and Mailbox Recovery

For most businesses email is the most critical continuity component. When Microsoft Exchange database files (EDB) and transaction logs lose integrity, mailboxes become inaccessible. After an accidentally deleted mailbox, a corrupted database, or a failed migration, we decode the EDB structure and rebuild mailboxes, the folder hierarchy, and attachments. The goal is to give users their mailboxes back as they were.

Virtual Machine and Datastore Loss: VMware VMDK, Hyper-V VHDX

Virtualization has become the standard for server consolidation, but the loss of a single datastore can drop dozens of virtual machines at once. On the VMware side, VMFS datastore damage, accidentally deleted VMDK files, broken snapshot chains, and thin provisioned disk inconsistencies are common. On the Hyper V side, corrupted VHDX files, broken checkpoint chains, and severed differencing disk links stand out.

In these scenarios we work in two layers: first we extract the virtual disk files intact from the VMFS or NTFS storage layer, then we handle the file system inside that virtual disk, and if needed the database within it, in a separate recovery pass. We shared the finer points of virtualization recovery with examples in our server virtualization VMware Hyper-V recovery article.

Ransomware on a Server

The first reflex on a ransomware infected server matters. Isolate the machine from the network, but do not wipe the disks and do not try to reinstall. In some cases shadow copies that escaped encryption, large files that were only partially encrypted, or backup points the attack never reached still hold recoverable data. We do not recommend paying the ransom; instead we honestly assess what can be brought back from a read only image of the disk. When we cannot guarantee recovery, we say so clearly.

Failed Backup and Accidental Deletion

Ironically, a large share of calls come in while a backup supposedly exists. The backup is assumed to run, but nobody noticed the job had been failing for months, or it was written to the same faulty array. Another classic scenario is the right folder being removed by the wrong command, or a script targeting production data. Every new write to that volume after a deletion lowers the recovery chance, which is why the first step is to stop the system.

First Step by System and Scenario

The table below is built to give you direction in a moment of panic. The common thread is always the same: stop before you touch.

System Scenario What Not to Do Correct First Step
RAID 5 / 6 / 10 Second disk failure, array offline Starting a rebuild, breaking disk order Label and power off disks, bring them for imaging
SQL Server MDF corrupt, database suspect Forcing repair Copy with the LDF, do not intervene
MySQL InnoDB Tablespace inconsistent, service down Writing with innodb force recovery Preserve the data directory as is
Oracle DBF datafile damaged Attempting recovery onto the datafile Stop the server, image the files
Exchange EDB will not mount, mailboxes inaccessible Running eseutil hard repair Keep EDB and logs untouched
VMware VMFS datastore lost, VMDK deleted Reformatting the datastore Power off the host, stop writes to the LUN
Hyper-V VHDX corrupt, checkpoint chain broken Force merging checkpoints Preserve the VHDX and avhdx files
Any Ransomware Reinstalling, paying ransom Isolate from the network, keep the disk

Business Continuity and Recovery Time (RTO)

The real job of a data recovery firm is not only to extract data but to shorten the time your business takes to get back on its feet, the Recovery Time Objective. That is why we work according to your urgency level to speed up diagnosis. For failures that fully halt production we offer priority and weekend included work, aiming to make a critical database or mail system accessible as fast as possible.

To be honest, every failure has a different duration. A logical recovery from a single disk can take a few hours, while clean room work and staged imaging for a multi disk array with severe physical damage can take days. After diagnosis we give you a realistic timeframe and a recoverability estimate; we do not make inflated promises.

Confidentiality, KVKK and NDA

Your servers hold customer records, financial data, and personal data. That is why confidentiality is not a marketing line for us but the foundation of how we work. We sign a non disclosure agreement (NDA) with every corporate client who requests one. During recovery, access to your data is limited and audited, and when the work is done the working copies are securely destroyed at your request.

We run the entire process within the framework of the Turkish Personal Data Protection Law (KVKK, Law No. 6698). How long the data stays with us, who accessed it, and how it was returned are all on record. For your corporate audit needs we can share the process documentation.

A Professional and Transparent Process

Our way of working has four steps, and we inform you at each one:

  1. Free diagnosis: We examine the system and identify the failure type and layer. At this stage we do not touch the data, we only read it.
  2. Quote and approval: We present the recoverability status, the estimated time, and the cost clearly. No work starts before you approve.
  3. Read only imaging and reconstruction: We copy the disks sector by sector and do all the work on the copy. When needed we apply physical intervention in a dust controlled clean room.
  4. Verification and delivery: We run an integrity check on the recovered data and deliver it to you on a clean medium.

We describe this structure for every device and scenario type in full on our data recovery services page.

Local Advantage in Ankara

Because time is critical in server recovery, physical proximity is a real advantage. Instead of shipping disks and waiting for days, businesses in and around Ankara can bring their systems directly to our laboratory. Our location at Hacettepe Teknokent Beytepe makes face to face handover and fast diagnosis possible in emergencies. We also work with secure shipping from anywhere in Turkey.

Frequently Asked Questions (FAQ)

My server crashed, what should I do first?

Shut the system down safely and stop touching it. Do not rebuild the RAID, do not format, do not run repair commands. Preserve the disks as they are and call us. Every new write lowers the recovery chance.

What happens if I try to rebuild the RAID array myself?

This is the most common irreversible mistake we see. A rebuild with the wrong order or parameters can overwrite recoverable data along with the parity. On systems brought to us untouched, our success rate is markedly higher.

My virtual machines are gone, can VMDK and VHDX files be recovered?

In most cases yes. We extract deleted or corrupted VMware VMDK and Hyper V VHDX files from the storage layer, then recover the file system and database inside them separately. As long as you have not reformatted the datastore, the chance is high.

How is the confidentiality of my data protected?

We sign an NDA with every client who requests one, run the process in a KVKK compliant way, and securely destroy working copies when the work is done. Access to your data is limited and on record.

Will I pay if no data comes out?

No. The first diagnosis is free and we do not charge if no data is recovered. We only charge for the work you approve and that we recover successfully.

DSET Contact

DSET has served at Ankara Hacettepe Teknokent Beytepe since 2003. Our data recovery success rate is 99.4 percent. The first diagnosis is free, and if no data is recovered there is no fee. If your server has crashed, call us without losing time.

Phone: +90 536 662 38 09

Sources