Can You Recover Deleted Btrfs Files From an NVMe If fstrim Has Not Run Yet?
A waiting fstrim.timer is not proof that the deleted 50GB is still present. Btrfs can send discard requests without the periodic systemd trim job: on supported devices, asynchronous discard has been enabled by default since Linux kernel 6.2. The safest assumption is therefore that recoverability is unknown, not that the five-day timer represents a five-day recovery window.
In this Btrfs NVMe case on Reddit, folders were deleted from a 2TB external NVMe, the user avoided deliberate file writes and unplugged it after roughly a minute, then checked systemctl status fstrim.timer and saw the next scheduled run was still days away.
The Mount Policy Matters More Than The Timer
Btrfs trim documentation distinguishes synchronous discard, asynchronous discard, and manual fstrim. It also states that discard=async is automatically enabled by default on devices that support it since kernel 6.2. The timer only describes one manual trim path; it does not tell you whether discard requests were already issued when the files were deleted.
Preserve The Device:
Keep the NVMe unmounted. If the deleted data matters, make a sector-level image or clone before trying recovery tools, and perform experiments on the copy rather than repeatedly mounting the source.
What The Recovery Test Can Actually Tell You
- If the relevant logical blocks still return old data: A Btrfs-aware recovery workflow may still retrieve some files or metadata.
- If discarded ranges now return zeros or otherwise no longer expose the old contents: Recovery software cannot recreate those lost bytes.
- If the file system itself is damaged:
btrfs restorecan salvage readable file data without modifying the source filesystem, but it cannot reverse device-level discard of data that is no longer readable.