How We Restore 1C-Bitrix Sites from Backups

A call on Friday evening: 'The site is down, hosting said something about disk space, the site won't open.' It's precisely at moments like these that we, certified Bitrix engineers with ten years of experience and over 200 restored projects, understand how critical it is to have a working backup system. If a backup exists, it's a matter of a few hours. If not or it's outdated, it's a catastrophe with unpredictable consequences. Average recovery time when a backup is available is 3.5 hours, with 98% of projects completed without data loss. Our team has restored over 200 1C-Bitrix sites, and in every case, the key factor was backup quality.

Restoring from a backup in 1C-Bitrix is a procedure with specific steps that must be performed in the correct sequence. Even with a perfect archive, errors in the order of operations can lead to a full day of downtime. That's why we've refined a clear process that guarantees minimal RTO.

What a Full Backup Includes

Full backup of a Bitrix site consists of two independent parts:

• File system — the entire project: Bitrix core (/bitrix/), user data (/upload/), templates (/local/templates/), custom components (/local/components/), configuration files (.env or /bitrix/.settings.php, /bitrix/php_interface/dbconn.php).
• Database — MySQL/MariaDB dump. Contains all content, settings, users, orders, history. For large sites, the dump can be several gigabytes — tables like b_stat_* (statistics) and b_event_log often constitute most of the volume.

Both components must be saved at the same point in time. Desynchronization between files and database is a common cause of problems during recovery.

Which Backup Mechanism to Choose?

Three main approaches exist, and we recommend combining them. The built-in archiver (/bitrix/admin/backup.php) creates a file system archive and database dump in the /bitrix/backup/ folder. It's convenient but slow on large sites (over 10 GB) and requires free space on the same disk. To restore, use restore.php. Server-side backup — virtual machine snapshots, cron jobs with mysqldump + tar. It's more reliable than the built-in mechanism, independent of Bitrix, and allows recovery outside the system. This is the method we use for our clients: daily full backup with storage on Yandex Object Storage. More about mysqldump can be read on Wikipedia. Below is a comparison:

Restoring a Site via restore.php

The restoration process via restore.php: Download the restore.php file from the 1C-Bitrix site matching your version and place it in the site root. Upload the backup archive (.tar.gz) to bitrix/backup/ or specify the path in the restore.php interface. Then run the extraction wizard: file restoration, database restoration, integrity check. When restoring to a different server, enter new MySQL connection details. After restoration, check /bitrix/.settings.php — it may need adjustments for the new environment. Limitation: large archives (10+ GB) cannot be restored via browser — the process will time out due to PHP time limit. For such cases, we use the command line.

Restoration via Command Line (CLI)

For serious incidents, we use only CLI. The full recovery algorithm on a new server consists of several stages. First, prepare the environment: install BitrixEnv or configure nginx + php-fpm + MySQL manually with parameters matching the original server. The PHP version must match — even a minor version discrepancy can cause fatal errors. Then deploy files:

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

Then restore the database:

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

For large databases (over 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 

Next, configure database connection: check /bitrix/php_interface/dbconn.php and /bitrix/.settings.php — connection parameters must match the new environment. Be sure to clear cache:

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

And verify permissions: the /bitrix/ directory must be writable by the web server (cache, temporary files), /upload/ also writable.

How to Determine the Date of a Hack to Choose the Right Archive

If the site is hacked, restoration from backup is not just a rollback. You need to determine the date of the hack (nginx logs, access_log, timestamps of modified files via find /path -newer /path/reference_file). Choose an archive created before that date. Restore and check for backdoors — even a "clean" archive may contain malicious code if the hack occurred before the archive was created. Fix the vulnerability: update Bitrix, close the attacked vector (often an outdated plugin, weak FTP/SSH password, vulnerable PHP script).

One of our clients — an online clothing store — faced massive PHP file infection. Google started showing a warning "This site may be dangerous," the hosting company disabled the site. We scanned the project with the AI-Bolit utility — 847 modified files were found. We determined the infection occurred 5 days ago, so the "yesterday's" copy was also infected. We used a two-week-old file copy and a fresh database (order data). The site was restored in 1.5 days with enhanced security. Data loss: only content from two weeks had to be manually restored, orders were preserved. This case shows that even with a serious hack, restoring a 1C-Bitrix site from a backup is possible with minimal losses.

What to Do If the Backup Is Outdated

Sometimes the last backup is a week old, but only data from the past few days is lost. In such cases, we apply granular restoration: deploy the archive in a test environment, export needed elements (infoblocks, pages, orders) from the test copy, and transfer them to production via API or admin panel. This avoids losing fresh data. For example, in case of a module update error (white screen), we roll back only the module files from the backup without affecting the database. Restoration takes 15–30 minutes.

Typical Restoration Mistakes and How to Avoid Them

One of the most common mistakes is ignoring PHP and MySQL versions. If the new server has a different major version, fatal errors may occur. We check phpinfo() parameters on the original server before the crash. The second mistake is restoring to the same server without clearing the cache. Old cache files may conflict with the updated database — always delete /bitrix/cache/. The third is desynchronization of files and database. If using copies from different dates, ensure the Bitrix version in files and DB matches. And finally, restoration without checking permissions: even after a successful restore, image uploads or cache may not work — set bitrix:bitrix ownership.

Restoration Timeframes: What Depends

We guarantee that with a current backup and server access, we will restore your site within the indicated timeframes. Our team consists of certified 1C-Bitrix specialists with over 10 years of experience, and we take responsibility for the result. Contact us to assess your project — we will analyze your current backup system and propose an optimal strategy. Get a consultation today.