Evan hit's on some good points, but here are maybe some specific cost effective way's to get sub 1 hour recovery time in the face of failures.
Small Business likely means small hardware, so it may not be alot of cost to do some simple things that actually add a significant amount of resiliency in the face of problems. THe main idea is just have extra hardware ready to go.
First, get comfortable with the thought of a virtual IP. That is the IP address that users will talk to, but can reside on any server you give it to. This is the IP address you're users, and applications will want to talk to. And it'll be the most helpfull for ultimatly any solution you go for. Having a VIP means that you shouldn't have to reconfigure any oft the applications when failing over. Also, keep in mind that having redundant hardware also has the impact of increases administration overhead, doing two configuration updates instead of 1.
If we start with you're routing / web proxy server, it's probably the easiest since their won't be any real state that needs to be stored on the box itself. So just get a duplicate of the same box, and configure it the same. I'd keep both plugged in on the LAN segment, and assuming you're internet is on another interface, swap cables if their is a failure. From a routing perspective, you set all you're lan clients to target the .1 address (the VIP) for their default route and proxy server give server A the .2 address and server B the .3 address. This way they can both be managed for config updates (applies to both). And all you have to do to failover is remove the .1 IP assignment from .2 and move it to .3, and move the internet connection to the other interface. It's not very complicated, easy to do and understand, and costs the extra hardware of a second box. If you can get redundancy on the internet side, you could add some complexity, and get automatic failover using something like VRRP.
Without specifics, it's hard to say but you're web server may be just as simple. Add a second server with Identical configuration, create a vIP between the two, and move the VIP to the backup in the face of failure. I generally don't mind if session state is lost on a failover (it's a critical problem to cause a failover). So if users have to log in again, no big deal. Again, vrrp can probably be used for automatic failover.
Moving onto you're DB, this is significantly more complex. Most DB's have some sort of primary / secondary model, where you backup the original DB to the secondary, and then copy all transaction logs or DB changes to the secondary. Again, you can combine this with VIP's for the applications / users actually accessing the DB. However, failover is more complicted. Depending on the failure of the primary, you may need to actually get the drives up and running to copy and leftover transaction logs. Then bring the secondary active. If you can tolerate some lost data, then you can bring the secondary active right away. After the failover, server B is now you're primary, and you're work would be to restore server A, and turn it into the new backup so it's ready to be failed to when server b eventually has problems.
File servers are always the hardest part, since unlike DB's, it's alot harder to get a built in feature of the file system. However, some level of resiliency can be achieved by having a second server, and simple write a script that scans the filesystem for changes, and copy any new files to you're secondary. You can basically run rsync on a cron I beleive to do this. Again, you use a VIP that you give to users, that you move over if you do a failover. In you're script, I wrould highly recommend that you check to make sure the system is the owner of the VIP before transferring files. You really really really don't want the rsync to execute in the wrong direction and overwrite any changes you're users are making. This could lose some files if their is a failure, and also will not protect again users wiping out files themselves.
I have no idea what you could do about you're phone system... it really depends on the vendor and how it's setup. The vendor may have some off the shelf solution for resiliency.
Some final words of warning. Make sure you thoroughly test any setup you are going to go with. Make sure you know how to fail it over without losing that critical information. Test test test to make sure it will work when you need it to. Make sure you have processes in place that configuration changes, software updates, etc get applied properly to both primary and backups. The good news is, you can probably do controlled failover's when you want to bring a server down to upgrade, etc. It's not an active-active setup, so you have no idea if the secondary will work when you need it.
I work in telecom, and our equipment is very highly redundant, including in most cases geo-graphic redundancy. Our number 1 point of failure is redundancy isn't tested after changes, and users making changes that don't know how the redundancy model works. However, we have the added problem that all our equipment needs to support automatic failover in no more than several seconds. You can tolerate manual intervention in you're failovers if you only need to be up and running within 30 - 60 minutes. You just need to be prepared. Good luck.