There is a difference between deleting files using a windows manager GUI and deleting files using CLI. When deleting files using windows manager you are simply moving files from one directory to trash directory. The only thing that gets updated is your filesystem inode metadata information (timestamps, block maps, extended attributes) for that specific file. You can get an overview of your filesystem inode information using tune2fs, sudo tune2fs -l /dev/sda1 |grep -i inode which looks something like this:

$ sudo tune2fs -l /dev/sda1 |grep -i inode 
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Inode count:              30007296
Free inodes:              29382378
Inodes per group:         8192
Inode blocks per group:   512
First inode:              11
Inode size:               256
Journal inode:            8
First orphan inode:       21628027
Journal backup:           inode blocks

So it’s fairly easy to just restore files from the GUI. When you remotely SSH to your machine you can see all the deleted files in ~/.local/share/Trash. However, when you use rm command to delete a file, you are not simply moving files to a different hidden folder, you are also letting the OS know through updated inode metadata its ok to use the disk space previously used by this file and write other files into that disk space. Depending on many factors (including which OS or filesystem or custom options in the filesystem you have added), the OS may decide to overwrite that space in next hour or two months from now.

When you wipe (secure delete) your files you are telling the filesystem to delete the file and write random data on the space where the file previously existed. In the case of secure delete – it is usually not possible to recover files. It’s a good idea to start the process of recovering deleted files as soon as you realize you have made a mistake – the longer you wait, the less likely it is that you will be able to recover the file.

There are couple of ways to recover data in Linux, two of the more popular options are TestDisk/PhotoRec and extundelete. PhotoRec, part of TestDisk, can help recover individual files, while TextDisk is used for more powerful recovery task, like filesystem partition, boot sector or Superblocks. TestDisk supports most major filesystems and builds for most popular OS is available. For an in-dept recovery walkthrough, check out their recovery guides. A typical PhotoRec recovery process looks like this:

extundelete specifically deals with ext3/4 filesystems, so you are limited by your option compare to TextDisk. Typically, file recovery is done by unmounting the filesystem you are recovering from with read-only access and save the recovered files to a different filesystem to avoid writing over deleted files. Restoring files from extundelete is as simple as extundelete /dev/sda1 --restore-all.

Data recovery is a messy business and often hit or miss, regardless of the OS or filesystem, so it’s always a good idea to immediately discontinue using a filesystem from where you are planning to recover data, to avoid overwriting it.