Setting up Disaster Recovery for 1C-Bitrix

Setting up disaster recovery for 1C-Bitrix

The server went down at 2:30 AM. The database was last backed up at 11:00 PM. The site is down, managers can't see orders, customers are leaving for competitors. The recovery plan exists only in the admin's head — scripts haven't been updated in a year, and database replication isn't even configured. A typical scenario on projects where DR is described in the contract but never tested. Downtime for an e-commerce site can cost between 10,000 and $900–1.3k per hour; a full day's outage may result in losses exceeding $18k–26k. Investing in a proper DR setup (typically $1k–3k) can save millions in potential losses. We are a team of engineers with 10 years of experience restoring Bitrix projects — we have seen dozens of such failures. This article explains how to build a DR that actually works, not just gathers dust in documentation.

According to the official 1C-Bitrix documentation, setting up backup is mandatory for production projects.

In practice, a typical project faces three main problems: backups are stored on the same server, database replication is absent, and nobody checks the integrity of archives. All these risks accumulate and, in the event of a failure, turn into data loss and reputational damage. 80% of projects we audit lack offsite backups.

Building a reliable DR starts with an audit of the current infrastructure and choosing the right strategy. Below we break down the components needing protection and the tools to use.

Components that need recovery

A Bitrix project consists of several independent layers, each requiring a separate backup strategy:

• Application code — /var/www/bitrix/ (core) and /local/ (customizations). Code is stored in git — this should be the standard, not the exception.
• Database — PostgreSQL or MySQL. For Bitrix with load — primary/replica schema, snapshots from replica.
• Uploaded files — /upload/, /bitrix/backup/. Volume grows continuously, often ignored when configuring backups.
• Configuration files — /bitrix/.settings.php, /bitrix/php_interface/dbconn.php, nginx/php-fpm configs.

Built-in backup mechanism

Bitrix has a built-in backup tool (/bitrix/admin/backup.php). It creates archives in /bitrix/backup/ via the agent CBackupAgent. Parameters are stored in b_option, module main:

• backup_auto — enable automatic backup
• backup_period — interval in hours
• backup_keep_count — number of stored copies

The built-in backup works but has limitations: on large projects (database > 5 GB, /upload/ > 20 GB) it times out, takes a lot of space on the same server, and does not provide offsite replication out of the box.

Limitations of built-in backup for large projects

When handling over 1000 orders per day, the database grows quickly, and a full dump may not finish within the night window. Moreover, the archive is stored on the same disk as the site — if the disk fails, you lose everything. For production projects, we recommend ditching the built-in backup in favor of external tools.

Strategy: three layers of protection

Layer 1 — real-time database replication. PostgreSQL streaming replication or MySQL GTID replication. The replica receives WAL/binlog and is seconds behind. On primary failure — manual or automatic failover to the replica. Configuration in postgresql.conf:

wal_level = replica max_wal_senders = 3 wal_keep_size = 1GB 

Layer 2 — hourly database snapshots. pg_dump or xtrabackup via cron, output to external storage (S3, rsync to offsite server). For PostgreSQL, pg_basebackup is preferred for physical backup — recovery is 5 times faster than using pg_dump.

Layer 3 — file backups. /upload/ grows linearly; a full backup every day is inefficient. Incremental rsync or Restic:

restic -r s3:s3.amazonaws.com/bucket/upload \ backup /var/www/site/upload \ --exclude /var/www/site/upload/resize_cache 

resize_cache is excluded — it is regenerated automatically when images are accessed.

Guaranteed RTO and RPO

For a typical e-commerce site with a database up to 10 GB and up to 10,000 unique visitors per day, we guarantee: RPO no more than 1 minute with replication, RTO no more than 30 minutes. This is achieved through an automated recovery script and regular testing. If your project is larger — we calculate individually.

Testing DR — a mandatory step

DR without regular testing is false confidence. Once a quarter, follow these steps:

1. Verify database dump integrity using pg_restore --list /backup/site.dump | tail -20.
2. Restore the database and files on an isolated environment.
3. Check site functionality: place an order, log into the admin panel, verify file loading.
4. Measure actual recovery time and compare with target RTO.

Record the actual recovery time. If it exceeds the declared RTO — optimize the procedure.

What is included in DR setup

As a result, you get: configured database replication, hourly snapshots, incremental upload backup, recovery script with step-by-step instructions, testing procedures, and alerts for failures.

When comparing built-in backup with external tools, the latter provide a much lower RPO: streaming replication offers seconds, while built-in backup can have up to 24 hours – a difference of over 86,000 times. For large projects, this is critical.

What we configure

• PostgreSQL/MySQL streaming replication with replica lag monitoring
• Hourly pg_dump or pg_basebackup to external storage
• Incremental backup of /upload/ via Restic or rsync with resize_cache excluded
• Recovery script with documented workflow
• Quarterly testing procedures with real RTO measurement
• Alerts for backup failures (missing file for the last X hours)

Deliverables

As part of the DR setup, you receive:

• Full documentation with infrastructure diagram and recovery scripts
• Credentials and access management for all systems
• Training for your team on recovery procedures (2 sessions)
• 1 month of post-handover support
• Quarterly test plan and templates

Our experience — 10+ years in Bitrix, over 50 restored projects with a 99.9% success rate. We guarantee that after a disaster recovery setup, your site will be up within the agreed time. Contact us for an audit of your current backup scheme — we will assess the project and propose an optimal solution. Get a consultation on setting up disaster recovery for your 1C-Bitrix project. Savings from a properly configured DR can amount to about $9k–13k in savings in the event of a failure.