RTO / RPO definition

RTO/RPO definition is the joint working-out of two key recovery targets: RTO (Recovery Time Objective) — the maximum acceptable downtime within which you must return to work; RPO (Recovery Point Objective) — the maximum acceptable amount of data loss (how far 'back' you are willing to lose data on a failure). We analyze the criticality of your systems and data, calculate the cost of downtime and loss, and formulate realistic targets by segment (for example, orders — almost zero loss, while cache — does not matter). Honestly about the essence, this is key: this is PLANNING of targets, NOT their achievement. Defining 'we recover within 1 hour, lose at most 5 minutes of data' is half the job; to actually achieve it, you need the corresponding setup of backups, replication and infrastructure — that is separate work (backup strategy and DR — 770). A figure by itself without implementation is an intention, not a guarantee. Honestly about money, this matters: targets cost money. The more aggressive the RTO/RPO (closer to zero), the more expensive: near-zero RPO requires continuous replication, RTO in minutes — a hot standby. We will honestly show the 'target ↔ cost' link so you choose a reasonable balance, not maximalism for the sake of figures. Honestly about responsibility: the final values are a business decision (how much downtime/loss is acceptable specifically for you), we help make it well-grounded but do not decide for you. Honestly about access: information about systems, data and processes is needed. An important boundary: this is the definition of targets (planning), while the implementation of backups/DR for them is 770; availability mirrors are 769. Picture this: instead of 'on a failure we recover however we can and lose an unclear amount' — there are clear, budget-aligned targets around which data protection is built. The base price starts from 15,000 ₽; it depends on the number of systems.

• It is unclear within what time the business must recover after a failure.
• It is unclear how much data is acceptable to lose — and no one has decided.
• Backups are made at random, without a link to business goals.
• No link between 'how fast/how much loss ↔ how much it costs'.

• Analysis of system and data criticality by segment
• Estimation of the cost of downtime and data loss
• Formulating realistic RTO and RPO targets
• The 'target ↔ implementation cost' link (without maximalism)
• Segmentation (where near-zero loss is needed, where not)
• Indicating boundaries (planning, not implementation)
• Handing over the targets as the basis for a backup strategy (770)
• Review and agreement with you

• Clear, deliberate targets for recovery time and data loss
• The price of each reliability level is clear
• A basis for a proper backup and DR strategy
• Business-aligned targets (their implementation — separate)

• We analyze systems, data, the cost of downtime; collect information
• We formulate RTO/RPO by segment, show the link with costs
• We agree the targets as the basis for a backup strategy (770)

• After this, will my data definitely recover within the RTO?

  Not automatically. Defining RTO/RPO is agreeing on targets (within how long to recover and how much loss is acceptable). To actually achieve them, you need backups, replication and infrastructure set up for those figures — that is separate work (770). A target without implementation is an intention, not a guarantee; we honestly separate these two stages.

• Why not just set RPO = 0 and RTO = 0?

  Because it is very expensive. Near-zero RPO requires continuous data replication, RTO in minutes — a hot standby always at the ready. We will honestly show the 'target ↔ cost' link and help choose a reasonable balance by segment: somewhere near-zero loss is justified (orders/payments), and somewhere it is excessive.

• Who decides the final figures?

  It is a business decision — how much downtime and loss is acceptable specifically for you. We analyze criticality, calculate the cost and propose well-grounded values, but ultimately you decide deliberately. This is more honest: the targets should reflect your risk and budget, not our template.