Skip to content

Backup and disaster recovery

A backup is only real once you've restored from it. We agree recovery targets with you, build backups and failover around them, and prove them with scheduled restore drills.

An engineer replies, not a salesperson — within one business day.

  • RPO and RTO per system
  • Off-site and cross-cloud copies
  • Restore drills with written results
  • Co-founders do the work

Official cloud partners

  • Yandex Cloud
  • Selectel
  • Timeweb Cloud
among our clients
  • Novotek
  • RZD
  • SberCorus
  • Otus
  • Besttrip
  • JedAI
  • IMSystems
  • Builddocs
  • Headframe
  • RTDS
Case studies →
symptoms.log

When teams come to us

Backups nobody has restored

Jobs run every night, but nobody has done a full restore in the last year.

Unknown recovery time

Nobody can say how much data you'd lose or how long you'd be down.

A DR plan from three architectures ago

The document exists, but it describes a system you no longer run.

Customers ask for evidence

Auditors or enterprise customers want DR evidence you don't have.

scope.md

What we do

Recovery targets

RPO and RTO per system, based on what an hour of downtime or lost data actually costs.

Backup design

Databases, object storage, Kubernetes state and configuration — nothing important left out.

Off-site and immutable copies

Copies in another region, account or cloud, with separate credentials, so one compromise or outage can't destroy them all.

DR architecture

Pilot light, warm standby or active-active — chosen per system, not one size for everything.

Restore drills

Scheduled drills with measured recovery times and written results.

Runbooks

Step-by-step recovery procedures, wired into on-call.

What you keep

  • RPO/RTO matrix per workload
  • Backup and DR implementation as code
  • Recovery runbooks
  • Drill reports with measured recovery times

Stack

  • Velero
  • PostgreSQL
  • Object storage
  • Terraform
  • Kubernetes
git log --cases

Similar problems we have solved

All case studies
Industrial

Novotek

Infrastructure had grown ad hoc: configuration lived on the servers, and changes could not be tracked or reproduced.

  • Described the infrastructure as code, so it is reproducible and goes through review
  • Separated development, testing and production environments
  • Introduced monitoring and an incident response procedure
Transportation

RZD

Strict continuity requirements: services cannot be stopped, and problems must be visible before users notice them.

  • Rebuilt the setup for fault tolerance with no single points of failure
  • Set up metrics, logs and meaningful SLI/SLO-based alerts
  • Organized on-call rotations and incident reviews
Construction document management

Builddocs

The system ran on its own hardware; maintenance was getting more expensive and capacity was running out.

  • Planned and executed a cloud migration with a rollback plan at every step
  • Set up backups with regular restore testing
  • Built deployment pipelines on the new platform

TEAM.md

Who will work on your project

There are three of us, by design: the engineers you talk to are the engineers who do the work. No account managers, no hand-offs.

  • Alexander Kaloshin — Co-founder

    Alexander Kaloshin

    Co-founder

    20+ years in IT. In 2014 he founded Last.Backend, a container orchestrator built at almost the same time as Kubernetes. Leads our AI practice.

    • Last.Backend: container management and DevOps as a service
    • Fault-tolerant infrastructure: Kubernetes, CI/CD, bare metal
    • Go engineering
    • Speaker at ProIT Fest and GolangConf
  • Alexander Tikhomirov — Co-founder

    Alexander Tikhomirov

    Co-founder

    7 years in DevOps and dozens of delivered projects, from a first pipeline to production under heavy load.

    • Infrastructure design and operations
    • Cloud migrations and greenfield builds
    • CI/CD, Kubernetes, infrastructure as code
  • Denis Gerasimov — Co-founder

    Denis Gerasimov

    Co-founder

    5 years in DevOps. Takes on the hardest problems and sees them through.

    • Complex infrastructure projects
    • Monitoring, on-call and incident response
    • Operations automation
FAQ.md

FAQ

What's the difference between backup and disaster recovery?
A backup is a copy of your data. Disaster recovery is the tested procedure, and the infrastructure, to get your service running again from that copy within an agreed time.
How often should we test?
At least once a year for everything and quarterly for critical systems. We can run the drills for you and give you the report.
Will this touch production?
The assessment is read-only. Implementation changes are reviewed, applied through code and scheduled with you.
Can backups live in a different cloud?
Yes. Cross-cloud or on-premises copies protect against a provider- or account-level failure.
Can you help with ransomware resilience?
Yes — immutable, isolated copies with separate credentials, and restores tested from them.

Let's talk about your infrastructure

Tell us what is going on today. We reply within one business day with a free initial review.