How to Recover Accidentally Deleted Server Files
%203.png&w=256&q=75){kind=small}
Why Deleted Files Aren't Actually Gone
On a standard Linux ext4 filesystem, `rm` doesn't move a file to a "trash" anywhere on disk. It removes the directory entry that points to the file and marks the file's inode and data blocks as free space. The actual bytes usually still sit on disk, untouched, until something else writes new data over those exact same blocks.
That single fact is why speed matters more than anything else after an accidental delete. The longer a server keeps running — writing new log lines, caching files, rotating temp data — the more likely those freed blocks get reused for something new, and once they're overwritten, the old data is gone permanently, not just hidden. A file deleted five minutes ago on a quiet partition has a real chance of recovery. The same file on a busy partition that has since written gigabytes of new data may not.
Stop Writing to Disk Immediately
The first and most important step after an accidental delete is to stop write activity on that filesystem or partition, not to start troubleshooting. Every write is a chance to overwrite the exact blocks you're trying to get back, and that includes writes made by the recovery process itself.
Don't install a recovery tool onto the same disk you're trying to recover from — that installation writes new files, and those writes could land directly on the blocks holding your deleted data. If you can, pause cron jobs and stop logging that would otherwise keep churning on the same partition while you work.
If a second disk or a mounted network path is available, that's where any recovery tool or output copy should go. The goal in this first minute isn't recovery yet — it's simply preserving the state of the disk so recovery is still possible a few minutes later.
Recovering a File Still Open by a Process
If a running process still had the file open at the moment it was deleted — common when a service was actively writing a log or a data file — the data is still fully accessible through `/proc/<pid>/fd/<fd>` until that process closes the file or gets restarted. The kernel doesn't actually free the underlying data as long as an open file descriptor still references it, even though the directory entry is already gone.
This only works while that process is still running with that file descriptor open. Restarting the service, or the process exiting on its own, closes the descriptor and the data becomes unreachable through this route — so it's worth checking `lsof | grep deleted` right away, before restarting anything that might have been mid-write to the file you lost.
Recovering With extundelete and testdisk
For files with no open handle, ext4 recovery tools like `extundelete` or `testdisk` can sometimes reconstruct deleted files by scanning the raw filesystem for orphaned inodes — inode structures the directory tree no longer points to, but whose data blocks haven't been reclaimed yet. Both tools work best when run against a partition that has seen minimal write activity since the deletion, ideally mounted read-only or accessed as an image copied to a different disk.
This is a best-effort forensic process, not a reliable recovery method. Success depends entirely on how much has been written to disk since the deletion, and there's no way to know in advance whether a scan will turn up a clean, complete file or a corrupted fragment.
A scan can also take a long time on a large volume, during which the server is often still running and still writing — which is exactly the tension this whole process creates. That uncertainty is the reason forensic undelete tools are treated as a last resort rather than a first response.
Why Backups Are the Reliable Fix
The reliable recovery method is always a backup taken before the deletion happened. Restoring a single file or directory from a recent snapshot is deterministic and fast — you know exactly what you're getting back, and it takes minutes — versus hours of uncertain forensic work with no guaranteed outcome.
A backup strategy that actually covers accidental deletion needs two things together: frequency, so "recent" means what it sounds like, and retention, so there's somewhere to restore from a few days back if the deletion wasn't noticed the moment it happened. Daily automated backups with at least a week of retention cover most accidental-deletion scenarios, including the common case where a missing file isn't noticed until several days later.
How CloudStick Handles Backup Recovery
CloudStick's automated server and website backups run on a configurable schedule with a retention period you control, so the frequency-and-retention combination that actually protects against accidental deletion is set up once and runs without anyone remembering to trigger it. Archived Backups keeps a browsable history of those snapshots, so you're not stuck restoring the most recent one when the file was actually deleted several backups ago.
Restoring can also be scoped to just a specific website's files rather than the whole server, directly from the dashboard — no forensic tooling, no guessing whether a scan will find anything usable. For a CloudStick user, an accidentally deleted file is a restore-from-yesterday's-backup problem with a known outcome, not a race against disk-block reuse using a tool that might come back empty. That's the practical takeaway here: the moment matters for `lsof` and `/proc` recovery, but the real fix is making sure a recent backup already exists before you ever need one.
