Setting up Disaster Recovery for 1C-Bitrix

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Showing 1 of 1All 1626 services
Setting up Disaster Recovery for 1C-Bitrix
Simple
~1 day
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1358
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Website development for FIXPER company
    947
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    694
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    830
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    732
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    1075

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 100,000 rubles per hour; a full day's outage may result in losses exceeding 2 million rubles. Investing in a proper DR setup (typically 100,000 to 300,000 rubles) 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 Technology RPO RTO
1 — replication PostgreSQL streaming replication / MySQL GTID seconds minutes
2 — snapshots pg_dump / pg_basebackup / xtrabackup up to 1 hour 15–30 min
3 — file backup Restic / rsync (incremental) up to 24 hours up to 1 hour

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

Stage Duration Result
Audit of current infrastructure 2–3 days Report with risks and recommendations
Design of DR scheme 1 day Architecture document
Configuration of replication and backups 3–5 days Working scripts and monitoring
Recovery testing 1 day Protocol with RTO/RPO measurements
Documentation handover 1 day Procedures, scripts, credentials

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
Sample DR test planEvery quarter, perform a full restoration on an isolated environment. Check: database integrity, operation of all modules, correct file loading. Record actual recovery time and compare with target RTO.

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 millions of rubles in the event of a failure.

What Professional 1C-Bitrix Installation Includes

We start by checking innodb_buffer_pool_size. The default MySQL value (128 MB) is a death sentence for an online store with a catalog of 10,000+ items. We set 70–80% of available RAM on a dedicated server, 50% on VPS. This single setting speeds up the site by 2–3 times compared to the default. We'll assess your project in one day — get a consultation. Contact us to order turnkey installation with performance guarantee.

How to Choose Hosting and Edition for 1C-Bitrix Installation?

BitrixVM is a virtual machine with a pre-installed stack: nginx + Apache, PHP-FPM, MySQL/MariaDB, Sphinx, Push server. For VPS — the best start. Everything is already configured for Bitrix, including OPcache, log rotation, and firewall. Management via web panel on port 8890. Bitrix documentation recommends starting with BitrixVM for predictable performance.

VPS/VDS is the sweet spot. Minimum configuration for a medium online store: 2 vCPU, 4 GB RAM, SSD. Optimal: 4 vCPU, 8 GB RAM. OS: Ubuntu 22.04 or Debian 12. If not BitrixVM, we configure the stack manually for the task. Virtual hosting — only for business cards and landing pages. Requirements: PHP 8.0+, MySQL 5.7+ / MariaDB 10.0+, 512 MB RAM, .htaccess. 1C-Bitrix hosting partners guarantee compatibility. Dedicated server — for highload. Typical architecture: web server separate, database separate, Redis/Memcached separate. For Enterprise edition — web cluster with load balancer. Cloud (Yandex Cloud, VK Cloud, Selectel) — when load spikes: sales, seasonal peaks. Autoscaling via Managed Kubernetes or simple VM vertical scaling.

Choosing the edition is equally important. A common mistake: choosing "Small Business" for a store that grows to B2B with wholesale prices and three warehouses in six months. Upgrading to "Business" — pay the difference, data is not lost, but it's better to plan ahead. Our specialists select the edition for current tasks and with room for growth. For example, the "Business" license (about 35,000 RUB) pays off through multi-warehouse and 1C exchange, while the wrong choice can lead to a loss of up to 30,000 RUB monthly on excess resources.

Edition For Whom Key Limitation
Start Business cards, landing pages No infoblocks 2.0, no trade catalog
Standard Corporate sites No e-commerce module
Small Business Small stores 1 price type, 1 warehouse, no 1C exchange
Business Medium stores, B2B Multi-warehouse, multicurrency, CommerceML
Enterprise Highload, cluster Web cluster, CDN, multisite

What Server Settings Are Critical for 1C-Bitrix?

Web Server and PHP

nginx as reverse proxy + Apache (mod_php) or nginx + PHP-FPM directly. The second option saves memory — Apache is not needed. But some Bitrix modules use .htaccess, so for compatibility we sometimes keep Apache. nginx configuration: fastcgi_read_timeout 300 — for long operations (1C import), client_max_body_size 1024m — large file uploads. Block access to .settings.php, .settings_extra.php, bitrix/.settings.php — they contain database passwords. Rewrite rules from urlrewrite.php — Bitrix generates them, but with nginx + PHP-FPM they need to be duplicated. PHP 8.0–8.2 with extensions: mbstring, curl, gd, xml, json, opcache, redis/memcached. Key php.ini settings: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, max_execution_time=300, memory_limit=512M, upload_max_filesize=100M, post_max_size=128M.

