On a dedicated server nobody is backing anything up unless you set it up. There is no platform snapshot underneath and no infrastructure copy to fall back on: the provider protects the hardware and the network, and what runs on the machine is entirely yours.
RAID is not part of this
Worth stating first because it is the assumption that costs people their data.
RAID protects against a disk failing. It writes a deleted file, a corrupted table, ransomware and a mistaken command faithfully to every disk in the array, instantly.
A server with mirrored disks and no backups has no backups.
What a complete backup contains
Application files; the web root and any uploads directory.
Databases, dumped rather than copied. Copying database files while the service is running produces an inconsistent copy that may not restore, and you find that out during the restore. Use the database's own dump tool.
Configuration. Web server config, service definitions, cron jobs, firewall rules. Small, and the part everyone forgets. It is what turns a restore from "rebuild the server from memory" into "put the files back".
It has to leave the machine
A backup on the same server protects against a deleted file and nothing else. A compromised server can reach and destroy its own archives; a failed array takes them with it.
Push to remote storage, and use credentials that can write but not delete if the storage supports it. That single detail turns a full compromise from a total loss into an inconvenience.
Automate it and make it complain
Manual backups lapse within a quarter. Write the job once: dump the database, archive files and configuration, push it off-server, prune local copies.
Then make failure noisy. A backup job that has been failing quietly for six weeks is indistinguishable from having none, and that is the most common way people discover they have none.
Retention
Daily for a week or two, weekly for a couple of months, one monthly kept longer.
Three days feels sufficient and is not: compromises and slow corruption are usually discovered long after they start, so a short rotation may contain only already-broken copies.
Know how long a restore takes
This is the number that turns backups into a recovery plan, and almost nobody measures it.
Restoring a large database takes hours, not minutes. If your acceptable downtime is two hours and a full restore takes six, you do not have a recovery plan; you have archives.
Time it once, on real data. The answer determines whether you need a standby server, replication, or simply a realistic expectation.
Test a restore deliberately
Restore to a spare machine and check the result properly: does the application start, is recent data present, does it actually work.
You are looking for specific, common failures; a directory excluded by a pattern nobody reviewed, a dump truncated by a timeout, a configuration file never included. All discoverable now in half an hour; all discovered at the worst possible moment otherwise.
Recovery order
Rebuild or reinstall first if the server was compromised, restoring on top of a compromised system leaves whatever caused it in place.
Then files, then database, then configuration, then start services. Update everything before it goes back online, or the same automated scan finds the same unpatched service within days.
Document that sequence somewhere that is not on this server. The moment you need it is the moment the server is unreachable.
A server that hosts something being written to continuously. A shop, an application taking submissions, has a timing problem on top of everything here: How to Back Up a Store That Takes Orders Continuously deals with it.
What a bare-metal restore actually needs
Restoring files onto a working server is straightforward. Rebuilding a machine that no longer exists requires several things people do not think of as backups.
The partition and array layout. Recreating it from memory is guesswork, and getting it wrong means restoring onto a structure the system will not boot from.
lsblk -f > /root/layout.txt cat /proc/mdstat >> /root/layout.txt storcli /c0 show all >> /root/layout.txt 2>/dev/null blkid >> /root/layout.txt
The network configuration. Addresses, gateways and routes. A restored machine with no network is a machine you cannot reach to fix.
The bootloader. A file-level backup restores the files and not the boot sector. Whatever tool you use, know whether it makes the result bootable or whether that is a manual step.
Keep that file with the backups rather than on the machine it describes, which is the whole point, and the mistake that makes it useless.
The things that are not files
On your own hardware, several pieces of configuration live outside the filesystem entirely and are lost with the machine.
The array controller's configuration. Which disks form which array, in what order, with what settings.
Firmware and BIOS settings. Boot order, virtualisation options, power settings; anything changed from the default.
The management controller. Its network address, its user accounts, and its own firmware version. Server hardening best practices deals with why that interface is a machine in its own right.
Photograph or export these once, when the server is built, and store it with the layout file. It takes ten minutes and it is the difference between rebuilding in an afternoon and rediscovering decisions somebody made two years ago.
Restore to different hardware once
A restore onto the same machine proves the backup is readable. It does not prove you can rebuild after a hardware failure, which is the scenario the backups exist for.
Restore onto a different machine. A rented server for a day, or a virtual machine, and find out what breaks. The usual discoveries are network configuration tied to a hardware address, licences bound to the original machine, and drivers that differ.
All three are cheap to solve during a test and expensive to discover during an outage. Testing a new server before putting it into service walks through the machine you would restore onto.
Write the order down
Not the commands. The sequence and the decisions. Which service comes back first, what has to be checked before traffic is allowed, who is told and when.
Recovery is done under pressure by whoever is available, who may not be the person who set it up. A written order is what makes that possible. There is more on the communication half, which should be in the same document in telling clients about maintenance and outages.