Dedicated server acceptance: what to check right away

Before you migrate any data, spend an hour on four checks: the hardware matches the order, the disks have not burned through someone else's lifetime, the array is assembled and healthy, and the uplink delivers the advertised speed. All of it takes about a dozen commands and lands in one file. If a discrepancy surfaces later, it is harder to prove and the rollback costs downtime.

Verify four things against the order: CPU model, memory size and type, disk count and size, port speed.
ECC must be active: dmidecode -t memory should report an Error Correction Type mentioning ECC.
Look at Power_On_Hours on the drives: tens of thousands of hours on a "new" machine is worth a question.
Passwords and keys change before the data moves in, not after.

Step 1. Match the configuration against the order

What you check	Command	What it should show	Sign of a problem
Processor	`lscpu`	the model and socket count from the plan	a different Xeon, one socket instead of two
Memory	`dmidecode -t memory`	size, DDR4 type, Error Correction ECC	ECC disabled, fewer modules
Disks	`lsblk -d -o NAME,SIZE,ROTA`	the drive count and size from the plan	SATA SSD instead of NVMe
Array	`cat /proc/mdstat`	the ordered level, state `[UU]`	degraded from day one
Network port	`ethtool eno1`	Speed matching the plan uplink	100 Mbps instead of a gigabit

For example, the Dedicated Pro DE plan lists an Intel Xeon E5-2680v4, 32 GB DDR4 ECC, 2×1 TB NVMe in RAID1 and a 1 Gbps uplink. So lscpu should report 14 cores and 28 threads, and nvme list two 1 TB devices.

lscpu | grep -E 'Model name|Socket|Core|Thread'
dmidecode -t memory | grep -E 'Size:|Speed:|Type:|Error Correction'
lsblk -d -o NAME,SIZE,ROTA,MODEL
nvme list
cat /proc/mdstat

The full list of configurations and paid options lives on the dedicated servers page; compare against that.

Step 2. Drive and memory condition

A new server does not imply new drives: media regularly returns to the pool after previous tenants. Check the runtime and the error counters before your data lands on them.

apt install -y smartmontools rasdaemon stress-ng

# SATA SSD and HDD
smartctl -a /dev/sda | grep -E 'Model|Power_On_Hours|Reallocated|Pending'
# NVMe: endurance and warnings
smartctl -A /dev/nvme0n1 | grep -E 'Percentage Used|Media and Data'

# 20 minutes of load; the ECC counters before and after must match
ras-mc-ctl --summary
stress-ng --cpu "$(nproc)" --vm 4 --vm-bytes 80% --timeout 20m --metrics-brief
ras-mc-ctl --summary

Percentage Used above 10% on a "new" NVMe, non-zero reallocated sectors, or tens of thousands of power-on hours are all worth raising with support in writing straight away. How to read the remaining attributes is covered in the article on SMART disk diagnostics, and a full memory run in the article on testing server memory.

Step 3. Uplink and performance

# port speed and mode
ethtool eno1 | grep -E 'Speed|Duplex|Link detected'

# throughput and packet loss
iperf3 -c ping.online.net -P 8 -t 30
mtr -rwc 100 8.8.8.8

Mind the plan terms: Dedicated Start US has a gigabit port but a 30 TB monthly traffic allowance, while Pro and Enterprise come with unmetered traffic. The method for measuring disks and CPU is covered in the article on benchmarking a server with fio and sysbench; run it before production load so the numbers are honest.

Step 4. Access and baseline security

Change the root password you were issued and switch to key-based login.
Test the console: the KVM/IPMI option on ZevsHost costs $5 per month and is already included in Dedicated Enterprise US. Connect to it now rather than during an outage; what it gives you is described in the article on IPMI and KVM-over-IP. Change the factory BMC password straight away.
Bring up a firewall before you expose any service: the order of the first steps is in the article on basic server hardening.
Note that outbound SMTP on ports 25, 465 and 587 is closed by default and opened on request for verified customers.

Step 5. Record the baseline

{ date -Is; lscpu; dmidecode -t memory; lsblk -f; cat /proc/mdstat;
  ip -brief addr; smartctl -a /dev/sda; } > /root/acceptance.txt 2>&1

Six months later this file answers "was it always like this, or did it change" in seconds. Copy it off the server: a snapshot that exists only on the machine under investigation is useless exactly when you need it.

Do not migrate data until the checks are finished. Once production databases and files live on the server, replacing a disk, a memory module or the whole machine turns from a ten-minute operation into a migration with downtime. This matters most for the array: if cat /proc/mdstat shows a degraded state or a resync running from day one, wait for it to finish and confirm the state becomes [UU]. Acceptance is passed when the configuration matches the plan, SMART is clean on every drive, the ECC counters did not grow under load, ethtool reports the advertised port speed, and the snapshot is stored off the server.

Key takeaways

Check CPU, memory, disks and port against the plan before the data moves, not after.
ECC must be visible in dmidecode, and the array must sit at [UU].
Power-on hours and SMART counters reveal whether a drive is new or previously used.
A short stress test exposes a failing memory module while the server is still empty.
Take the baseline configuration snapshot on day one and keep a copy off the server.

Dedicated server acceptance: what to check in the first hour