Hetzner Dedicated setup: what breaks during a typical installation
The typical scenario for bringing up a dedicated server looks harmless: default disk partitioning, one administrative key for everyone, a basic package set, and updates “sometime later.” Failure does not come immediately — first it is rare service restarts, then a nighttime incident when the root partition runs out of space and data and logs have grown several times over.
That is also when it turns out that backups are configured formally and recovery from them has never been tested.
Hetzner Dedicated setup without an access scheme costs more: keys remain with a previous contractor, changes on the production machine are made directly, and no one keeps a change history.
A separate class of errors during server setup is networking and updates: service ports are open to the outside, the kernel is updated without a reboot, and the vulnerability remains closed only on paper.
The root cause here is not in the hardware, but in the absence of a server configuration tailored to the task.
The outcome is predictable: dedicated server administration comes down to manually dealing with incidents at night, and recovery takes hours of manual work instead of minutes.
That is why we start dedicated server setup not with installation, but with analysis: which services run on the machine, what is critical to failure, who has access, and how quickly operability needs to be restored. Below, we break down how this is addressed.
What changes after migration: access, redundancy, updates
Before migration, access is spread out: root by password, shared keys in chats, and the contractor keeps an account “just in case.” After setup, login is only by personal keys, permissions are distributed by role, and every action goes into a log.
No “shadow” access remains — a departed employee’s key is revoked with a single command, and this is visible in the audit.
Service redundancy is not “a backup once a day,” but a replica on a second node plus a regular snapshot with recovery testing. Separately, we make sure the snapshot actually deploys: a copy that has never been restored does not count as a backup.
Recovery time after a failure drops from hours to tens of minutes — the server is deployed from code, not assembled from memory.
Scheduled updates proceed without downtime: first the standby node is updated, then traffic is switched, and kernel reboot falls into an agreed low-traffic window. If validation fails, the switch is rolled back, and users notice nothing. Security updates stop being an emergency: the window is known in advance.
Dedicated server fault tolerance rests on disk mirroring, monitoring of key metrics, and automatic failover to a standby. Configuration is stored as code, so the state is reproduced from the repository rather than learned by hand.
On Hetzner dedicated servers, this provides a predictable foundation: the hardware is under our control, and service behavior is described and tested.
Deployment options: manual setup, templates, automation
The three approaches differ not in tools, but in how much effort goes into maintenance six months after launch. Manual server setup gives full control: kernel parameters, disk partitioning, firewall rules, and the service set are selected for a specific workload.
The price is environment reproducibility: the state lives in command history and in the engineer’s head, and a second such machine is built anew and with discrepancies.
Configuration templates pin down a standard set — packages, users, network rules, data directories — and deploy it to a new machine in minutes.
Deployment automation goes further: the infrastructure description is stored in a repository, changes undergo review, and the configuration is restored from scratch without manual steps.
| Option | When it fits | Limitations |
|---|---|---|
| Manual server setup | a single node for a non-standard workload, one-off hypothesis checks | not reproducible; every change is a manual operation; discrepancies between machines are found by manual comparison |
| Configuration templates | 2–10 standard servers with repeatable roles: web, database, queue | the template becomes outdated and diverges from reality; updates are rolled out partly by hand |
| Deployment automation | a fleet of servers, frequent releases, strict reproducibility requirements | discipline is needed: infrastructure description, change review, time for initial development |
The choice is rarely binary: manual setup remains for nodes with special requirements, templates cover standard roles, and automation covers everything that must be restored one-to-one.
On Hetzner dedicated servers, we move the infrastructure toward the third option gradually, starting with the areas where manual changes already cost the most.
Work stages: from server audit to access handover
Our Hetzner Dedicated setup begins with a server audit, not with software installation: we need to understand how disks are partitioned, which ports are open, and what is already running.
From this grows the setup work plan and the infrastructure diagram, which you approve before the first change on the machine. The stages then proceed sequentially, and each has a verifiable result.
- Server audit. We capture the current state: disk partitioning and health, network interfaces, running services, accounts, open ports. The output is a prioritized list of risks.
- Infrastructure diagram. We agree on the target state: which services run on the machine, what access rules apply, where data is stored, where backups go, and in what order updates are performed.
- Setup. Updates, key-based login instead of passwords, firewall, permission separation, service isolation from each other, log rotation.
- Data and copies. We deploy production services, enable scheduled backups, and verify recovery without fail — a copy from which data has never been restored does not count as production-ready.
- Failure testing. We break things intentionally: reboot, loss of connectivity, service stop, disk overflow. We record recovery time and transfer it into instructions for your team.
- Server handover to the customer. We hand over access, documentation, and the service map, walk through them together with your engineers, and revoke our keys. After that, the machine remains under your maintenance.
What you keep: configurations, diagrams, policies
All nodes are handed over not as a “black box”: you keep a set of artifacts by which the infrastructure can be reproduced, maintained, and handed over to another team — without retelling from memory or searching for the person who configured it. Below is what is captured in configurations and documentation by the time of handover.
- Configurations and inventory. Declarative descriptions of roles and parameters: network settings, filtering rules, limits, task schedules, mapping of services to nodes — a new server is brought up from them, not assembled manually from scratch.
- Infrastructure diagram. Topology, addressing, segments, external dependencies, and failure points; the diagram reflects the actual state, not the design intent.
- Access policies. Roles and permissions, the procedure for issuing and revoking keys, their lifetime, separate accounts for services; access is set up under your accounts.
- Backup policy. What is copied and how often, retention depth, where copies are stored, how recovery is tested, and in what time the node returns to operation.
- Maintenance instructions. Scheduled work, update procedure, log rotation, response to triggered checks, escalation procedure, and known node limitations.
- Server documentation. A profile for each node: purpose, resources, placement, dependencies, owner, change history.
- Handover session. A walkthrough of the artifacts with your team or your engineer, answers to questions on contentious points; repositories and access remain with you.
The set is self-sufficient: development, migration, or incident analysis tasks are resolved using these materials, not by messaging the person who configured it.
Case study: how we reduced recovery time after a failure
Starting point
Two dedicated servers operated as independent units: the application and database ran on one node, and the second was used for test copies. Setup was done by hand, configurations diverged — what was tested on one node produced a different result on the second.
In case of failure, recovery took about three hours: bring up the node, recall the sequence of steps, restore from the nightly copy, and lose a day’s worth of data. Scheduled updates also meant 30–40 minutes of downtime.
What we changed
We separated roles: application, database, and entry point on separate Hetzner nodes, each brought up by the same declarative configuration and verified by automated tests.
The database was moved to hot replication, and the entry point was placed behind a fault-tolerant load balancer with automatic failover when a node is lost. We added incremental backups and snapshots before each release, plus monitoring with thresholds for load and queue length.
What was achieved
Recovery time after a node failure dropped from three hours to 10–12 minutes, and most of it is automation, not manual steps. Migration to the new configuration took place without service interruption: traffic was switched gradually as replicas warmed up.
Load is distributed between two nodes, and peaks no longer cause degradation — previously, response time grew along with the queue. Manual operations in a release went from fifteen to two, and both are confirmed with a single command.
How does a dedicated server differ from a cloud virtual machine?
A dedicated server is a physical machine where CPU cores, disk I/O, and network bandwidth belong only to your service. A cloud virtual machine runs on a shared hypervisor and shares host resources with neighbors.
The difference shows up in distribution tails: under peak load, latencies on dedicated hardware remain stable, while on a virtual machine they grow when a neighbor starts its workload.
| Criterion | Dedicated server | Cloud VM |
|---|---|---|
| Resource isolation | Full: no one but you is on the hardware | Shared hypervisor, neighbors affect latency tails |
| Load predictability | Stable with a known profile: database, queues, billing | Variable: declared limits and actual performance diverge under peak |
| Cost of ownership | Fixed rental for the machine, beneficial with constant load | Consumption-based payment, beneficial during idle periods and short tasks |
| Maintenance complexity | You are responsible for disk partitioning, RAID, updates, monitoring | The provider covers the hardware; you cover only your stack |
| Scaling | Vertically and horizontally, but in large increments | Within minutes, in fractional increments |
The choice is dictated by the workload profile, not fashion. Constant utilization from half capacity, a database with strict disk requirements, custom licensing rules — these are dedicated machines: resource isolation there is not an abstraction but measurable predictability.
On Hetzner, such configurations are built for production, where response time matters more than elasticity.
The opposite situation is short experiments, seasonal spikes, batch queue processing. Here the cloud is cheaper in total cost of ownership: you pay for actual consumption and do not keep idle hardware.
A compromise is a hybrid: the application layer in the cloud, disk- and memory-sensitive services on dedicated nodes.
In practice, the decision is made based on three measurements: peak and median latency under load, data growth profile, and the cost of downtime during a failure.
If latency tails are critical and the load is stable, we take a dedicated server and configure it for the task; if experimentation speed matters more, we start with virtual machines.
Describe your service profile — we will come back with an assessment of which option addresses the task and how to arrange the transition.
Technical questions: backups, monitoring, updates
Most questions at this stage are not about how to bring up a Hetzner server, but about what happens after access handover. Below are technical concerns that come up before launch: copies, response to failures, updates, and independent changes.
How do you verify that a backup will actually restore?
Server backup without recovery testing is a report, not insurance. Once a month, we deploy a copy on a separate node, bring up the application, and compare the data with the production environment. The output is a record: what was restored and how long it took.
Who learns about a failure first — you or us?
Availability monitoring looks at the service from the outside, not just at the server’s own load. Alerts go to the on-call engineer, with response within 15 minutes; we bring you in when the incident requires your decision. After the review, we record what was changed so the failure does not recur.
Do updates require stopping the service?
No, if the application is ready for it. We perform zero-downtime updates through a second copy of the environment: the new version is brought up alongside, tested in a staging environment, and traffic is switched after successful validation. If it fails, we return to the previous version.
Can you edit the server yourselves after handover?
Yes, access remains with you. But manual changes diverge from the infrastructure description — and the next update overwrites them. Therefore, post-handover support is structured so that changes go through the same set of checks. We discuss quick fixes “on the live system” separately.
Let’s discuss the task: send the diagram and requirements
The estimate for Hetzner Dedicated setup depends not on the number of machines, but on the accuracy of the inputs. So that we come back with an implementation plan rather than clarifying questions, send the requirements in one message — according to the points below. We will fill the gaps on a call with an engineer, but it is better to know about them in advance.
- Service composition: application, database, cache, background jobs — and how they are connected to each other.
- Expected load: peak requests per second, data volume, write intensity, number of concurrent users.
- Network diagram: what is open to the outside, what remains in the internal network, whether a load balancer and a separate monitoring node are needed.
- Storage and partitioning: how many disks, whether RAID is needed, which directories we move to a separate volume.
- Access requirements: who on the team connects, by keys or passwords, whether action auditing and permission separation are needed.
- Backup: copy frequency, retention period, acceptable data loss, and target recovery time.
- Maintenance window and acceptance criteria: when a reboot is acceptable and by which checks you will accept the finished configuration.
Then we assemble an implementation plan: stages, migration order, rollback points, timelines. Preparation for server launch usually takes from a few days to a couple of weeks — depending on the service composition and access requirements. Describe the task — we will come back with an estimate and work plan.