Only admin level can change the default 1 day setting.
So if you can't communicate to an admin user to extend that then have to assume it will be moved to trashdir where it supposedly remains for 4 days .... unless admin has reduced that time. I have no way of knowing how your server is set up nor maintained, etc.
"Can you please explain? If the recycle bin is not relevant (I will only have access to admin tomorrow), what are my options?"
It is relevant ... just that due to oversight of how it's programed no recycle link shows for deleted courses in course admin ... cause you might not be able to see courses + no link shows ... even for admins ... I just tested it on a sandbox server.
You will probably need to contact admin of server ... one who has command line access ... and share with them this followup info:
mysql> select contenthash,filename,filesize,component from mdl_files where filename like '%.mbz';
finds a deleted course - component is tool_recyclebin.
bcfad21bf2be11a297d9880138bed36802bdc767 | backup.mbz | 45885851 | tool_recyclebin
File in moodledata
bcfad21bf2be11a297d9880138bed36802bdc767
Could do commands below with any tool you have to browse files.
[root@sos filedir]# find ./ -name bcfad21bf2be11a297d9880138bed36802bdc767
./bc/fa/bcfad21bf2be11a297d9880138bed36802bdc767
Could do command to copy via any tool you have to browse files.
[root@sos filedir]# cp ./bc/fa/bcfad21bf2be11a297d9880138bed36802bdc767 /var/www/unirepo/recyclebin-backup.mbz
note: above unirepo is a file system repo for multiple instances of moodle on server where I was testing.
The process above I did use and was able to restore a deleted course ... however I did not do exactly the same process as you did. That to say, your mileage might vary!
Example of trashdir from CLI
cd /path/to/moodledata/filedir/trashdir/
ls -lR *
On your site that might list a lot of files. On my sandbox site found 2 that look to be a moodlebackup by their size:
20/2c:
total 44812
-rw-rw-rw-. 1 root apache 45886036 Jan 4 07:18 202c07385b7a475363eb56ad63912bba3b8d8527
and
f3/92:
total 44812
-rw-rw-rw-. 1 root apache 45886116 Jan 4 07:22 f392214d4a3514b0d1f4f8b6392046681d5d67df
Using the last example above:
[root@sos trashdir]# file -b f3/92/f392214d4a3514b0d1f4f8b6392046681d5d67df
gzip compressed data, from Unix
Looks to be a backup file ... gzip compressed data and if I copied that file out of trashdir/f3/92/ to some other location so I could use it to do a test restore or take a quick peak at it:
[root@sos trashdir]# cp f3/92/f392214d4a3514b0d1f4f8b6392046681d5d67df /var/www/unirepo/somebbackup.mbz
Here's the test if it is a backup file:
[root@sos unirepo]# tar zxvf somebbackup.mbz moodle_backup.xml
moodle_backup.xml
if that extracts a moodle_backup.xml file then somebbackup.mbz is a backup file one can restore to the site.
Check of moodle_backup.xml
[root@sos unirepo]# head moodle_backup.xml
<?xml version="1.0" encoding="UTF-8"?>
<moodle_backup>
<information>
<name>backup-moodle2-course-144-td-20200104-0722.mbz</name>
<moodle_version>2019052003.04</moodle_version>
<moodle_release>3.7.3+ (Build: 20191205)</moodle_release>
<backup_version>2019052000</backup_version>
<backup_release>3.7</backup_release>
<backup_date>1578144133</backup_date>
<mnet_remoteusers>0</mnet_remoteusers>
Looks valid!
Again ... 'best of luck'!
'SoS', Ken