Setting up a backup data center for 1C-Bitrix

Setting Up a Backup Data Center for 1C-Bitrix

If the primary server becomes unavailable, the backup DC must accept traffic without manual intervention and without data loss. In practice, most "backup DCs" are servers with an outdated backup that someone switches to manually an hour after an incident. A properly functioning backup DC for Bitrix means a replicated database, a file mirror, and automatic DNS failover.

Backup DC Components

1. Database Replication

A MySQL/MariaDB replica in the backup DC is mandatory. It is configured via standard binlog replication or GTID:

# On the backup replica
[mysqld]
server-id = 10
gtid_mode = ON
enforce_gtid_consistency = ON
read_only = ON
log_slave_updates = ON  # required if the replica will become the master

Monitoring replication lag is the key metric for evaluating RPO:

SHOW SLAVE STATUS\G
-- Seconds_Behind_Master: 2  -- acceptable
-- Seconds_Behind_Master: 300 -- problem, investigation required

2. File Synchronization

The upload/ directory is synchronized via rsync on a schedule or continuously via inotifywait:

# Continuous synchronization via inotify
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

Configuration files (/bitrix/.settings.php, dbconn.php) — via Git or a separate rsync script triggered on each change.

3. Ready Web Stack at the Backup Site

The backup server must have an installed and configured stack (nginx, php-fpm, redis) with a correct configuration. Bitrix files (/bitrix/, /local/) — synchronized once daily or from the latest deployment.

Switchover: Manual vs Automatic

Manual switchover — an operator updates the DNS A record after confirming the incident. Minimum TTL for fast switching — 60–300 seconds.

Automatic (failover) — a healthcheck on the primary DC; if it becomes unavailable, a script updates DNS via API:

#!/bin/bash
# healthcheck.sh — runs every minute via cron
MAIN_IP="185.10.1.100"
BACKUP_IP="195.20.2.100"
DOMAIN="your-site.ru"

if ! curl -sf --max-time 10 "https://$DOMAIN/health" > /dev/null; then
    # Switch DNS via Cloudflare API
    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}'

    # Notify the team
    curl -s "https://api.telegram.org/bot$TG_TOKEN/sendMessage" \
        -d "chat_id=$TG_CHAT&text=FAILOVER+ACTIVATED:+switched+to+backup+DC"
fi

Backup DC Activation Checklist

When failover is triggered, the following must be done at the backup site:

1. Promote the replica to master: STOP SLAVE; RESET SLAVE ALL;
2. Update /bitrix/.settings.php — replace the master DB IP with the local one
3. Verify that Redis is running and sessions are accessible
4. Check 1C-Bitrix cron jobs (agents): /bitrix/admin/agent_list.php
5. Run a test transaction in the store
6. Notify the support team about the change in order processing endpoint

Steps 1–3 are automated via an Ansible playbook:

# failover.yml
- 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"  # local master at the backup site

- name: Restart php-fpm
  service:
    name: php8.1-fpm
    state: restarted

Setup Timeline

Setting up a backup DC with DB replication, file synchronization, and automatic DNS failover — including switchover testing — takes 5–8 business days.