Get in touch

Home/Projects/IT infrastructure

Case study · In production

Our own infrastructure,backup, anti‑ransomware

Our own IT infrastructure: virtualized servers, a VPN with a standby server that starts on its own, offsite backup for 10 jobs and anti-ransomware protection. Everything has to run unattended, sometimes for two weeks at a time, and every component has been checked through tests and drills.

2.2–2.5 sfrom suspicious access to detectiondrills, 3 Nov 2026
4.2–6.4 suntil alerts reach phone, e-mail and WhatsAppsame drills
~5.5 mintotal outage during VPN failovertest, 31 Oct 2026
10offsite backup jobs, with versions kept for 30 daysservers, databases, virtual machines
The situation

Where we started

We have physical servers at several locations, plus client sites that we manage remotely. Access went through a VPN on an old protocol with a single server: if that server went down, nobody could reach the network.

We are regularly away for two weeks at a time, so the systems have to look after themselves: recover after a failure, copy data off-site and notify us by phone when something is wrong.

What we did

The solution

  • moved all VPN clients to a new protocol with our own certificate and switched off the old protocol
  • created a standby copy of the VPN server, refreshed every night, which starts automatically when the primary goes down
  • brought the management of all servers into one web console with two-factor authentication
  • set up automatic offsite backup, with a status page for each job and phone alerts
  • added anti-ransomware protection that isolates the machine and stops the backup on suspicious access
How it works

Six parts working together

Each part has its own alert, and every alert reaches the phone.

VPN with a standby server

Network access is only possible over an encrypted connection, with a fixed address for each user.

  • the standby copy is refreshed every night
  • checked every minute, started automatically
  • clients reconnect on their own

Central console

All servers, at all locations, are managed from the browser.

  • two-factor authentication
  • 40 remote desktop connections in 5 groups
  • 15 applications in a single panel

Offsite backup

Each location uploads its data to an external cloud and reports its status.

  • 10 jobs: servers, databases, virtual machines, workstations
  • versions kept for 30 days
  • status page with a “run now” button

Anti‑ransomware protection

On suspicious access, the machine is isolated automatically and the backup stops, so a good copy is not overwritten.

  • alerts by phone, e-mail and WhatsApp
  • drill mode, with no real effect
  • 9 successful drills

Monitoring

Server resources and temperatures, tracked continuously.

  • 8 systems under resource monitoring
  • hardware health report every 30 minutes
  • alerts are acknowledged from the page

Fallback access path

A separate machine, on another physical server, keeps admin access available if the main server goes down.

  • independent of the main server
  • used only for recovery
Problem solved

Failover without overlap

The two copies of the VPN server share the same network identity, so they must never run at the same time. The standby copy starts only after it has been confirmed that the primary is off, including through the physical server's management interface. When the primary restarts, it first checks whether the standby is active.

The nightly export replaces the old copy only after it has been imported and verified, so a broken copy never takes the place of a good one.

Results

What we measured

  • failover test on 31 Oct 2026: about 5.5 minutes of total outage, and 8 clients reconnected automatically, each with its own address
  • 8 VPN clients moved to the new protocol; the old protocol was switched off
  • offsite backup: a 522 GiB virtual machine uploaded in 2 h 13 min, out of 5 TB of external storage
  • in the drills, access was detected in 2.2–2.5 s and alerts reached every channel in 4.2–6.4 s
  • the file cloud received an A grade in a security check
Claude's role

What Claude did on the project

What Claude did

  • works with us directly on the server, over a secure connection, with access limited to our account
  • reads the hardware health report every day and notes what has changed since the previous day
  • uses the browser on the server to check web pages
  • compiled the project's technical sheet from documents and checks on the server

What we did

  • set the rules: any affected machine is isolated immediately and the backup stops
  • decided what goes into the backup and in what form
  • built the fallback access path, on another physical server, for when the main server goes down
  • keep the accounts, the access rights and the final check

The protection and the failover were validated through drills and scheduled tests, with alerts marked as simulations.

Do your servers depend on one person or one machine?

We start with an inventory: what runs where, where the copies are and what happens if a server goes down.

Request an assessment →