Quick Answer

If you have lost data on a Linux server, the single most important rule is this: never run fsck or any repair command on the original disk or volume, and stop writing to it. Unmount the volume immediately, take a read only bit for bit image with ddrescue, and perform every recovery attempt on that copy. A wrong repair can permanently destroy data that was still recoverable.

Why Data Loss on Linux Servers Is Different

Linux servers usually hold a company's most critical data: databases, virtual machine images, source code repositories, customer files and backup archives. Unlike a desktop Windows machine, here multiple filesystems, the logical volume manager and software RAID layers are stacked together. That is why Linux data recovery depends not on a single tool but on correct diagnosis and intervention in the right order.

The cause is often not a hardware failure but human error. A wrong command, a repair launched in panic or a mistyped dd target can corrupt healthy data beyond recovery within minutes. This article covers the most common scenarios on ext4, XFS, Btrfs and LVM, the right tools and the order to follow, with a B2B server focus.

The First and Most Important Step: A Read Only Image

Before running any recovery tool, the only correct move is to take the affected volume offline and create a read only image. If the server is in production, stop the relevant service, unmount the volume and, where possible, attach the disk read only.

GNU ddrescue is the standard tool for this. Unlike plain dd, it skips read errors, keeps a map file and can return to problem sectors later. Always write the image to a separate, healthy disk, never onto the source or the same physical drive. Keeping a log file lets you pause and resume from where you stopped.

Once the image is taken, set the original disk aside and run every attempt on the copy. This single rule accounts for most of the difference between a successful recovery and permanent data loss.

Recovery by Filesystem

ext4 and Why Journaling Makes Undelete Hard

ext4 has been the default server filesystem for years. The journaling that gives it reliability unfortunately makes deleted files hard to recover. When a file is deleted, ext4 zeroes the block pointers inside the inode. As a result, classic undelete methods work far less on ext4 than they did on ext3.

Still, hope is not lost. The extundelete tool scans journal records and tries to reconstruct inode information as it existed before deletion. Success depends on how much has been written to the volume since the delete, which is why stopping writes the moment you notice is vital. For a corrupted superblock, dumpe2fs can locate backup superblock positions, and the volume can be read using an alternate superblock at mount time, again only on the copy.

XFS and the Risks of xfs_repair

XFS is preferred on large filesystems and heavy workloads, and is the default on RHEL based servers. The most common XFS problem is a failed log replay after a sudden power loss. There is an important trap here: running xfs_repair with the L flag zeroes the log, and this can permanently lose data held in pending transactions.

The correct approach is to first try mounting the disk on a clean system and let the log replay normally. If that is not possible, run xfs_repair in its n mode, a read only simulation, to see what it would do. Aggressive log zeroing should be considered only as a last resort and only on the image copy.

Btrfs, Copy on Write and btrfs restore

Btrfs offers powerful features such as snapshots and checksums thanks to its copy on write design. That architecture is an advantage, but it complicates things when metadata is corrupted. A damaged Btrfs volume often will not mount at all.

The safest tool here is btrfs restore. It walks the tree in read only fashion without mounting the volume and copies files to another destination. Because it never writes, it cannot make the situation worse. The repair option of btrfs check must be used very carefully, since a wrong repair can damage the tree further. If the volume has snapshots, reading data from a healthy snapshot first is the fastest route.

LVM Logical Volume Recovery

LVM splits physical disks into flexible logical volumes. The most destructive mistake is removing the wrong logical volume with lvremove. The good news is that LVM automatically keeps backups of metadata changes under slash etc slash lvm slash backup and slash etc slash lvm slash archive.

A removed logical volume can usually be brought back as long as no new data has been written over it. First, vgcfgrestore restores an archived earlier metadata version, which recreates the definition of the deleted volume. The volume is then activated and mounted read only. On a volume overwritten by a wrong dd, this method will not help and a carrier level scan is required.

mdadm Software RAID Assembly Failures

