What dedicated server management involves
Management splits into two layers. The physical layer, meaning power, cooling, the network and failed components, sits with the host and its data centre whatever plan you buy. The software layer, meaning everything from the operating system up, is where the managed or unmanaged choice applies. That second layer is a short list of jobs that never quite finish:
| Task | What it means in practice | When |
|---|---|---|
| Patching | Installing operating system and application security updates, and rebooting when a new kernel needs it | Continuously, with urgent fixes the same day |
| Hardening | SSH keys, a firewall, closing services you do not use, locking down the IPMI interface | At handover, then after every change |
| Monitoring | Disk health, RAID state, disk space, memory, load and whether your services are up, with alerts to a person | All the time |
| Backups | Copies off the server, at least one of them offline, and test restores | On a schedule that matches how much data you can lose |
| OS upgrades | Moving to a newer release before the old one stops getting security fixes | Every few years |
| Incidents | Working out why something broke, arranging a hardware swap, restoring data | When it happens, often at night |
Managed vs unmanaged dedicated server
With an unmanaged dedicated server you get full root or Administrator access and the host's job stops at the hardware and network. With a managed dedicated server the host's engineers also log in and do some or all of the software work. The hardware is identical; what you are buying is someone else's time and responsibility. A typical split looks like this, though every provider draws the line slightly differently, so read what their managed plan actually lists:
| Job | Unmanaged | Managed |
|---|---|---|
| Power, network, DDoS filtering | Host | Host |
| Replacing a failed disk, DIMM or power supply | Host | Host |
| First OS install | Host | Host |
| OS and control panel updates | You | Host |
| Firewall, SSH and other hardening | You | Host |
| Monitoring and responding to alerts | You | Host |
| Backups | You | Check the plan; often an add-on |
| Your application, code and data | You | Usually you |
The last row matters. Managed administration rarely means someone will debug your PHP or your database queries, and uptime guarantees normally exclude outages caused by your own software or settings. Managed buys you a maintained, watched operating system, not a development team.
Out-of-band access: IPMI and remote hands
Most dedicated servers have a small management controller, reached through IPMI, that works even when the operating system is down. Through it you can power the server off and on, watch the boot console, mount an ISO and reinstall the OS. For an unmanaged server this is what lets you recover from a 3 a.m. lock-out yourself instead of waiting on a support ticket.
That power is also the risk. CISA's advisory on IPMI points out that root access to the controller gives control over the hardware, firmware, reboots and OS installs, and that interfaces exposed to the internet are easy to find. Its recommendations are to restrict IPMI traffic to trusted internal networks, use strong unique passwords, use encryption, and disable cipher 0 and anonymous login. In practice: change the default credentials on day one, and reach IPMI over a VPN or private network, not an open public address.
For jobs that need a person in the room, such as a cable swap or a disk change, hosts offer remote hands. Check whether it is included or charged per job, and whether it is available round the clock.
Patching a dedicated server, and how long your OS is supported
NIST's patch management guide, SP 800-40 Rev. 4, treats patching as preventive maintenance with five steps: identifying, prioritising, acquiring, installing and verifying patches. The last step is the easiest to skip. An update that needs a reboot is not applied until the server has rebooted, and a service that fails to start afterwards is worse than the bug you patched.
Some of this can be automated. Ubuntu Server ships with unattended-upgrades enabled, applying security updates automatically once a day. That covers the routine fixes, but someone still has to schedule reboots, read what changed and check that the server came back healthy.
The bigger job is the release itself. Once an OS release reaches end of support, it gets no more security fixes, and a dedicated server often outlives the release it was installed with:
| Operating system | Security support until | Notes |
|---|---|---|
| Ubuntu 22.04 LTS | May 2027 (standard) | Ubuntu Pro ESM extends LTS releases to 10 years in total |
| Ubuntu 24.04 LTS | May 2029 (standard) | Same ESM option |
| Debian 12 | 30 June 2028 (LTS) | Debian LTS aims for at least five years per release |
| Debian 13 | 30 June 2030 (LTS, planned) | |
| AlmaLinux 8 | 31 May 2029 | |
| AlmaLinux 9 | 31 May 2032 | Active support ends 31 May 2027 |
| AlmaLinux 10 | 31 May 2035 | Active support ends 31 May 2030 |
| Windows Server 2019 | January 2029 (extended) | Mainstream support ended January 2024 |
| Windows Server 2022 | October 2031 (extended) | Mainstream support ended October 2026 |
Windows Server 2022 is worth a note: since its mainstream support ended in October 2026, it receives security updates only, with no new features. It is still supported, but plan the move to a newer release well before 2031 rather than the year it runs out. On Linux, Ubuntu 22.04 and AlmaLinux 9 both change support phase in 2027, so a server built on either today has a decision coming.
Hardening a new dedicated server
Hardening is the work you do once, at handover, so that the server starts life with a small attack surface. A sensible first hour on a Linux server looks like this:
- Log in with SSH keys, not passwords. Ubuntu's OpenSSH documentation recommends key-based login using ed25519 keys, with two-factor authentication on top if you want it. Once your key works, turn off password login.
- Create a normal user for daily work and use sudo, rather than logging in as root.
- Enable the firewall and open only the ports your services need.
- Remove or disable services you do not use. Every listening port is something to patch.
- Lock down IPMI as described above: new credentials, no open public access.
- Write down what you changed, so the next person, or you in a year, knows how the server was built.
For a fuller checklist, the CIS Benchmarks are consensus-based configuration guides covering many operating systems and products. Few servers apply every recommendation, but they are a good way to see what you have missed.
Monitoring disks, RAID and services
Hardware problems often give warning before they cause an outage, and disks are the usual place to look. On Linux, smartd watches each drive's SMART data, logs problems and can email you when a drive starts reporting errors. If you use software RAID, mdadm --monitor watches the arrays and can email on events such as Fail, FailSpare, DegradedArray and SparesMissing.
This is where RAID either helps or lulls you. A RAID 1 mirror keeps the server running when one disk fails, but it is now running on a single disk. If nobody gets the alert, the second disk can fail weeks later and take the data with it. Set the alerts up, send them to an address someone actually reads, and test that they arrive.
Beyond the hardware, watch disk space, memory, load and whether your actual services respond. A simple external check that loads your website or connects to your database every few minutes catches the failures that the server itself cannot report.
Backups: snapshots, RAID and the copy you can restore
Neither RAID nor a snapshot is a backup. RAID copies every change to every disk, including a deleted table or files encrypted by ransomware. A snapshot usually lives on the same storage it is protecting. A backup is a separate copy, somewhere else, that you have proved you can restore.
CISA's #StopRansomware Guide recommends keeping offline, encrypted backups of critical data and regularly testing their availability and integrity. For a dedicated server that means at least one copy the server itself cannot overwrite or delete, kept away from it, and a restore test on a schedule, not only after something has gone wrong.
Read your host's terms on this. Many hosts, including us, say plainly that any backups they take are a courtesy and that you remain responsible for your own. Unless you have bought a backup service, assume nobody else has a copy.
Who should manage your dedicated server?
Unmanaged suits you if you or your team already run Linux or Windows servers, want full control over versions and configuration, and have someone who will answer an alert at night. It is the cheaper option, and with IPMI access you can fix most problems without waiting on anyone.
Managed suits you if there is no sysadmin in the business, the server runs something customers or staff depend on, and you would rather pay a monthly fee than learn patching, RAID and firewall rules under pressure. It also gives you a named party responsible for the OS when an auditor or client asks.
Before you buy managed, ask:
- Exactly which tasks are covered, and which are not?
- Who applies patches, how quickly, and when do reboots happen?
- Who receives monitoring alerts, and what happens at night?
- Are backups included, where are they stored, and are restores tested?
- What does the SLA exclude?
If the honest answer is that nobody will look after the server properly, consider whether you need a whole machine at all. A smaller virtual server with dedicated cores is less to manage and costs far less.
How management works on a Bigdomainhost dedicated server
Our dedicated servers in Mumbai (BOM-1) and Delhi NCR (DEL-1) are unmanaged by default, which is the cheapest option. The DS-Entry plan, with 8 cores and 16 threads, 32 GB RAM and 2 × 960 GB NVMe, is ₹14,499 a month excluding 18% GST, the same in both locations, and every server is ordered by enquiry. Whichever you choose, the price includes:
- IPMI access on every server, so you can power-cycle, mount an ISO and watch the boot console without a ticket.
- 4-hour hardware replacement: a failed disk, DIMM or power supply is replaced within four hours of diagnosis, 24×7, at no charge, from spares kept on site.
- 24×7 remote hands for a reboot, cable swap or disk change, at no extra charge.
- RAID set up your way before handover; DS-Entry's two NVMe drives are commonly mirrored as RAID 1.
- Your choice of Windows Server 2019 or 2022, Ubuntu LTS, Debian, Rocky Linux, AlmaLinux or your own ISO, installed before handover.
Managed administration, covering OS patching, panel management, monitoring and hardening, is an add-on with no published price; ask for it in the same enquiry as the server. Off-site backup storage and control panel licences are extra too, and our uptime SLA excludes downtime caused by your own software or configuration. If a whole server is more than you need, a VDS gives you dedicated CPU cores from ₹3,576 a month.
Sources (checked )
- CISA: Risks of Using the Intelligent Platform Management Interface (IPMI)
- NIST: SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology
- Center for Internet Security: CIS Benchmarks
- Canonical: Ubuntu release cycle
- Canonical: Automatic updates - Ubuntu Server documentation
- Canonical: OpenSSH server - Ubuntu Server documentation
- Microsoft: Windows Server 2019 - Microsoft Lifecycle
- Microsoft: Windows Server 2022 - Microsoft Lifecycle
- Debian: LTS - Debian Wiki
- AlmaLinux: AlmaLinux Release Notes - AlmaLinux Wiki
- Ubuntu Manpages: smartd(8)
- Ubuntu Manpages: mdadm(8)
- CISA: #StopRansomware Guide