What to check before you buy a dedicated server

A dedicated server listing gives you a processor model, a memory figure, a disk configuration and a price. Those are the easy parts to compare and the least likely to go wrong. What determines whether the machine is pleasant or painful to own sits in the questions the listing does not answer, and most of them can be settled before you pay.

The disks are probably used

Cheap dedicated servers are frequently re-rented hardware. The chassis, the drives and the power supply have all been running for years. That is not a problem in itself — enterprise drives routinely run for a long time — but it means drive condition is an unknown you should resolve in the first hour rather than the first incident.

# every block device, with model and whether SMART is available
lsblk -d -o NAME,SIZE,ROTA,MODEL
sudo smartctl --scan

# the numbers that matter, per drive
sudo smartctl -A /dev/sda | grep -Ei 'power_on|reallocat|pending|uncorrect|wear|percent|media_wear|total_lbas'

What to look at:

• Power_On_Hours — tells you the drive's age. 40,000 hours is over four years of continuous service.
• Reallocated_Sector_Ct and Current_Pending_Sector — any non-zero pending count on a spinning disk is a reason to ask for a replacement now, not later.
• Percentage_Used or Media_Wearout_Indicator on SSDs — the controller's own estimate of consumed endurance.
• Total_LBAs_Written — how much has been written to an SSD. Combined with its rated endurance this tells you what is left.

Then run a long self-test, which reads the whole surface and is the only way to find errors in regions nothing has touched recently:

sudo smartctl -t long /dev/sda
# hours later
sudo smartctl -l selftest /dev/sda

Ask the provider, before ordering, whether drives are new or used and what their drive-replacement policy is. A provider who answers plainly is telling you something useful about how they operate.

"Unmetered" and "unlimited" mean specific things

Network terms are where dedicated hosting hides most of its fine print. Three different arrangements all get marketed similarly:

• A port speed with a traffic allowance. A 1 Gbps port with, say, a monthly transfer cap. Exceeding it means overage charges or a throttle.
• Unmetered at a lower committed rate. A 1 Gbps port guaranteed at a much lower sustained rate. Traffic is uncapped in volume but shaped in speed.
• Genuinely unmetered at port speed. Rarer and priced accordingly.

The question to ask is not "is it unlimited" but "what is the committed rate, and what happens when I exceed it — throttle, charge, or suspension?" Get the answer in writing, because the difference between a throttle and a surprise invoice is the difference between a bad afternoon and a bad month.

Also ask about the uplink itself: whether the port is shared with other machines in the rack, and what the provider's transit mix is. A cheap network often means one budget transit provider, which shows up as poor routing to some regions no matter how fast the port is.

Out-of-band access decides your worst day

When the machine will not boot, the only thing that matters is whether you can reach it without the operating system. Three levels, in descending order of usefulness:

• Full IPMI/BMC access with remote console and virtual media. You can watch the boot, enter firmware settings, and mount an installer. This is what you want.
• A rescue mode that network-boots a small Linux image. Enough to fix a broken bootloader, repair a filesystem or copy data off. Adequate.
• A reboot button in a control panel. Enough to power-cycle, nothing more. If that is all there is, every serious problem becomes a support ticket with a queue in front of it.

Ask which you get, and whether IPMI is included or charged per use. Then test it on day one, while the machine is empty and a mistake costs nothing. Finding out that your remote console does not work during an outage is the expensive version of that discovery.

RAID: what it is, and who rebuilds it

Two drives in a listing could mean hardware RAID, software RAID, or two independent disks. All three are sold the same way.

If hardware RAID is involved, find out which controller, whether it has a battery or capacitor backing its write cache, and whether you can see its status from the operating system. A write cache without a working battery is a data-loss mechanism waiting for a power event.

# software RAID state
cat /proc/mdstat

# a common hardware controller, if the tool is installed
sudo storcli /c0 show
sudo storcli /c0/vall show

Then ask the operational question: when a drive fails, who notices, and who replaces it? With software RAID on an unmanaged server, the answer is you — which means you need monitoring that actually alerts, not a status file you will never read. Set that up before you need it:

