Резервное копирование

Встроенный мастер резервного копирования формирует архивы сайта и базы данных локально или в облачном хранилище Битрикса для восстановления утилитой restore.php. Для нагруженных интернет-магазинов снятие дампов базы переносится на системный уровень (mysqldump --single-transaction), а работоспособность копий регулярно подтверждается тестовыми развертываниями на изолированном стенде.

Прогресс хранится в этом браузере. Войдите, чтобы сохранить его в аккаунте.

Что нужно понимать

1

Встроенное резервное копирование
2

Облачное хранение
3

Автоматизация бэкапов

Материалы

Официальная документация

★ Резервное копирование Новая дока
Многосайтовость: раздел «Выполнить резервное копирование» Новая дока

Проверь себя

Диск умер, копии год лежат в облаке 1С-Битрикс, а мастер восстановления просит пароль, которого никто не знает. Как так вышло?

Регулярное копирование хранит пароль шифрования в базе, зашифрованным лицензионным ключом, а база лежала на том же диске. Пароль от автоматических копий записывают отдельно, в менеджер паролей команды.

Почему встроенный бэкап не подходит как единственный для магазина с базой в 20 ГБ?

Он работает на PHP шагами по 30 секунд, дамп собирается не одномоментно, и делает только MySQL. Основной бэкап — на уровне сервера: mysqldump с --single-transaction или xtrabackup плюс rsync upload; встроенный — второй эшелон и инструмент переезда.

Бэкап через cron_events.php не создался, а следующий появился только через сутки. Это нормально?

Да, так устроен запуск через cron: после ошибки повтор только через сутки, ошибка — в журнале резервного копирования. Если нужен контроль, запускайте backup.php напрямую из cron в режиме «прямой запуск» и следите за кодом выхода.

Что проверять раз в квартал, кроме того, что архив создаётся?

Что из него поднимается сайт: restore.php на стенде, вход в админку, картинки из upload, обмен с 1С. Бэкап, который никто не восстанавливал, не существует.