RTO/RPO for 1C-Bitrix: From Interview to Runbook
When business says, "the site shouldn't be down for more than an hour," we understand—that's an RTO question. And we are responsible for formalizing agreements with the business and technically ensuring them. Six months later, it turns out restoration from the last backup takes 4 hours, and the business didn't know. RTO and RPO are not technical characteristics; they are agreements that need to be formalized and technically enforced. As certified 1C-Bitrix specialists with over 10 years of experience, we guarantee your target metrics will be achieved with the right approach.
A typical scenario: for an e-commerce store with a daily turnover of $9k–13k (approximately $11,000), each hour of downtime costs $360–520 ($450). Reducing RTO from 4 hours to 10 minutes can save up to $1.4k–1.9k ($1,700) per incident. Such numbers motivate businesses to invest in reliability.
What Are RTO and RPO for Bitrix?
RPO (Recovery Point Objective) is the maximum acceptable data loss. If RPO = 1 hour, then in a disaster you can lose no more than an hour of transactions: orders, registrations, stock changes.
RTO (Recovery Time Objective) is the maximum acceptable downtime. If RTO = 30 minutes, the site must be operational within 30 minutes after an incident.
Typical values for an e-commerce store on Bitrix: RPO = 1 hour, RTO = 2 hours. For high-load projects: RPO = 5 minutes, RTO = 15 minutes. The stricter the requirements, the more expensive the infrastructure.
Aligning RTO and RPO with Business
A common mistake is engineers setting technical parameters without consulting the business. This can lead to unjustified infrastructure costs or, conversely, business losses due to long downtimes. We always start with a client interview: how much do you lose per hour of downtime? What data is critical? Only then do we choose the architecture.
How to Calculate Real RTO?
Recovery time is the sum of all steps, not just "restore the database":
- Incident detection — 0 to 15 minutes (depends on monitoring)
- Decision to failover — 5–10 minutes
- Database recovery/promotion — depends on the RPO solution
- Application configuration change — 2–5 minutes
- Cache warming — first requests after recovery are slow, Redis/memcached empty
- Health check — 5–10 minutes
The "cache warming" step is often ignored in RTO calculations. After recovery, the database receives load from scratch: Bitrix cache is empty, OPcache cold. The first 5–10 minutes of operation are peak database load. Without rate limiting, this can bring down the newly restored server. ITIL recommends including detection time in RTO calculation.
Technical Solutions for Different RPO Levels
RPO = several hours. Hourly pg_dump to external storage is sufficient. Simple, cheap, but recovery is slow for large databases.
RPO = minutes. Streaming replication PostgreSQL with synchronous mode (synchronous_commit = on). Each transaction is confirmed only after being written to the replica. Additional latency: +5–15 ms per transaction. More in PostgreSQL documentation.
RPO = seconds. Patroni with synchronous replication plus continuous WAL archiving via archive_command to S3. With WAL archiving, you can restore the database to any point in time (PITR).
# postgresql.conf for PITR archive_mode = on archive_command = 'aws s3 cp %p s3://backup-bucket/wal/%f' Technical Solutions for Different RTO Levels
RTO = several hours. Restore from pg_dump plus deploy code from git. Linearly depends on database size: 10 GB — approximately 45–90 minutes restoration.
RTO = 30–60 minutes. Standby server with hot replica. On incident — manual failover: promote replica, change DNS or app config. Not automatic, but fast.
RTO = less than 10 minutes. Automatic failover via Patroni + HAProxy. No human intervention. Requires initial setup and regular testing.
Which Recovery Method for Your Project?
Choice depends on budget and data criticality. Compare the main options:
| Method | Typical RPO | Typical RTO | Complexity |
|---|---|---|---|
| pg_dump | 1 hour | 2–4 hours | Low |
| Streaming replication | 1 min | 1 hour | Medium |
| Patroni + WAL | 1 sec | 10 min | High |
Patroni with PITR delivers RTO 6 times faster than restoring from pg_dump.
Decision Matrix for Bitrix
| Project Size | RPO | RTO | Infrastructure |
|---|---|---|---|
| Up to 5k orders/day | 1 hour | 4 hours | pg_dump to S3, deploy from git |
| 5–50k orders/day | 15 min | 1 hour | Streaming replica + manual failover |
| Over 50k orders/day | 1 min | 10 min | Patroni + HAProxy + WAL archiving |
Documentation and Testing
RTO/RPO without a documented runbook is worthless. The runbook must contain the exact command sequence for each failure scenario: primary database failure, web server failure, loss of /upload/, server compromise.
# Example runbook section: PostgreSQL failover (manual) # 1. Check that primary is unavailable pg_isready -h primary.db -p 5432 # 2. Promote replica ssh replica.db 'pg_ctl promote -D /var/lib/postgresql/data' # 3. Update Bitrix config sed -i "s/primary.db/replica.db/" /var/www/bitrix/.settings.php # 4. Clear cache php /var/www/bitrix/bitrix/modules/main/cli/cache_clear.php Example runbook for web server failover
On web server failure: switch balancer to backup server, check sessions, restart PHP-FPM.What's Included in RTO/RPO Setup?
- Audit of current infrastructure and business interview to formalize RPO/RTO
- Selection and configuration of the solution (pg_dump, streaming replication, Patroni)
- Setup of WAL archiving for PITR if needed
- Creation of a detailed runbook with recovery commands
- Testing plan and operational documentation
- Knowledge transfer to the client's team (1–2 sessions)
We assess your project in two days. Contact us for a consultation—we'll choose a turnkey solution. Over 50 projects with critical availability requirements—our experience speaks for itself. We guarantee transparent calculations and an operational scheme. Order an audit of your current recovery plan.