Disaster Recovery for 1C-Bitrix: Where It Breaks and Why
Disaster recovery for 1C-Bitrix starts not with backups, but with a map of failure points.
In a typical configuration there are four: the database node, the file storage with uploaded documents and images, replication between servers, and the application configuration itself — settings, exchange rules with 1C, custom modules.
A database failure stops everything at once: the catalog, orders, the customer portal, integrations.
Storage corruption strikes in a targeted but insidious way — the site opens, but half of the images and attachments return an error, and the client finds out about it before your team does.
Replication failure is more dangerous because it doesn't manifest immediately. Data diverges between nodes, some transactions are lost, and recovery from a backup that looks "fresh" at first glance returns the system to a state that never actually existed.
Configuration loss is a separate class: an update or an edit on the production environment overwrites the exchange settings with 1C, and the site keeps running but stops seeing warehouse stock and prices.
The cost of not having a plan comes not from site downtime, but from the depth of the rollback. If backups are taken once a day and stored on the same server as the production database, the real recovery point drifts a day back, and if the hardware fails, it's lost along with it.
Recovery in that mode stretches into hours of manual work: bring up the database, deploy the files, restore the configuration, verify the exchange with 1C, make sure orders for the period weren't lost.
We examine each failure point separately: what exactly goes down, how quickly it's noticed, how long it takes the system to return to a working state, and what data is irretrievably lost in the process. Then — how this is covered by a disaster recovery plan.
What a well-designed recovery plan delivers
A well-designed recovery plan turns an incident from a "figure it out as we go" mode into a predictable procedure with a known-in-advance recovery time and acceptable data loss.
The difference shows in the first minutes after a failure: when the on-call engineer has a recovery runbook with concrete steps, recovery takes tens of minutes instead of hours, and not every minute of downtime goes into figuring out "what actually went down and where the backups are stored."
The key effect is controlled data loss.
Backups without a plan give an illusion of protection: a copy exists, but it's unclear which point in time to roll back to, which transactions in the database will have to be replayed manually, and what to do with files uploaded after the last snapshot.
The plan fixes target metrics for each contour — how often a copy is taken, how much data is acceptable to lose, and within what time the service must return to operation — and these metrics are verified in drills rather than left on paper.
A separate class of failures related to manual actions is also closed off. According to statistics, most prolonged incidents are not hardware failures but human error: the wrong server, a forgotten migration step, restoring the wrong version of the database.
The runbook removes improvisation: a sequence of steps, checkpoints, responsible parties, and criteria by which it's clear that recovery has completed correctly.
As a result, service resilience stops depending on who exactly is on shift today. Recovery time is cut many times over, the share of lost data drops to a pre-agreed minimum, and decisions during an incident are made according to a document rather than under pressure. Let's break down how such a plan is built for a specific configuration.
Recovery scenarios: cold, hot, distributed
Choosing a recovery mode is not about "the more expensive, the better," but about matching availability requirements and the nature of the workload.
Cold recovery deploys a copy from a backup archive onto a prepared node: it suits projects where several hours of downtime is acceptable, but it provides complete isolation from a failure of the primary site.
A hot standby keeps a second node in constant sync with the production one — failover takes minutes, but it requires both nodes to be ready to accept traffic and the data not to diverge.
A distributed scheme adds cross-site replication and load balancing: the failure of one node does not interrupt service, and recovery boils down to rerouting traffic.
The price is synchronization complexity and the risk of write conflicts, which is why it is adopted for high-load portals with a strict continuity requirement.
| Option | When it fits | Limitations |
|---|---|---|
| Cold recovery | Small projects, hours of downtime acceptable | Long bring-up, manual steps, service downtime |
| Hot standby | Online stores, customer portal, minutes of downtime | Requires constant synchronization, more expensive to maintain |
| Distributed scheme | High load, continuity requirement | Complex replication, risk of conflicts, higher barrier to entry |
In practice, modes are combined: a hot standby handles fast rollback, while a cold copy at a separate site insures against the loss of an entire contour.
We set the target recovery time and recovery point for your workload profile, verify failover during drills, and only then put the scheme into production operation.
Stages of developing a disaster recovery plan
A recovery plan is not a document "for the shelf," but a sequence of engineering work where each subsequent step builds on the results of the previous one.
We start with an infrastructure audit: which components are part of the perimeter (web server, database, search index, queues, integrations with 1С), where data is stored, which failure points are critical and which can be survived. Without this map, any redundancy scheme is built at random.
- Infrastructure audit. Inventory of components, dependencies, and current failure points; we record what is already made redundant and what relies on a single node.
- Defining target metrics. We agree on the acceptable downtime and acceptable data loss for each service — the choice of scheme depends on them, not the other way around.
- Designing the redundancy scheme. Backups of the database and files, a replica, cold or hot standby, snapshot frequency and retention depth for rollback tasks.
- Setting up redundancy and monitoring. We automate snapshots, set up integrity checks and failure alerts — a silently failing backup is worse than no backup at all.
- Drill failure. We deploy a test environment and simulate a real scenario: node loss, database corruption, integration failure. We measure the actual recovery time.
- Failover procedure. Step-by-step instructions with roles and decision points: who initiates the failover, how integrity is verified, when a rollback is declared.
- Recovery verification and handover. We repeat the drill failure after adjustments, record the results, and hand over the up-to-date procedures and contacts to the team.
Each stage ends with an artifact: an infrastructure map, agreed-upon metrics, redundancy configurations, a drill failure report, a procedure.
Based on the results of the drill failure, the actual recovery time becomes visible — and it is this, not the estimated one, that becomes the benchmark for the business.
Artifacts: configurations, schemas, access policies
The documentation package is what distinguishes managed recovery from "we'll call the admin, he remembers." After the work is done, you are left with files that let any on-duty engineer bring the project up without the original author. Below is exactly what we hand over.
- Backup configuration — backup settings files: what is copied (database, uploaded files, web server configs), at what frequency, retention depth, where the copies go, and how their integrity is verified.
- Topology diagram — an up-to-date map of the environment: application servers, database, load balancer, external services, failure points, and the order in which they are brought up during an outage.
- Access policies — a role matrix: who has rights to what in the panel, in the database, in the repository, and in the infrastructure; separately — accounts for emergency access with rotation.
- On-duty instructions — a step-by-step procedure: how to recognize an incident, what to check first, how to deploy a copy, whom to escalate to, and by what criteria recovery is considered complete.
- Verification log — a table of drill recoveries: date, scenario, time to operability, what broke during the process, and what fix was applied.
- Update procedure — how changes in code and settings make it into the backups, so that the backup does not lag behind the actual state of the project.
- Contact matrix — those responsible for the database, hosting, domain, and external integrations, with the notification order in case of an emergency.
Each artifact lives in the repository next to the code, not in email or chat.
This way, when the contractor changes or an engineer leaves, recovery does not depend on someone's memory — the instructions and the log show that the system has actually been verified, not just "configured."
Case: recovery after a database node failure
The client is a retail online store on 1С-Bitrix with its own infrastructure: a web server, an application server, and a separate database node.
The failure came from where it was least expected: at night a disk on the database node degraded, the DBMS went into read-only mode, and monitoring only surfaced the problem after the fact — when the site was already throwing errors at checkout.
What it was before
Backups were taken once a day and stored on the same physical host as the database. Restoring to the latest copy meant losing a day's worth of orders and manually reconciling stock levels.
The recovery procedure existed only as notes in a chat thread, there was no one responsible for actions during a failure, and the actual downtime was about 9 hours — some customers never returned to their carts.
What was changed
We separated the copies and the database onto different sites, enabled continuous transaction log shipping — the recovery point moved from a day to minutes.
We set up a replica of the database node with automatic failover of the application to it: a failure of the primary node no longer halts order checkout.
We wrote out a step-by-step recovery plan — who makes the failover decision, how data integrity is verified, how stock levels and orders are reconciled after the bring-up.
What it became
Downtime during a database node failure dropped from 9 hours to 20-30 minutes, including data verification. Order loss during the failure window — zero: the last confirmed transaction is not lost.
We run drills on the plan once a quarter — the team performs the failover without prompts, and we see where the procedure diverges from reality.
The case is illustrative because the problem was not the absence of backups, but their location and the lack of a practiced course of action. A copy on the same host does not protect against a node failure — it dies along with it.
How does backup differ from a recovery plan?
Backup answers the question "do we have a copy of the data," while a recovery plan answers the question "what exactly does each person do in the first minutes after a failure." Copies are an asset: database dumps, website files, server configurations, exports to separate storage.
A plan is a procedure: who notices the failure, who decides on the switchover, in what sequence services are brought up, how data integrity is verified after startup.
The difference shows up at the moment of an incident. If there are only copies, the team starts with a discussion: whose site is this, where is the latest backup stored, which database version is compatible with the current code, who has access to the storage.
Every clarification costs minutes and hours of downtime, and decisions are made by people who are anxious at that moment and don't have the full picture.
A plan removes these questions: roles are assigned in advance, the sequence of steps is fixed, and decision points are defined.
The key difference is in the switchover procedure. Backup restores data but doesn't describe how to bring the service back to operability: which node to start from, how to switch traffic, what to do with the task queue and users' unfinished operations.
A plan describes this as well, along with the rollback procedure if data loss for the last few hours is discovered after startup.
Responsible roles are what is most often missing when only copies exist. Without explicitly assigned people, an incident turns into parallel attempts by different specialists to fix the system independently of each other.
A plan establishes who coordinates, who works with the database, who checks the site after it's brought up, and who communicates with users.
The difference in approaches is that copies protect data, while a plan protects the business — downtime, predictability, and the ability to report on what happened.
Common technical concerns
Before starting work, we check the recovery plan against what is already running in your environment: kernel version, 1C edition, set of modules, database, web server, load balancer, file storage, external integrations.
If the infrastructure is non-standard — a dedicated search server, a cluster, custom handlers — that is not a blocker: the redundancy scheme is built around the actual components, not a one-size-fits-all template.
The load from the redundancy mechanisms themselves is minimal and predictable. Database copying runs during the low-activity window, incremental snapshots are taken with a delay of minutes rather than in real time, so the site's response time for visitors does not change.
If the database is large, we spread copying and replication across different nodes so they do not compete for disk with production queries.
Is this compatible with our current infrastructure?
Yes, if the environment meets the platform requirements — a current kernel branch, a supported database version, sufficient disk space for snapshots. We start with an inventory: we look at what is already deployed and propose minimal adjustments rather than a full rebuild.
If some components are outdated, we will show what needs to be updated before work begins, and why recovery will not be predictable without it.
How much will the load on the servers increase?
The increase is within the margin of error during peak hours. The main work happens in the night window: a full snapshot, integrity check, test deployment. During the day, only incremental changes occur — they do not compete with production queries. If resources are tight, we move backup operations to a separate node.
How long does implementation take and what is the scope of work?
A typical project takes two to four weeks, depending on the number of integrations and the complexity of the database.
The scope includes: environment audit, setup of copying and storage, deployment scripts, testing on a staging environment, a failure response procedure, and team training. We separately define who does what on your side.
What are the environment requirements?
Required: a supported kernel and database version, space for snapshots with room for several generations, access to backup storage, and accounts with limited privileges for recovery tasks.
We verify the exact list during the audit — it depends on which components are already deployed and how permissions are configured.
Let's discuss your recovery task
To come back with an assessment and a plan rather than generalities, we need a minimum of input data about your environment. The more precise the inputs, the fewer assumptions in the estimate and the faster the project can start.
- How hosting is set up: your own server, a virtual machine, or a managed platform, and who is responsible for the infrastructure.
- Data layout: one database or several, whether there is master-master, which modules and external integrations are tied to "1C-Bitrix".
- What is already configured: backup, replication, monitoring, and whether there are verified recovery points.
- Target metrics: acceptable downtime and acceptable data loss for the last period — the architecture depends on them.
- Constraints: access requirements, security regulations, maintenance windows, and who on the customer side makes decisions.
- Failure history: what has already broken, how it was recovered, and how long it actually took.
Based on this data, we assemble an implementation plan: a list of failure scenarios, the target redundancy architecture, the procedure for responding to an incident, and a schedule of drills.
We separately define what we do during the preparation phase and what we do at the moment of an incident, so that the team has an unambiguous procedure rather than improvisation.
Describe your task in free form — we will come back with a scope assessment and an implementation plan.