You hit backspace on the wrong directory
You accidentally delete a project folder. The terminal confirms the removal. Your months of work vanish from the file manager. You freeze for a second, then realize the clock is ticking. Every background service, every log rotation, every automatic update writes to the disk. The longer you wait, the higher the chance that new data overwrites the old. Stop what you are doing. Unmount the drive or switch to a live environment. Recovery is possible, but only if you act before the filesystem reclaims the space.
What's actually happening
Filesystems do not erase data when you delete a file. They remove the directory entry and mark the underlying blocks as available for future writes. Think of it like tearing the index out of a book. The pages are still there, but the table of contents no longer points to them. The operating system will reuse those pages the next time it needs to store something new. Once new data lands on those blocks, the old content is overwritten and unrecoverable.
This is why immediate action matters. Recovery tools scan the raw disk for recognizable file signatures and leftover metadata. They work best when the filesystem journal has not yet committed the deletion to the block allocation map. Fedora ships with three common filesystems. Each handles deletion differently. Each requires a different recovery approach. Pick the tool that matches your partition. Run it from a read-only state. Trust the process.
Recovering ext4 files
Fedora Workstation defaults to ext4 for the root filesystem. ext4 keeps a journal of metadata changes. When a file is deleted, the journal records the removal, and the block bitmap marks the space as free. extundelete reads the journal and the inode table to reconstruct the directory structure. It works best on an unmounted partition or a read-only mount. Running it on a live, read-write root partition will likely fail or corrupt the recovery process.
Identify the partition holding your data before you install anything.
lsblk -f
# WHY: Lists block devices and their filesystem types.
# WHY: Find the partition labeled ext4 that contains the lost files.
# WHY: Note the exact device path like /dev/nvme0n1p3 or /dev/sda2.
If the partition is your root drive, boot from a Fedora Live USB and open a terminal. If it is an external or secondary drive, unmount it immediately.
sudo umount /dev/nvme0n1p3
# WHY: Prevents the kernel from writing new data to the partition.
# WHY: A mounted read-write filesystem will allocate freed blocks to temp files.
# WHY: Unmounting guarantees the disk state stays frozen during the scan.
Install the recovery tool and run the scan.
sudo dnf install extundelete -y
# WHY: Pulls the ext4 recovery utility from the Fedora repositories.
# WHY: The package includes the journal parser and inode walker.
sudo extundelete /dev/nvme0n1p3 --restore-all
# WHY: Scans the filesystem journal and inode table.
# WHY: Reconstructs deleted files into a RECOVERED_FILES directory.
# WHY: The tool prints progress as it walks through the block groups.
The tool will print progress as it walks through the inode table. It separates recovered files by directory structure. Check the RECOVERED_FILES folder for your data. If you only need a specific path, replace --restore-all with --restore-file /path/to/file to save time. Run the scan from a different drive. Never run recovery tools on the same partition you are trying to save.
Recovering XFS files
XFS handles deletion differently. It does not keep a reversible journal for file metadata. When you delete a file on XFS, the directory entry is removed and the space is freed immediately. Dedicated XFS undelete tools exist in third-party repositories, but they are experimental and often fail on modern Fedora kernels. The reliable path for XFS is using testdisk or photorec, which scan raw disk sectors for file signatures instead of relying on filesystem metadata.
Install the standard recovery suite from the official repositories.
sudo dnf install testdisk -y
# WHY: Provides photorec, a signature-based recovery tool.
# WHY: The package works across all filesystems without journal dependencies.
sudo photorec /dev/nvme0n1p3
# WHY: Launches the interactive recovery wizard.
# WHY: It ignores the filesystem structure and searches for known file headers.
Navigate the TUI interface. Select the partition, choose the filesystem type, and pick a destination folder on a different drive. photorec will carve out files based on headers and footers. You will lose original filenames and directory structure, but the file contents will be intact. Rename and sort them manually afterward. Signature-based recovery is slower than journal parsing. Expect the scan to take longer on large drives. Leave the terminal alone while it runs.
Recovering Btrfs files
Btrfs changes the game entirely. It is a copy-on-write filesystem that supports native snapshots. If your Fedora installation uses Btrfs, you likely already have automatic snapshots from snapper. You do not need third-party recovery tools. You just need to mount an older snapshot and copy the files back.
List available subvolumes and snapshots to find the right point in time.
sudo btrfs subvolume list /
# WHY: Shows all active subvolumes and their paths.
# WHY: Snapshots appear as read-only subvolumes under /.snapshots.
# WHY: Note the ID number that predates your deletion.
If you are using the default Fedora Btrfs layout, snapshots live in /.snapshots. Navigate to the snapshot directory that predates the deletion.
ls -la /.snapshots/1/snapshot/home/youruser
# WHY: Verifies the file still exists in the historical snapshot.
# WHY: Replace 1 with the actual snapshot ID from the previous command.
# WHY: The snapshot is a frozen copy of the filesystem at that moment.
Copy the file or directory back to your live system.
cp -a /.snapshots/1/snapshot/home/youruser/project/ /home/youruser/
# WHY: Preserves permissions, ownership, and timestamps.
# WHY: The -a flag ensures extended attributes and SELinux contexts survive.
# WHY: Restores the data to your active home directory without breaking links.
Btrfs snapshots are atomic and consistent. You are not recovering fragments. You are reading a point-in-time copy of the filesystem. This is why Btrfs is the recommended choice for developers and power users who cannot afford data loss. Configure snapper to keep daily snapshots for seven days and weekly snapshots for four weeks. Automate the retention policy. Future-you will thank you.
Verify it worked
Do not assume the recovery succeeded because the files appear in the directory. Corrupted inodes or partial block overwrites can produce zero-byte files or truncated data. Open critical documents in their native applications. Run a checksum comparison if you have a backup or known good copy.
find RECOVERED_FILES -type f -empty
# WHY: Lists any recovered files that are zero bytes.
# WHY: Zero-byte results indicate overwritten or unrecoverable inodes.
# WHY: These files cannot be repaired and must be restored from backup.
md5sum /path/to/restored/file /path/to/known-good/file
# WHY: Confirms bit-for-bit integrity between the recovered and original data.
# WHY: Matching hashes mean the recovery is complete and safe to use.
If the files open correctly and the checksums match, the recovery is successful. Archive the restored data to a separate drive immediately. Do not leave it on the same partition you just scanned. SELinux contexts may also break after recovery. Restored files will inherit the default context of the destination directory. If you move a recovered configuration file back to /etc/, run restorecon -v /etc/filename to fix the security context. Services will refuse to read files with incorrect contexts. Check journalctl -xe if a service fails to start after restoration. The logs will show the exact denial. Fix the context before restarting the unit.
Common pitfalls and what the error looks like
The most common mistake is running recovery tools on a mounted, read-write partition. The kernel will happily allocate the freed blocks to temporary files, swap, or journal commits. extundelete will refuse to proceed and print Error: Could not open /dev/sdX1: Device or resource busy. The filesystem must be unmounted or mounted read-only before scanning.
Another pitfall is expecting 100% recovery. If the filesystem journal has already committed the deletion and the block allocator has reused the space, the data is gone. photorec will still carve out fragments, but you will see truncated files or missing metadata. You will also notice that filenames are replaced with generic names like f12345.doc or f67890.jpg. This is normal for signature-based recovery. The tool does not read the directory tree. It reads raw bytes.
Configuration drift is a silent killer. Files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. If you recover a system configuration file, compare it against the package default before applying it. Manual edits drift, package defaults stay consistent. Run dnf verify to check which system files have been altered. Trust the package manager. Manual file edits drift, snapshots stay.
When to use this vs alternatives
Use extundelete when you are on ext4 and the partition has not been mounted read-write since the deletion. Use photorec when you are on XFS or when filesystem metadata is too damaged for journal-based recovery. Use Btrfs snapshots when your system is configured with copy-on-write and automatic snapshotting. Use a proper backup strategy when you cannot afford to rely on post-deletion recovery tools. Stay on the upstream Workstation defaults if you only deviate from the filesystem layout occasionally.