Setting Up Backups for 1C-Bitrix

Setting Up Backups for 1C-Bitrix

A backup you only remember when a disaster strikes is not a backup. It is an illusion of security. 1C-Bitrix offers several backup mechanisms, and the choice between them directly affects how quickly you can restore the site after a server failure.

Built-In Backup Tools

Backup module (bitrix.backup). The platform's native tool. Creates a site archive (files + database dump) in the /bitrix/backup/ directory. Launched manually or on a schedule via agents (CAgent).

Limitations of the built-in module:

• The archive is stored on the same server as the site. If the disk fails, everything is lost.
• On large sites (10–20 GB+) the archiving process may be interrupted due to PHP timeout or memory limits.
• No built-in rotation — must be configured manually or via a cleanup agent.

Backup via BitrixEnv/BitrixVM. If the server is deployed on the official BitrixEnv image, the /root/restore.sh script is available, along with configuration options via the menu.sh menu. This method operates at the OS level and is not subject to PHP limitations.

A Proper Backup Architecture

A reliable backup strategy is built on the 3-2-1 rule:

• 3 copies of data
• 2 different media/storage types
• 1 offsite copy (outside the primary server)

For Bitrix sites this is implemented as follows:

Level 1 — local backup. Daily database dump via mysqldump + archive of /bitrix/, /upload/, and user directories. Retention: 7 days on the server.

Level 2 — remote storage. Synchronization of archives to an S3-compatible storage (Yandex Object Storage, AWS S3, Selectel). Via s3cmd, rclone, or AWS CLI, triggered by cron after the local archive is created.

Level 3 — server snapshots. If the hosting supports VM snapshots (Yandex Cloud, Hetzner, DigitalOcean) — daily full-disk snapshots. This enables fast recovery after a system-level failure.

Crontab Setup for Backups

Example of a minimal cron script for a BitrixEnv server:

# Database dump
0 3 * * * mysqldump -u bitrix -p'pass' sitedb | gzip > /home/bitrix/backup/db_$(date +\%Y\%m\%d).sql.gz

# Site files archive (excluding cache and logs)
30 3 * * * tar -czf /home/bitrix/backup/files_$(date +\%Y\%m\%d).tar.gz \
  --exclude='/home/bitrix/www/bitrix/cache' \
  --exclude='/home/bitrix/www/bitrix/managed_cache' \
  --exclude='/home/bitrix/www/bitrix/stack_cache' \
  /home/bitrix/www/

# Upload to S3
0 5 * * * rclone sync /home/bitrix/backup/ s3remote:bucket-name/backups/

# Delete local copies older than 7 days
0 6 * * * find /home/bitrix/backup/ -name "*.gz" -mtime +7 -delete

Important: exclude cache directories from the file archive (/bitrix/cache/, /bitrix/managed_cache/, /bitrix/stack_cache/). They can take up gigabytes and are completely unnecessary in a backup — the cache rebuilds itself.

Backup Integrity Verification

Creating a backup is half the job. The other half is confirming it can actually be restored. At minimum once a month: deploy the archive on a test server, verify site accessibility and data integrity.

The check can be automated with a script that deploys the latest backup to a test environment and makes an HTTP request to the home page — if the response code is not 200, it sends an alert.

Scope of Work and Timeline

Setting up backups with rotation, upload to S3, and basic integrity checking — 1–2 business days: audit of the current situation, crontab configuration, remote storage setup, testing.