You can restore the database on another server, as long as the Disaster Recovery (DR) server has the same version of SQL Server. (Technically, you could restore it to a server with a more recent version of SQL Server, but the database files would be upgraded at that point and you wouldn't be able to go backwards when the old server gets fixed. (You should be able to go back to an earlier service pack, but not an earlier version. )
if the disk storage system looks different, you may need to specify new paths for the underlying MDF, NDF and LDF files. So, you should know how to change the location of those files (vis SSMS or TSQL, what ever you prefer).
All data, indexes, constraints, procedures, etc. will be restored. Things that will not be restored are SSIS packages, relevant SQL Agent jobs, linked servers.
The database will resemble what it looked like at the end of the last backup, assuming that you are just taking full backups. (If you are running with FULL recovery mode and are taking transaction log backups, things get more fussy, but I think that is a different question.)
A common problem is logins. In SQL Server, logins are tied to a server, users are tied to a database and the SID is the value that relates the two together. For AD logins, SQL uses the SID from the AD login, for SQL logins, SQL Server makes up a valid-looking SID and keeps track of that.
If you are using domain logins for your applications, it would be best to join the DR server to the domain. If not, may have to do join it in a hurry because your applications might be using those domain logins. You'd have to create SQL credentials during your DR restoration efforts and fix any connections strings that use a trusted login. This is likely to be error-prone and time-consuming.
If you are using SQL logins for your applications, be sure that you create those logins using the exact same passwords (of course) and the exact same SIDs. (sp_addlogin has a parameter that allows you specify a particular SID.) If the SIDs do not match, users may be able to connect to the server but may not be able to properly access the data. There is a ton of googlable stuff on matching up the SIDs between logins and databases after the fact; the easiest thing to do is make sure that they match before the fact. So, did up Microsoft's login reverse-engineering script, run it, and keep the output (which is a script that can create logins) somewhere safe. (If your primary server is down, you won't be able to run it then.) You can run that script on the DR server when you have a failure, you can run it immediately. Note that if logins can change their passwords, you will have to do something to sync them on the DR server.
It is a good idea to try this at least once before you have to do it for real. If you aren't used to doing this sort of thing, and often if you are, something will always pop up and you'll have to scramble at the last minute.