On-Premise Bitrix24: Backup & Disaster Recovery Strategy

Why On-Premise Bitrix24 Demands a Serious DR Plan

Self-hosted Bitrix24 has no cloud safety net, meaning a single ransomware attack, database corruption, or failed OS upgrade can simultaneously take down your CRM, telephony, tasks, and communications — making a written backup and DR strategy the difference between a two-hour restore and a two-week disaster.

When you run Bitrix24 on your own infrastructure, there is no cloud safety net. A failed OS upgrade, a corrupted database, or a ransomware event can take your CRM, tasks, telephony, and internal communications offline — together. Based on our implementation work, the most common causes of data loss or prolonged downtime on self-hosted portals are:

• Unplanned OS or module upgrades applied directly to the production server without a staging copy
• Database corruption — even a medium-sized portal can carry a 25–30 GB MySQL database, and InnoDB errors can cascade quickly
• Security incidents — portals running outdated web environments accumulate vulnerabilities that are actively exploited
• Hardware or VPS failure with no off-site copy of the data

A written backup and DR strategy is the difference between a two-hour restore and a two-week disaster.

---

What Exactly Needs to Be Backed Up

A complete Bitrix24 on-premise backup requires three distinct components — the MySQL/MariaDB database, all application files under /home/bitrix/www/, and server configuration files — because missing any single one of them makes a full restore impossible.

A complete Bitrix24 on-premise backup has three distinct components. Missing any one of them makes a full restore impossible.

Component	Typical location	Notes
MySQL / MariaDB database	sitemanager (or sitemanager0) schema	Contains all CRM data, tasks, users, business-process state
Application files	/home/bitrix/www/	Includes /bitrix/, /local/, uploads, custom components
Server configuration	/etc/nginx/, /etc/php.ini, /etc/my.cnf, cron entries	Required to rebuild the environment exactly

Custom code note. Projects that have modified core Bitrix24 files (which our security audits occasionally reveal — typically a small percentage of the total file count, but in critical modules such as CRM and IM) need those modified files captured separately and documented. Otherwise an update will silently overwrite them.

