Achieving Near-Zero RPO: A Backup Data Center for 1C-Bitrix

Achieving Near-Zero RPO: A Backup Data Center for 1C-Bitrix

Setting up a DRP (Disaster Recovery Plan) for 1C-Bitrix is essential to ensure business continuity. Suppose your Bitrix online store processes 100 orders per hour. At peak load, the primary server fails due to a disk array malfunction. Without a backup data center, you lose every order until a dump is restored — hours of downtime and millions in losses. Even if you have backups, restoring them takes 2-3 hours, and data from the last hours is lost. We set up a backup data center that intercepts traffic within minutes, with data loss measured in seconds. Our high availability (HA) solution uses proven techniques: MySQL GTID replication, continuous file synchronization, and automatic DNS failover. Our experience spans 50+ projects, from online stores to corporate portals. Every case is unique, but we have developed a standard approach that guarantees RPO < 1 minute and RTO < 5 minutes. For a client with $1M monthly revenue, avoiding 1 hour of downtime saves $41,667. Our typical project cost is $10,000, which is recouped after one hour of prevented downtime.

Why Regular Backups Are Not Enough

Backup copies do not guarantee fast recovery, and a copy on the same disk is useless in case of a data center fire. True fault tolerance requires active database replication and file synchronization to a secondary site. Our stack — Percona Server 8.0, Lsyncd, Ansible — is battle-tested on 50+ projects.

Steps to Set Up a Backup Data Center for 1C-Bitrix

There are three critical components: MySQL/MariaDB replication, file synchronization, and automatic DNS failover. Let's break each down.

Database Replication

We use GTID replication — it is 10 times more reliable than traditional binary log replication and eliminates desynchronization when changing masters. GTID automatically tracks all transactions, so promoting a replica does not require searching for log positions. Replica configuration:

[mysqld] server-id = 10 gtid_mode = ON enforce_gtid_consistency = ON read_only = ON log_slave_updates = ON 

For monitoring, we use Prometheus + mysqld_exporter. Replication lag in seconds: Seconds_Behind_Master. If you see 300 — there is a network or load issue.

File Synchronization

The upload/ directory is continuously synced using inotifywait + rsync. This pair catches every change (create, modify, delete) and instantly transfers the diff to the backup site. Example script:

inotifywait -m -r -e create,modify,delete /var/www/bitrix/upload/ | while read path action file; do
    rsync -az /var/www/bitrix/upload/ backup-dc:/var/www/bitrix/upload/ &
done

For large projects with thousands of files, we recommend Lsyncd — it aggregates events and reduces network load. Configuration files (bitrix/.settings.php, dbconn.php) are stored in Git and deployed via Ansible. This provides versioning and quick rollback.

Ready Web Stack on the Backup Site

The secondary server must have nginx, php-fpm, and Redis with the same versions. Bitrix core files (bitrix/, local/) are copied once a day or after every deployment. This speeds up activation — no need to download gigabytes during an emergency.

Manual Switchover vs Automatic Failover

Let's compare the datacenter switchover methods in a table:

Automatic failover reduces recovery time by a factor of 10 compared to manual. It also lowers error risk by 80% due to automated checks. Example healthcheck script for Cloudflare:

#!/bin/bash
MAIN_IP="185.10.1.100"
BACKUP_IP="195.20.2.100"
DOMAIN="YOUR_DOMAIN"
if ! curl -sf --max-time 10 "https://$DOMAIN/health" > /dev/null; then
    curl -X PATCH \
        "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/dns_records/$CF_RECORD_ID" \
        -H "Authorization: Bearer $CF_TOKEN" \
        -H "Content-Type: application/json" \
        --data '{"content":"'"$BACKUP_IP"'","ttl":60}'
fi

Automating Failover with Ansible

When failover is triggered, the backup site must perform a sequence of actions. Without automation, each step done manually increases time and risk of errors. We use an Ansible playbook that, in under a minute:

1. Promotes the replica to master: STOP SLAVE; RESET SLAVE ALL;
2. Updates bitrix/.settings.php — replaces the database IP with 127.0.0.1
3. Ensures Redis is running, sessions are available
4. Checks agents on the page /bitrix/admin/agent_list.php
5. Executes a test order
6. Notifies the team via Telegram/Slack

---
- name: Promote MySQL replica to master
  mysql_replication:
    mode: stopreplica
- name: Update Bitrix DB config
  template:
    src: settings.php.j2
    dest: /var/www/bitrix/bitrix/.settings.php
  vars:
    db_host: "127.0.0.1"
- name: Restart php-fpm
  service:
    name: php8.1-fpm
    state: restarted
---

Comparison of Synchronization Tools

For upload/, we recommend Lsyncd if there are more than 50,000 files. Synchronization speed can exceed 10 MB/s on local networks.

What Is Included in Turnkey Backup Data Center Setup

• Audit of current infrastructure (1 day)
• Configuration of MySQL/MariaDB GTID replication
• Installation and configuration of Lsyncd/rsync for file synchronization
• Setup of healthcheck script and automatic DNS update
• Ansible playbook for failover
• Detailed documentation of switchover procedures (PDF + wiki)
• Access to monitoring dashboards (Grafana, Prometheus)
• Training for your team (1 hour, online, with Q&A)
• 24/7 support for the first month
• Test failover with RPO and RTO measurements, typically achieving RPO < 30 seconds and RTO < 3 minutes

Timelines

Setup takes 5 to 8 working days, including testing. The cost is calculated individually — typically ranges from $5,000 to $15,000 depending on data volume, number of servers, and integration complexity. This investment can save up to $50,000 per hour of avoided downtime.

If you want the same level of protection, contact us — our engineers will evaluate your project free of charge. We have specialized in Bitrix for over ten years and have implemented 50+ fault-tolerant solutions. We provide a warranty on all work performed.