sql server down bad things happens
Remember: you do not have a recovery plan until you tested your recovery plan...

The theory is simple: on the disaster recovery machine you have prepared for such cases you restore the most recent full backup, then you apply the most recent diff backup (if any) and then all the hourly log backups taken after the most recent diff (or after the most recent full if no diff was yet taken since the last full). Since you were not able to backup the tail of the log, you will loose up to one hour of transactions. Since your whole recovery schedule was based on a plan to be able to restore within the maximum allowable downtime, your restored server will be up and running (including all jobs, migrated logins etc etc, and the application will be redirected to it...) within the allowed downtime, because you tested this before and is a known procedure, and the operator follows the well know checklist you have set in place for such an event (and had tested it!). And btw, if the maximum allowable downtime is shorter than the physical time required to do a full restore a 4.1Tb DB (which is measured in hours), then some warm or even hot standby (mirror, log shipping) is ready to take on the work... 

What happens in the real world is that usually this is the moment when the power of hope (let's hope this never happens...) hits the hard wall of reality...