Additionally, back up: - SSL certificate files (or the Let's Encrypt renewal configuration) - SMTP relay credentials and /home/bitrix/msmtp*.conf files - Any cron jobs under the bitrix user (/usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php)

---

Setting RPO and RTO Targets

For a mid-sized self-hosted Bitrix24 portal running CRM plus telephony plus tasks, the recommended RPO is 1–2 hours and RTO is 2 hours, requiring incremental or transaction-log-level database backups rather than nightly full dumps alone.

Before choosing a backup frequency, define two numbers:

• RPO (Recovery Point Objective) — how much data loss is acceptable. For an active CRM with sales calls, leads, and deal updates happening all day, an RPO of more than a few hours is usually unacceptable.
• RTO (Recovery Time Objective) — how long the business can function without the portal. For companies that run telephony, task management, and client communication through Bitrix24, even a half-day outage has measurable revenue impact.

Typical targets for a mid-sized self-hosted portal:

Scenario	Recommended RPO	Recommended RTO
CRM-only use	4–8 hours	4 hours
CRM + telephony + tasks	1–2 hours	2 hours
CRM + ERP integration (e.g., 1C)	30–60 minutes	1 hour

Hitting a 1-hour RPO requires incremental or transaction-log-level database backups, not just nightly full dumps.

---

Backup Architecture: Three Copies, Two Locations

The industry-standard 3-2-1 rule requires 3 copies of data across 2 locations with 1 off-site or air-gapped copy — implemented for Bitrix24 as a local backup for fast restores, a remote S3/NFS copy for server-level failures, and a weekly cold copy for ransomware or datacenter events.

The industry-standard 3-2-1 rule applies directly here:

• 3 copies of the data
• 2 different storage media or locations
• 1 off-site or air-gapped copy

The diagram below shows a practical setup for a self-hosted Bitrix24 portal. A scheduled backup job produces a full snapshot (database dump + file archive + config files) stored locally, then synced to a separate backup server or object storage (S3-compatible), with a periodic copy to cold/off-site storage.

flowchart LR
    PROD[Production Server\nBitrix24 + MySQL]
    LOCAL[Local Backup\nSame datacenter]
    REMOTE[Remote Backup\nS3 / NFS / second VPS]
    OFFSITE[Off-site / Cold Copy\nRotated weekly]

    PROD -- "nightly full\n+ hourly DB dump" --> LOCAL
    LOCAL -- "daily sync" --> REMOTE
    REMOTE -- "weekly rotation" --> OFFSITE

In practice, the local backup handles fast restores (minutes), the remote copy handles server-level failures, and the off-site copy handles datacenter or ransomware events.

---

Bitrix24 Built-In Backup vs. OS-Level Backup

Bitrix24's built-in admin-panel backup is convenient but writes to the same server disk by default, sharing the production failure domain; for portals with databases above 15–20 GB, OS-level scripted backups using Percona XtraBackup or mariabackup are required for reliable, non-locking DR coverage.

Bitrix24 ships with a built-in backup module accessible from the admin panel. During initial server deployment, this is typically configured to write backups to the same server that hosts the portal. That satisfies the "have a backup" checkbox — but it does not satisfy a real DR requirement, because the backup and the production data share the same disk and the same failure domain.

Built-in Bitrix24 backup (admin panel): - Convenient, no SSH required - Covers files and database in a single archive - Default destination is the local server — must be redirected or supplemented

OS-level / scripted backup: - Full control over frequency, compression, retention - Can run mysqldump or xtrabackup (for large databases) on a schedule - Allows shipping encrypted archives to remote storage automatically - Captures config files the built-in tool ignores

For portals with databases above ~15–20 GB, mysqldump becomes slow. Percona XtraBackup (or mariabackup) supports hot physical backups without locking tables — important for portals that run 24/7.

---

The Pre-Upgrade Backup Protocol

Every Bitrix24 module or core update must be preceded by a full database dump, file archive, config snapshot, and a validated staging deployment — a cycle that adds roughly half a working day but costs far less than a recovery operation from a failed production update.

One scenario our project teams execute on every module or core update is a full pre-change backup. The documented sequence is:

1. Full database dump — capture the current state of sitemanager
2. Full file archive — tar/gz of /home/bitrix/www/
3. Config snapshot — copy of nginx, PHP, MySQL config files
4. Deploy a staging copy — spin up the backup on a separate server and validate it boots correctly
5. Run the update on staging first — test all critical functions (CRM records, task sync, integrations, business processes, custom menu items)
6. Apply to production — only after staging confirms no regressions

This sequence is non-negotiable when the portal has custom code in /local/ or modified core files, because module updates will overwrite changes in /bitrix/php_interface/ — which is why custom code should be migrated to /local/ before updates are applied.

For reference: in a typical project, the full backup-and-stage cycle adds roughly half a working day to any significant update. It is far cheaper than a recovery operation.

---

Security Hardening That Protects Your Backups

A backup is worthless if ransomware reaches it alongside production data, so effective protection requires IP-whitelisted admin access, 2FA on all admin accounts, a current web environment, and backup archives stored off-server under separate credentials that the production SSH key cannot reach.

A backup is worthless if the attacker who encrypted your production server also encrypted your backup. Several hardening measures reduce the risk:

• Restrict admin panel access by IP whitelist — prevents unauthorized access to the backup download UI
• Disable PHP error display (display_errors, display_startup_errors off in php.ini) — prevents leaking server paths that aid targeted attacks
• Enable HSTS and force HTTPS — reduces interception risk during backup downloads
• Enable two-factor authentication (2FA) for all admin accounts — Bitrix24 supports OTP via its own app
• Keep web environment current — our security audits have found portals still running on web environments several major versions behind the current recommendation, with the OS, nginx, Apache, PHP, and MySQL all outdated simultaneously. Each outdated component is a potential vector
• Maintain a firewall IP blocklist — regularly updated with IPs from which attack patterns are detected
• Store backup archives off-server with a separate set of credentials — your backup storage should not be reachable with the same SSH key as your production server

See also: Self-Hosted CRM: Why Choose Bitrix24 On-Premise for Data Sovereignty for a broader discussion of the trade-offs between cloud and on-premise deployment.

---

Restore Drills: Testing That Recovery Actually Works

A backup that has never been tested is a hypothesis, not a guarantee — schedule quarterly restore drills on a clean server, smoke-test all critical Bitrix24 functions including CRM, 1C sync, SMTP, and Push & Pull chats, and record actual RTO to verify it meets your target.

Most teams back up religiously and restore never. A backup that has never been tested is a hypothesis, not a guarantee. Schedule restore drills at least quarterly:

1. Provision a clean server (or VM snapshot) that mirrors production specs
2. Restore the database from the most recent backup — verify row counts in key CRM tables
3. Restore application files — confirm custom components and /local/ code is present
4. Restore configuration — nginx, PHP, MySQL settings applied
5. Run the Bitrix24 system check — the built-in diagnostic tool will flag DB structure errors, environment mismatches, and configuration problems
6. Smoke-test critical functions — create a test lead, update a deal, check 1C sync if applicable, verify email sending via SMTP relay, confirm Push & Pull (chats) is active
7. Measure actual RTO — record how long the full process took

Document each drill result. If actual RTO consistently exceeds your target, the backup architecture needs revision — either faster storage, a warm standby, or a reduced scope of what gets restored in the first tier.

---

Common Gaps Found in On-Premise Deployments

Technical audits of self-hosted Bitrix24 portals most frequently reveal backups stored only on the production server, inconsistent database dumps taken without XtraBackup, retention periods of just 3–5 days, and no documented restore procedure — gaps that compound because under-hardened portals are both more likely to need recovery and less likely to recover cleanly.

Based on our technical audits of self-hosted Bitrix24 portals, the most frequently encountered backup and DR gaps are:

• Backups stored only on the production server (no off-site copy)
• Database backups taken without locking or using XtraBackup — resulting in inconsistent dumps from busy portals
• No documented restore procedure — team knows backups exist, nobody knows how to use them
• InnoDB log file size too small (innodb_log_file_size = 64 MB is a common misconfiguration on legacy installs), which affects both performance and crash recovery
• Query cache left enabled — deprecated in MySQL 8.x and can cause cache corruption
• local_infile left enabled — a security risk that also signals the config has never been reviewed
• Backup retention too short (3–5 days), which won't catch a corruption event that went unnoticed for a week

These issues compound: a portal that hasn't been hardened is more likely to need recovery, and a portal whose backups haven't been validated is unlikely to recover cleanly when it does.

If your team is planning a migration from a cloud CRM to a self-hosted Bitrix24 deployment, the backup strategy should be designed before the migration — not after. See How to Migrate from HubSpot to Bitrix24: Step-by-Step Plan and Pipedrive to Bitrix24 Migration: What Changes and How to Move Your Data for migration-phase considerations.

For context on overall implementation scope and timelines, Bitrix24 Implementation Cost & Timeline: Real Data from 1,300+ Projects covers how backup setup fits into the broader project plan.