Hardware fails on a schedule nobody consults you about. When a dedicated server dies, the difference between a short bad evening and a week of outage is almost never the failure itself. It is which of five things you set up while everything was healthy. We run UK dedicated servers for a living, so this is written from the recovery side of the table: what we watch customers go through, and what the fast ones did differently.
Every serious dedicated server ships with an IPMI, iLO or iDRAC port. It lets you power-cycle, mount an ISO and read the console from home, even when the operating system is dead. The problem is that most people never log into it until the night they need it, and discover the password was never set, the licence expired, or the management IP was firewalled a year ago "for security" and nobody remembers the rule. Log into your out-of-band interface today, while nothing is wrong. Change the default password, note the URL, and confirm the console actually renders. Ten minutes now. On failure night it is the difference between rebooting into rescue mode yourself and opening a support ticket that says "please check my server" and waiting.
We have written before that RAID is not a backup, and the failure night is where that bill comes due. If your backups live on a second drive in the same chassis, a motherboard failure takes both copies with it. Backups must leave the box: rsync or restic to a second server in a different location, or object storage in another region. Two rules make the difference. First, the backup job must alert when it stops running, because silent backup failures are the classic pattern: everything "worked" for eleven months and the last good copy is from June. Second, you must have done at least one real restore. An untested backup is a hope, not a procedure. Time your restore once and write down how long it took; that number is your real recovery time, and it is usually two to five times longer than people guess.
When a server is unrecoverable, you do not want to be learning IP failover at 2am. There are three patterns. With failover or virtual IPs you re-point an address to a standby machine in minutes. With your own BGP announcement, as we covered in our article on BGP and failover IPs, your address follows your announcement anywhere you can bring a session up. And with plain assigned IPs, your only fast move is DNS: drop the TTL on your records to 300 seconds now, while things are healthy, so a future switch propagates in minutes instead of a day. Whichever pattern you have, the time to rehearse the re-point is this week, not during the outage.
The 4-day recoveries usually have plenty of backups and no destination. Restoring 800GB onto a fresh server takes hours of transfer before configuration even starts. Keep a standby option warm: a small secondary server already running your stack, or at minimum a documented build: the OS template, the config files in version control, the DNS zone files exported, the firewall rules in a script. The test is simple. If your main server vanished right now, could you rebuild an equivalent machine from a git repository and a backup destination, without remembering anything? If the answer involves tribal knowledge in your head, that is the gap.
Read your provider's SLA for hardware replacement before you need it. Many budget dedicated offerings carry next-business-day replacement, which sounds fine until you do the arithmetic on a Friday night failure: that is 60+ hours of outage from a clause you never read. Ask two specific questions before buying: what is the guaranteed hardware replacement window, and is out-of-band access included or a paid extra. Then keep your own records of the hardware, the RAID layout, the OS and partitioning, so a conversation with support does not start with twenty minutes of archaeology. When you compare providers, replacement windows and network redundancy matter more to your real uptime than a benchmark score; our provider selection guide goes deeper on that checklist.
Nobody earns a fast recovery on the night of the failure. You earn it in advance: out-of-band access tested, backups off-machine with a tested restore, an IP move you have rehearsed, a landing zone that exists, and a host contract whose replacement window you have actually read. Of the five, the two that save the most time in practice are the tested restore and the low DNS TTL, and both are free. Spend one quiet afternoon on this list and the next hardware failure becomes a story about a bad evening instead of a week of downtime.