For databases, it should be trivial to roll out your latest backup. It's purely a question of how large your database is, as to how long it takes to restore. If it's a huge database, it may take hours, but that's life. If the bosses don't like it, they can spring for a second server.
If you've had a real catastrophe, you should be able to get to your offsite backup in no more than an hour. If it takes longer than that, you might want a new offsite strategy.
If it's a hack, rather than a hardware problem, it's more important (and time consuming) to make sure you don't get hacked again. That's the time sink. Identify how they got you, and close the hole. If you don't do that, then you're just wasting your time.
For code bases, you should be able to deploy that extremely quickly. It should be just a matter of re-deploying the production code, which, hopefully, is automatic or close to it. If the deployment is largely manual, do something about that. I once dealt with this awful .Net package that was all dlls that had to be manually registered, and they weren't all backed up in the same place. Nightmare.
The most important thing to do is to practice. Bring your people in on the weekend and do a bare metal rebuild. Then take 'em to a bar for a critique. Everyone should know where everything is, what the plan is, and what their part in the plan is. If you have to make a decision during a crisis, you've failed. It should be automatic.