Database and Caching

MySQL/MariaDB. Key my.cnf parameters: innodb_buffer_pool_size — 70–80% RAM, innodb_log_file_size=256M, tmp_table_size=256M, max_heap_table_size=256M, thread_pool_size — number of CPU cores. Encoding utf8mb4 mandatory, otherwise emoji and special characters break. Redis is preferable to Memcached for Bitrix — supports persistent connections and is more reliable. In production, Redis handles concurrent writes three times faster than Memcached under typical load. Configure in .settings_extra.php:

'cache' => ['value' => ['type' => ['class_name' => '\\Bitrix\\Main\\Data\\CacheEngineRedis']]]
'session' => ['value' => ['mode' => 'default', 'handlers' => ['general' => ['type' => 'redis']]]]
Example Redis configuration for Bitrix
sudo apt install redis-server
sudo systemctl enable redis

Add to .settings_extra.php as above.

SSL, Email, and Cron

SSL — Let's Encrypt via certbot in 90% of cases. Redirect HTTP → HTTPS (301), HSTS, TLS 1.2/1.3, OCSP Stapling. In Bitrix, switch to HTTPS in the main module settings. Email: abandon mail() — connect SMTP (Yandex.Mail for domain, Mail.ru for Business). Be sure to configure SPF, DKIM, DMARC. Without SPF, emails go to spam. Test deliverability via mail-tester.com — score 9+/10. Cron: Bitrix agents switch to system cron — * * * * * /usr/bin/php /var/www/bitrix/modules/main/tools/cron_events.php. Schedule 1C exchange (15–60 min), search reindex, backups (mysqldump + rsync, rotation 7+4), temporary file cleanup.

Security and Administration

File system: owner www-data, directories 755, files 644, upload 775. nginx blocks access to configuration files. Enable Bitrix Proactive Protection — WAF, activity control (block after 5 failed attempts), kernel integrity check. For admin panel: two-factor authentication via Google Authenticator or OTP, restrict access by IP via nginx for paranoid.

How Long Does 1C-Bitrix Installation and Configuration Take?

Task Timeline
Installation on virtual hosting 2–4 hours
Installation on VPS with stack configuration 1–2 days
Installation on dedicated with architecture design 2–5 days
SSL + email + cron + security 1–2 days
Backup and monitoring setup 0.5–1 day

Post-Installation Checklist

  1. Performance Monitor (/bitrix/admin/perfmon_panel.php) — aim for 30+ points. Below 20 means serious configuration issues.
  2. System Check — automatic check of all parameters. Red items must be fixed, yellow — case by case.
  3. Security Scanner — check for typical vulnerabilities.
  4. PageSpeed Insights — TTFB < 200ms on VPS, LCP < 2.5s.
  5. Test 1C exchange — if integration is planned, verify CommerceML exchange before launch.

Additionally, check software versions, caching settings, cron operation, SSL certificate, SPF/DKIM/DMARC, access rights, delete default users and pages. For projects with 54-FZ, ensure fiscalization is configured via OFD provider.

Deliverables

  • Fully configured server for 1C-Bitrix with MySQL, PHP, nginx optimization.
  • Installed and activated license of the required edition.
  • SSL certificate, email settings, cron and backups.
  • Documentation: all configuration parameters, access credentials, cron tasks.
  • Content manager training: how to log into admin panel, add products, upload images.
  • Post-installation support for 30 days — consultations on settings.

Why Trust Professionals with Installation?

Incorrect installation means lost time and money. We've seen projects where a store on "Start" couldn't handle 50 visitors because innodb_buffer_pool_size wasn't configured. After migrating to VPS with correct configuration, the site "flew". Incorrect configuration can cost 30,000 RUB monthly due to excessive resource consumption. You get a ready-made architecture that scales. Order turnkey 1C-Bitrix installation — get a reliable platform for business growth. Contact us for a free consultation: we'll calculate the cost and time for your project. Over 7 years of experience, 120+ Bitrix projects implemented, including highload stores with million-item catalogs. Get in touch — we'll help configure Bitrix for your project.