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:
- Verify database dump integrity using
pg_restore --list /backup/site.dump | tail -20.
- Restore the database and files on an isolated environment.
- Check site functionality: place an order, log into the admin panel, verify file loading.
- 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 plan
Every 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
-
Performance Monitor (
/bitrix/admin/perfmon_panel.php) — aim for 30+ points. Below 20 means serious configuration issues.
- System Check — automatic check of all parameters. Red items must be fixed, yellow — case by case.
- Security Scanner — check for typical vulnerabilities.
- PageSpeed Insights — TTFB < 200ms on VPS, LCP < 2.5s.
- 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.