Maybe this is just my limited knowledge, but I am decently certain that if you remove files (without trash) then recovering them is very difficult. From my layman’s understanding:
The hard drive is a long set of 1’s and 0’s. If you hard drive is 500 GB for example, then you have 500,000,000,000 little on/off switches storable in a row. They are numbered from 0 to 499,999,999,999 if that makes sense (in reality, maybe they are grouped and numbered in a slightly better way, but this is an approximate way to imagine it).
Somewhere at the beginning, there is a section where the system always looks for notes about what portions of the long tape of numbers are used for what purposes. Maybe it says that at index 259,251,529 we have information on /home/user/Desktop. If we skip to that position in the tape, 259,251,529 has some 1s and 0s that encode a number – the number of things in that folder – as well as another list of 1s and 0s that encode their names. Then maybe it has a note about “stop reading” to tell us that a little later on at 259,254,215 we reached the end of the information about what’s in there.
As we create and delete files, it adds and removes notes in the designated area for that about where to find those files. So if /home/user/Desktop contains five files, maybe there is a list of five notes pointing to other sections of the computer. Maybe the first one points a little out past where Desktop was created, at 325,910,159 by chance. Perhaps it tells us that at that location, there are 10,000 bytes in a row which together are the data that your system tells you is inside of a 10kb file on Desktop.
When you rip out the jumps in this system that told us where to start 259,251,529 to find information about /home/user/Desktop, and likewise rip out the information that thing pointed to which would have told us that 325,910,159 and the 10,000 bytes after it are some thing.png sitting inside Desktop that is 10kb of data, the loss of these links means that the system will start to reuse these areas of space possibility in different amounts and in different places. As an example, the green portion in my picture above might be re-used and write over some of your stuff, but not all of it, on the drive.
Because of this, if you are serious about wanting to save the information encoded in files that no longer exist, you should immediately cease using the file system where the lost files existed. Don’t mount this as some external drive, and don’t boot from it if it’s your main drive. Maybe you already know this, as it goes without saying for users who are technically informed, but I think this is really important as a first step if you did not know.
The second step, once the drive is safely offline and in no further danger of re-purposing the empty portions of your disk (and therefore inadvertently erasing what you wish to save), you need a special software to skim across the contents of the disk regardless of the notes about where things are and try to find the bits and the pieces of things that remain partially intact, so you can bring them back.
I haven’t tried to do anything like that in years. In general, it is preferable to never use the system in a manner that requires the user to undertake this kind of recovery and instead use the normal file system and always make a backup. So I do not know what software to recommend you for this recovery purpose. But once you find software to solve the problem, it may take a long time to run depending on the size of your hard drive because it will be “looking for file-shaped information in the empty spaces” which by definition doesn’t know where to look.
Edit: It sounds like extundelete is the software solution that I mentioned above that maybe you already knew about.
In such a case, are you having a problem that /dev/sda2 is LUKS encrypted, and you need to use cryptsetup to load the unencrypted view of the partition to a device mapper name, to then run extundelete on the unencrypted partition contents by using the “unencrypted device name” created in the mapper folder or whatever?
Edit 2: Again, due to my lack of knowledge about this, don’t try the “cryptsetup + extundelete on the mapper” solution I suggested until you backed up a 1:1 mirror image of the LUKS encrypted drive somewhere like @FranklyFlawless suggested, if you are actually extremely serious about recovering the lost data. This way, if we find out my advice is bad and ignorant and the “cryptsetup” mount of the LUKS encrypted drive actually uses more of the reclaimed space and erases your stuff, then because you have a 1:1 mirror image of before you touched it you will be able to go back to that backup image and operate on the clean original while using better advice from somewhere else.
