If the programs executed from /tmp are still running, you can usually still retrieve the original binary even if it is "deleted" from the filesystem, because the inode still exists with the data; the removal is just unlinking the name from the directory.
In Linux, you can access the inode's contents via the /proc/PID/exe link. Tools like
ls will show you the original path and mark the link as broken (colorwise) and the listing will say something like "(deleted)" in the name. However, you can still retrieve it by reading the file.
An example showing this concept (using sleep as an illustrative tool):
$ cp /bin/sleep /tmp/otherprog
$ /tmp/otherprog 300 &
$ rm /tmp/otherprog
$ ls -l /proc/3572/exe
lrwxrwxrwx 1 john john 0 Feb 27 08:54 /proc/3572/exe -> /tmp/otherprog (deleted)
$ cp /proc/3572/exe /tmp/saved
$ diff /tmp/saved /bin/sleep
$ echo $?
I created a "new" program by copying the contents of the sleep program to a new program called "otherprog" and ran it such that it would keep running for a while. Then I deleted the program from /tmp. Using the PID I got from the shell (you can find the PIDs of the programs you care about via
ps) I looked at the exe link in /proc, then copied the contents of the file (even though target file name is gone), and checked that the contents match the original.
This of course won't work if the programs from /tmp are short-lived, because once they exit, the link count of the inode will drop to where the data is actually freed from disk.
It does avoid racing to copy the file before it is unlinked from the /tmp directory.