In Linux software RAID, do not panic when an mdadm array fails to assemble at boot. The most dangerous mistake is recreating the array, because create writes a new superblock and can break the existing data layout. First inspect each member's superblock with mdadm examine to learn roles, sequence numbers and the event count. In most cases the array can be reassembled with assemble force. If disks dropped at different times, perform a careful assembly with the most recent and consistent members, never a create attempt.

Common Causes and the Right Approach

Filesystem / Layer Typical Failure Recommended Approach
ext4 rm -rf, deleted file, corrupted superblock Stop writes, ddrescue image, extundelete, backup superblock
XFS Power loss, failed log replay Try mount first, run xfs_repair n mode, avoid L
Btrfs Metadata corruption, will not mount Copy with btrfs restore, read from snapshot, avoid repair
LVM Wrong volume removed with lvremove Restore metadata with vgcfgrestore, mount read only
mdadm RAID Array will not assemble mdadm examine, assemble force, never recreate
All layers Wrong dd target Stop writes, professional carrier level scan

What You Must Never Do

In Linux data recovery, repair attempts destroy the most data. Running fsck with the y flag on the original volume accepts every fix without asking and often overwrites recoverable structures. Reformatting with mkfs resets filesystem metadata. A half finished RAID rebuild breaks parity. The Btrfs repair option, the XFS L flag and the mdadm create command are the most damaging when run in panic. They all share one trait, they write to the original, which is why each must be tried first on an image copy.

The Correct Recovery Order

In short, the correct order is this. First, stop writing and unmount the volume. Second, take a read only bit for bit image with ddrescue. Third, perform all analysis and attempts on that copy. Fourth, pick the tool that matches the filesystem: extundelete for ext4, btrfs restore for Btrfs, vgcfgrestore for LVM, and TestDisk and PhotoRec for general file recovery. Fifth, stop at every point where you are unsure. A wrong command can cause damage that even a professional lab cannot reverse.

When to Stop and Call a Lab

If the disk makes physical noise, SMART values are degrading, several RAID members dropped at once, or read errors climb rapidly during imaging, do not continue on your own. In these cases every new read attempt wears the disk further. For such cases, which need a clean room and professional imaging hardware, stopping early preserves the chance of recovering all the data.

Frequently Asked Questions (FAQ)

I ran rm -rf, can the data be recovered?

Usually yes, but only if you stop writing immediately. On ext4, journaling makes undelete hard, yet a journal scan with extundelete can succeed. The more the volume is written to, the lower the chance. Unmount the volume and image it right away.

I ran fsck with y in a panic, what happens now?

fsck y may have repaired many structures without asking and lost some data. Do not give up. Stop writing to the volume, take a read only image and run recovery tools on the copy. A professional lab can often still extract data even after a fsck.

I deleted the wrong LVM volume with lvremove, can it come back?

Most likely yes. LVM keeps metadata backups under slash etc slash lvm slash archive. With vgcfgrestore you can restore the version from before the deletion and bring back the volume definition. The only condition is that no new data has been written over the freed space.

My Btrfs volume will not mount, what should I do?

First try btrfs restore to copy files to another disk without mounting, an operation that writes nothing. If the volume has snapshots, reading from a healthy snapshot is the fastest path. Consider btrfs check repair only as a last resort and only on the image.

My software RAID will not assemble, should I recreate it?

Absolutely not, do not recreate it. That overwrites the superblocks and can destroy the data. First inspect the members with mdadm examine, then try mdadm assemble force. If unsure, leave the array as is and consult an expert.

About DSET

DSET is a data recovery and cybersecurity company operating since 2003 at Ankara Hacettepe Teknokent Beytepe. Our team specializes in Linux servers, RAID, virtualization and all filesystems, working with a 99.4 percent success rate in data recovery. The first diagnosis is free, and if no data is recovered there is no charge. Reach us now: +90 536 662 38 09.

Related guides: RAID 5 recovery process and cost | VMware and Hyper-V virtualization recovery | data recovery price list 2026

Sources