Restoring a 1C-Bitrix Site from a Backup

Restoring a 1C-Bitrix Site from a Backup

A phone call saying "the site is down" on a Friday evening is a familiar situation. The causes vary: accidental data deletion, a failed update, a hack, a disk failure, "someone touched something." The speed of recovery depends on two things: whether there is a current backup, and how clearly the restoration process is understood. Improvising in the middle of an incident is the worst scenario.

Types of Incidents and Recovery Approaches

Before restoring, it is important to understand what actually happened. The recovery method depends on this.

File corruption or deletion. Roll back files from the archive without restoring the database — if the data in the DB is unaffected. Fast.

Database corruption. Restore only the DB dump — if the files are intact. You need to know exactly the dump's point in time relative to the current state of the files.

Complete server loss. Deploy on a new server from scratch: OS + web server + PHP + MySQL + Bitrix + files + DB dump. The longest scenario.

Hack (defacement or malicious code). Restore from backup plus analysis of the attack vector and remediation of the vulnerability. Restoring without analysis means returning the vulnerability.

Restoration Process: Native Tool

The built-in restorer in 1C-Bitrix is /bitrix/admin/backup.php. If the archive was created via the bitrix.backup module, it can be restored through the same interface.

Limitations: the same PHP timeout applies. Large archives (10+ GB) cannot be restored through a browser — the process will be interrupted.

Restoration via Command Line

For serious incidents — CLI only. Algorithm for full restoration on a new server:

1. Environment preparation. Install BitrixEnv (official image) or configure nginx + php-fpm + MySQL manually with parameters matching the original server. The PHP version must match.

2. Deploying files.

cd /home/bitrix/www
tar -xzf /path/to/files_backup.tar.gz --strip-components=N
chown -R bitrix:bitrix /home/bitrix/www

3. Restoring the database.

mysql -u bitrix -p sitedb < /path/to/db_backup.sql
# or for a gzip archive:
gunzip -c /path/to/db_backup.sql.gz | mysql -u bitrix -p sitedb

For a large database (1 GB+) — add acceleration parameters:

mysql -u bitrix -p --init-command="SET SESSION foreign_key_checks=0; SET SESSION unique_checks=0;" sitedb < db_backup.sql

4. Configuring the DB connection. Check /bitrix/php_interface/dbconn.php and /bitrix/.settings.php — connection parameters must match the new environment.

5. Clearing cache. After restoration, mandatory:

rm -rf /home/bitrix/www/bitrix/cache/*
rm -rf /home/bitrix/www/bitrix/managed_cache/*
rm -rf /home/bitrix/www/bitrix/stack_cache/*

6. Checking file permissions. The /bitrix/ directory must be writable by the web server (cache, temp files). /upload/ — also writable.

Restoration After a Hack

Restoring from a backup after a hack is not simply a rollback. Required steps:

1. Determine the date of the hack (nginx logs, access_log, timestamps of modified files via find /path -newer /path/reference_file).
2. Select an archive created before the hack.
3. Restore and check for backdoors — even a "clean" archive may contain malicious code if the hack occurred before the archive was created.
4. Remediate the vulnerability: update Bitrix, close the attacked vector (commonly — an outdated plugin, weak FTP/SSH password, or a vulnerable PHP script).

Case Study: Recovery After a Disk Failure

Client — an online store selling building materials. Friday, 18:30: the hosting provider reports a disk array failure. The site is inaccessible. The last backup — at night, 03:00 that same day (loss of ~15 hours of orders).

The client had a backup in Yandex Object Storage. A new VPS with BitrixEnv was deployed (20 minutes), the archive was downloaded from S3, files and the DB were restored, dbconn.php was updated, and the cache was cleared.

After 2.5 hours the site was running on the new server. Data loss: orders from the 15 hours before the failure — partially recovered from email notifications already sent to customers.

Key takeaway: with a properly configured offsite backup and a clear recovery process, 2–3 hours is a realistic RTO. Without a backup or with a backup only on the failed disk — the site is lost.

Case Study: Recovery After a Failed Update

A client updated a third-party module from Marketplace. After the update — a white screen (500 Internal Server Error), site inaccessible. The last backup was made 3 days ago.

Rolling back a three-day-old backup would mean data loss. Solution: roll back only the module files from the backup, without restoring the DB. Only the /bitrix/modules/broken_module/ directory was extracted from the archive and replaced with the old version. The site was restored in 15 minutes.

Lesson: a granular backup (files and DB separately) is more valuable than a monolithic archive.

Recovery Time Estimates

Actual figures depend on site size, channel speed to the storage, and the state of the archive.