As you’ve probably figured, the key is to be able to construct a query that will find you the image(s) in the database, wherein the originalfile table also captures filesystem paths. The database schema fairly closely follows the structure navigable in the OMERO model object glossary. Information on when images were imported, deleted, who owns, them, etc. is all recorded among the objects and their properties. The usefulness of the “old” version is much about that, after deletion, metadata about the image is no longer retained so, for instance, you can determine from the present database what was deleted when, perhaps by whom, but find out more about those things only from the old copy.
The metadata encoded in the template path used at import time might, if one is lucky, already provide enough to find the image on the backup of OMERO.server’s binary repository.
Of course, recovering and restoring post-import metadata such as users’ annotations is a whole other discussion for which, again, the devil is in the details.
There is also some potential for using the server logs as an extra source of clues but those are less-friendly still and, with luck, unnecessary.
In general I would recommend against believing that you have any capability to restore from backup except during periods when you have recently demostrated such a capability. 
It’s astonishing what one sometimes learns about some relevant previously unadvertised detail of one’s institution’s backup system.