# have mdadm email on failure
sudo sed -i 's/^MAILADDR.*/MAILADDR [email protected]/' /etc/mdadm/mdadm.conf
sudo systemctl restart mdmonitor 2>/dev/null || sudo systemctl restart mdadm 2>/dev/null

# and let smartd watch the drives themselves
sudo systemctl enable --now smartd

Managed, unmanaged, and what support will touch

"Unmanaged" usually means the provider is responsible for hardware and network, and everything above the operating system is yours. That is a reasonable deal at a low price, but be clear about the boundary:

• Will they reinstall the OS on request, and how long does that take?
• Do they respond to a hardware fault report at 3am, or only during business hours?
• Is there a stated response time, and is it a commitment or an aspiration?
• Do they touch firmware — BIOS and drive firmware updates — or is that yours too?

The honest providers in the budget tier say plainly that support covers hardware replacement and nothing else. That is fine if you know it going in.

Where the machine physically is

Latency is geography. Before committing, measure from where your users actually are:

# round trip and route from your side
mtr -rwzc 50 your-server-ip

# and the reverse path, from the server
mtr -rwzc 50 8.8.8.8

Routes are often asymmetric, so measure both directions. Many providers publish a looking-glass or a test file in each datacentre — use it before ordering rather than discovering the routing afterwards.

Jurisdiction matters too, separately from latency. The country the machine sits in determines which legal regime applies to the data on it, and for anything handling personal data that is a decision to make deliberately.

Power, and the single point of failure you are buying

A single dedicated server has one power supply, one motherboard and one network card in most budget configurations. Redundant power is a line item; so is a second uplink. Neither is usually included.

This is not an argument against a single server — it is an argument for knowing that your availability ceiling is set by that hardware, and planning backups and recovery accordingly. A dedicated machine with good backups elsewhere is a sound architecture. A dedicated machine whose backups live on its own second drive is not.

The first hour: a test sequence

Before you install anything you care about, confirm the machine is what was sold:

# CPU model, cores, and whether frequency scaling is sane
lscpu | grep -Ei 'model name|^CPU\(s\)|MHz|socket|core'

# memory size, speed, and whether it is ECC
sudo dmidecode -t memory | grep -Ei 'Size|Speed|Type:|Error Correct'

# does the quoted memory actually exist and work
sudo apt-get install -y memtester && sudo memtester 2G 1

# storage, condition, and throughput
lsblk -d -o NAME,SIZE,ROTA,MODEL
sudo smartctl -A /dev/sda | head -30

# sustained write, which also reveals thermal and cache behaviour
fio --name=seq --rw=write --bs=1M --size=20G --direct=1 \
    --ioengine=libaio --directory=/var/tmp --output-format=normal | grep -E 'bw=|WRITE:'

# network, to a public test endpoint in the same region
curl -o /dev/null -w 'down %{speed_download} B/s\n' https://speed.cloudflare.com/__down?bytes=200000000

# and what the kernel has already complained about
sudo dmesg -T --level=err,warn | tail -40

That last command is the one people skip and the one that most often finds something: correctable memory errors, disk resets, a link flapping. If the hardware is marginal, it usually says so in the log before it says so by failing.

A short list to send the provider

Most of the above condenses into questions worth asking before you pay. A provider's willingness to answer is itself information:

1. Are the drives new or used? What is their current SMART status?
2. What is the committed network rate, and what happens on exceeding it?
3. Is IPMI or a remote console included? Is rescue mode available?
4. Is RAID hardware or software? Who monitors and replaces failed drives?
5. What is the stated response time for a hardware fault, and does it cover nights?
6. Is the OS reinstallable on request, and how quickly?
7. Is the power supply redundant? Is the network uplink?
8. Which datacentre, and is there a looking-glass or test file I can measure against?

None of this makes a cheap server a bad buy. Budget dedicated hardware is often excellent value, particularly against cloud instances of similar capability. It makes the difference between buying a machine and buying a surprise.