It’s so far from trivial that it’s essentially unsupported. (-: Far better might be to fire up another OMERO instance in a throwaway VM sitting atop a binary repository and DB restored from a pre-deletion backup, import the files afresh into your production server then write a script that uses the Blitz API to copy any post-import metadata (analysis results, manual annotations, etc.) between servers (probably the query service on the VM to the update service on production).
Once you delete an image you will see a number of
EventLog model objects get created noting each related thing that was deleted. The query service will provide these; they live in the DB’s
eventlog table. This records what was deleted but not much of what the previous database rows contained. However, you could probably use the object types and IDs to figure which rows to restore from a DB backup. Additionally,
omero delete --dry-run --report Image:63,64,65 run on your restored VM will report exactly what is deleted from the database for the images in question, with IDs 63 thru 65 in this case. I am not aware of anybody who has used this to restore deleted data and I am curious as to the outcome of attempts! I do think fixing up a fresh import is probably the best way to go though, also repeating any attachments / tables from the backup storage instead of trying to “fake” them post hoc.