Recovering Deleted Files on Linux/Ubuntu | NOC.org Support

Accidentally deleting a file on Linux can be stressful, but recovery is often possible if you act quickly and correctly. The key principle is simple: stop writing to the filesystem immediately. Every new write operation risks overwriting the blocks where your deleted data still resides. This guide covers multiple recovery methods, from the simplest to the most advanced.

First Step: Stop Writing to the Filesystem

When a file is deleted on Linux, the filesystem marks the blocks as free but does not immediately zero them out. The actual data remains on disk until those blocks are reused. To maximize your chances of recovery:

• Do not install recovery tools to the same partition. Use a different partition, a USB drive, or install via a live boot environment.
• If possible, unmount the partition or remount it read-only: mount -o remount,ro /dev/sdX
• Do not create, copy, or download files to the affected partition.
• Minimize system activity. Stop services that write logs or temp files to the partition.

Method 1: Recover Open File Handles via /proc (Fastest)

If the deleted file is still open by a running process, the data is fully intact in memory and can be recovered instantly. This is the easiest recovery method when it applies.

# Find processes that have the deleted file open:
lsof | grep '(deleted)'

# Example output:
# apache2  1234  www-data  10r  REG  8,1  524288  1048577  /var/www/site/config.php (deleted)
# The key information: PID=1234, file descriptor=10

# Recover the file:
cp /proc/1234/fd/10 /tmp/recovered-config.php

# Verify the recovery:
file /tmp/recovered-config.php
cat /tmp/recovered-config.php

This works because Linux keeps the file data accessible through /proc/[PID]/fd/[FD] as long as any process has the file open. Once the process closes the file handle, this method no longer works.

Common scenario: You deleted a log file while the application was still writing to it. The application still has the file descriptor open, so the data is fully recoverable.

Method 2: extundelete for ext3/ext4 Filesystems

extundelete is designed specifically for recovering files from ext3 and ext4 filesystems. It reads the filesystem journal to find deleted inodes and restore the associated data.

# Install extundelete (on a DIFFERENT partition or live USB):
sudo apt install extundelete

# Unmount the affected partition first:
sudo umount /dev/sda1

# Recover a specific file:
sudo extundelete /dev/sda1 --restore-file home/user/important-file.txt

# Recover an entire directory:
sudo extundelete /dev/sda1 --restore-directory home/user/project/

# Recover all deleted files:
sudo extundelete /dev/sda1 --restore-all

# Recovered files are placed in RECOVERED_FILES/ in the current directory

Limitations: extundelete works best on ext3 and ext4 filesystems. It cannot recover files from XFS, Btrfs, or ZFS. Recovery success depends on how recently the file was deleted and how much disk activity occurred since deletion.

Method 3: TestDisk (Multi-filesystem Support)

TestDisk is a powerful recovery tool that supports multiple filesystems including ext2/3/4, NTFS, FAT, and more. It can recover deleted files, repair partition tables, and undelete partitions.

# Install TestDisk:
sudo apt install testdisk

# Launch TestDisk:
sudo testdisk

# Follow the interactive menu:
# 1. Select "Create" a new log file
# 2. Select the disk (e.g., /dev/sda)
# 3. Select the partition table type (usually Intel/PC)
# 4. Select "Advanced"
# 5. Select the partition
# 6. Select "List" to browse files
# 7. Deleted files are shown in red
# 8. Navigate to the deleted file, press 'c' to copy/recover it
# 9. Choose a destination directory (on a different partition)

TestDisk also includes PhotoRec, which is a file carving tool that recovers files based on their signatures regardless of the filesystem. It is especially effective for recovering images, documents, and media files.

Method 4: debugfs for ext2/ext3/ext4

debugfs is a low-level ext filesystem debugger that can list and recover deleted inodes. It is more manual than extundelete but comes pre-installed on most Linux systems.

# Open the filesystem in read-only mode:
sudo debugfs -R 'ls -d /home/user/' /dev/sda1

# List recently deleted inodes:
sudo debugfs -R 'lsdel' /dev/sda1

# Find the inode number of your file from the output, then:
sudo debugfs -R 'dump  /tmp/recovered-file' /dev/sda1

# Example: recover inode 1048577
sudo debugfs -R 'dump <1048577> /tmp/recovered-file' /dev/sda1

Note: debugfs requires you to know the inode number, which you can find from the lsdel output by matching the file size, deletion time, and owner.

Method 5: foremost for File Carving

foremost performs file carving — it scans raw disk data for known file signatures (headers and footers) and extracts matching data regardless of the filesystem state. This works even when the filesystem metadata is damaged.

# Install foremost:
sudo apt install foremost

# Scan and recover files from a partition:
sudo foremost -i /dev/sda1 -o /recovery/output/

# Recover only specific file types:
sudo foremost -t jpg,png,pdf,doc -i /dev/sda1 -o /recovery/output/

# Recovery is organized by file type in the output directory:
ls /recovery/output/
# jpg/  png/  pdf/  doc/  audit.txt

Limitations: foremost recovers files without their original filenames or directory structure. You will need to manually identify recovered files. It is most useful for recovering media files, documents, and other files with well-known signatures.

Choosing the Right Method

Prevention Strategies

Recovery is never guaranteed. The best approach is preventing accidental deletion in the first place:

Use trash-cli Instead of rm

# Install trash-cli:
sudo apt install trash-cli

# Use trash-put instead of rm:
trash-put important-file.txt

# List trashed files:
trash-list

# Restore a file:
trash-restore

# Empty the trash:
trash-empty

You can alias rm to trash-put in your .bashrc, though some administrators prefer to keep rm as-is and build the habit of using trash-put explicitly.

Regular Backups

No recovery tool is a substitute for proper backups. Implement:

• Automated daily backups with tools like rsync, borgbackup, or restic.
• Off-site backup copies (different server, cloud storage).
• Regular backup testing — verify you can actually restore from your backups.

LVM Snapshots

If your server uses LVM (Logical Volume Manager), you can take filesystem snapshots before risky operations:

# Create a snapshot before making changes:
sudo lvcreate -L 5G -s -n data-snapshot /dev/vg0/data

# If something goes wrong, restore from the snapshot:
sudo lvconvert --merge /dev/vg0/data-snapshot
sudo reboot

Version Control

For configuration files and code, using Git provides built-in protection against accidental deletion. Any committed file can be recovered from the repository history.

For a comprehensive approach to protecting your Linux server, see the Linux security checklist, which includes backup strategies, access controls, and other preventive measures.