Why we still write restore tests by hand
A backup you have never restored is a hypothesis, not a backup.
SCRF Systems looks after Linux servers for teams of five to fifty people. Patching, backups, monitoring and the unglamorous work that keeps a product online — handled on a fixed schedule, documented, and reproducible.
Four areas, one contract. No platform to migrate to, no proprietary agent on your machines.
Debian and Ubuntu fleets provisioned from code, hardened to a written baseline, patched in staged windows.
Nightly incremental snapshots to a second provider, retention up to twelve months, restore drills every quarter.
Uptime, disk, certificate expiry and service checks, routed to email or chat with an on-call rota.
Independent audit of what you run, a written risk list, and help moving between providers without downtime.
Most teams start with a two-week assessment and continue on a monthly retainer.
We inventory hosts, services and data flows, then hand over a written report: what breaks first, what is untested, what costs more than it should.
Backups that restore, alerts that fire, certificates that renew. Everything changes through review, with a rollback path.
Patching, capacity checks, incident response and a short monthly summary. You keep root access and every artefact.
Names omitted by agreement; details available on a call.
Replaced hand-made deployments with a single Ansible baseline and moved backups off the same provider.
Moved four domains to DNS-01, added expiry monitoring and a monthly check that actually runs.
Moved static delivery to object storage and right-sized eight instances that had been sized for a launch that never came.
Short write-ups, roughly once a month.
A backup you have never restored is a hypothesis, not a backup.
Automation fails silently; the calendar reminder is what catches it.
How we schedule reboots around a business that runs 08:00–18:00.
A short description is enough — number of hosts, what sits on them, what worries you.