And LOG backups? If you aren't using Full Recovery Model on DBs that you want to have a Disaster Recovery Restore on and if they contain changing data (e.g. OLTP) then ... IMHO ... You Should Be
Personally I would do the following:
Inform all users, disconnect all users from DBs, stop all Scheduled Tasks, prevent any external access from anything which does Remote Connections and/or Batch Updates through API/similar. It helps if there is a single "Button" that you can press that does this - i.e. something "Prepared in advance"
Is there a need to restore? Generally SQL will fail-safe (rollback all incomplete transactions WITHOUT any database corruption). For example, after a Power Failure. For your Disaster Recovery Test I am sure you need to do a Fire Drill Restore, but in real life that may not be required if the database passes a "Safe to use" test - e.g. running DBCC CHECKDB, so that would be my first step - but always proceed to Step 2 if doing a Fire Drill
First make a TAIL TLog backup (if you can - i.e. server / disks have not been destroyed!)
Restore the latest FULL backup for each database, followed by all the TLog backups (and finally the TAIL TLog backup, if you were able to make one). Only use RECOVERY after the last Restore has been made successfully.
Probably then run DBCC CHECKDB to check that the database is OK, but if that will take a long time (because your database is large) you may let users back into the DB whilst the CHECKDB is running [with the previso that they may lose data if the CHECKDB fails and you THEN have to restore to an earlier date - but if your backups have been made from a "clean" database, better still: if your backups are test-restored onto a standby/DEV server, there is almost zero chance that they will fail to restore]
re-enable Scheduled Tasks, Remote Access and User Access and inform users that the system is ready for use.
But ... the problem that then arises is that you have N x Databases to restore, you have to locate the most recent Full Backup for each of them, and you have M x TLog files to restore (for EACH database - in Full Recovery Model). Its a lot of files, and you really need a script that will do all that for you, rather than trying to do it manually (at a time when speed is of the essence, to allow users to resume working)
IF your MSDB database is intact you can use that to query what backups were made, when, and the location of their files. There are scripts available which will restore one/many DBs based on MSDB data.
If your MSDB is NOT available / or NOT current (you can only restore it from a backup several hours/days old perhaps) then you will need a script which looks at the physical backup Files available in a particular folder. If you always name your backups consistently (e.g. MyDatabaseName_21060522_090712.BAK) then a script can "parse" the database name, and the date/time parts to sequence the restores in the original order (but beware of daylight saving time changes and overlapping filenames ...)
But note that ALL your backup files must be available in that folder. IF you allow people to "just take a quick backup for Belt & Braces safety", and IF they are allowed to put that backup "anywhere" then all bets are off ...
... we have an SProc that makes a backup of a database, it requires three parameters - name of the DB, type (Full, Diff, TLog) and, optionally, a comment. We require that all backups are made using this SProc to ensure that they are in a specific folder etc. This is stipulated in any contracts with 3rd parties so that there are no "workarounds".