# Резервное копирование сайта на WordPress и 1С-Битрикс

URL: https://chugunov.pro/rezervnoe-kopirovanie-sajta/
Обновлено: 04.10.2026.
Источник: chugunov.pro.

## Коротко

Создание резервной копии сайта — это сохранение двух вещей: файлов (код, шаблоны, загруженные изображения, настройки) и базы данных (страницы, товары, заказы, пользователи). Только вместе они дают рабочий сайт. Копия, в которой есть файлы, но нет свежей базы, или наоборот, при аварии почти бесполезна.

Хорошая резервная копия делается автоматически по расписанию, хранится отдельно от сервера сайта и хотя бы раз была проверена восстановлением. Ниже — как устроены бэкапы в WordPress и 1С-Битрикс, какие способы бывают, где хранить архивы и как не обнаружить в день аварии, что копия пустая.

| Способ | Что сохраняет | Плюсы | Минусы |
| --- | --- | --- | --- |
| Бэкап хостинга | Файлы и базы на сервере | Не нужно ничего настраивать | Хранится у того же провайдера, срок хранения ограничен |
| Плагин WordPress | Файлы и база сайта | Гибкое расписание, выгрузка в облако | Нагружает сервер, зависит от работы самого сайта |
| Встроенный бэкап 1С-Битрикс | Файлы ядра, публичная часть, база | Штатный инструмент, умеет восстанавливать на другом сервере | Большие архивы на тяжёлых сайтах, нужна настройка |
| Скрипт на сервере (VPS) | Всё, что указано в скрипте | Полный контроль, не зависит от CMS | Нужен администратор, скрипт надо поддерживать |

## Основная мысль

**Резервная копия ценна не тем, что она создаётся, а тем, что из неё можно восстановить сайт: поэтому бэкап — это процесс из трёх частей (автоматическое создание, хранение вне сервера и регулярная проверка восстановления), а не одна кнопка в админке.**

Большинство владельцев вспоминают о бэкапах в момент аварии: сайт взломали, обновление сломало вёрстку, хостинг потерял данные, сотрудник удалил раздел каталога. В этот момент выясняется, что последняя копия сделана полгода назад, лежит на том же сервере или не содержит папки с изображениями.

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

## Что входит в резервную копию сайта

Сайт на любой CMS состоит из двух независимых частей. Их копируют разными способами, и обе обязательны.

### Файлы

- **Ядро CMS.** Файлы WordPress или 1С-Битрикс. Их можно скачать заново, но точная версия с вашими правками есть только в копии.
- **Тема или шаблон.** Вёрстка, стили, скрипты, доработки.
- **Плагины и модули**, включая купленные и написанные под заказ.
- **Загруженные файлы.** В WordPress это wp-content/uploads, в 1С-Битрикс — папка /upload/. Здесь изображения товаров, документы, вложения. Обычно это самая объёмная часть.
- **Конфигурация.** wp-config.php, /bitrix/.settings.php, .htaccess, файлы настроек сервера.

### База данных

В базе хранится всё, что меняется через админку и сам сайт: страницы, записи, товары, цены, заказы, пользователи, настройки плагинов и модулей. Резервная копия баз сайта — это дамп, файл с SQL-командами, которые воссоздают таблицы и данные. Его делают через phpMyAdmin, панель хостинга, плагин, встроенный инструмент CMS или утилиту mysqldump на сервере.

### Что можно не копировать

Кеш, временные файлы и старые архивы бэкапов внутри сайта только раздувают копию. В WordPress это папки кеша плагинов в wp-content/cache, в 1С-Битрикс — /bitrix/cache/ и /bitrix/managed_cache/. Их исключают из архива, при восстановлении кеш соберётся заново.

## Как сделать резервную копию сайта на WordPress

Для WordPress есть три рабочих подхода. Выбор зависит от хостинга, размера сайта и того, насколько он критичен для бизнеса.

### Бэкап сайта на WordPress через плагин

Плагины резервного копирования — самый доступный вариант для небольших сайтов. Общий принцип у всех одинаковый:

1. Установить плагин из официального каталога и открыть его настройки.
2. Выбрать, что копировать: базу данных, файлы или всё вместе.
3. Задать расписание: например, база ежедневно, файлы еженедельно.
4. Подключить удалённое хранилище: облачный диск, FTP или S3-совместимое хранилище.
5. Указать, сколько последних копий хранить.
6. Запустить первую копию вручную и убедиться, что архив появился в хранилище.

У плагинов есть ограничение: они работают внутри сайта. Если сайт взломан или не открывается, плагин тоже может перестать делать копии. На большом сайте создание архива может упираться в лимит времени выполнения скрипта или памяти на виртуальном хостинге.

### Резервные копии сайта WordPress средствами хостинга

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

### Ручной бэкап

Иногда копию нужно сделать прямо сейчас, например перед обновлением. Как сделать резервную копию сайта на WordPress вручную:

1. В панели хостинга или через phpMyAdmin экспортировать базу данных в файл SQL.
2. Через файловый менеджер или FTP скачать папку сайта целиком или хотя бы wp-content и wp-config.php.
3. Сохранить оба файла в одном месте с датой в названии.

На VPS то же самое делается двумя командами:

```
mysqldump -u user -p dbname > backup-2026-12-04.sql
tar -czf site-2026-12-04.tar.gz /var/www/site
```

Имя пользователя, базы и путь к сайту нужно подставить свои. Пароль команда запросит сама.

### Автоматические копии на VPS

Если сайт работает на собственном VPS, надёжнее всего настроить копирование средствами сервера, не завися от CMS. Типовая схема выглядит так:

1. Написать shell-скрипт, который делает дамп базы, упаковывает файлы сайта с исключением папок кеша и добавляет к имени архива дату.
2. Для пароля базы использовать отдельный конфигурационный файл MySQL с правами только для владельца, а не указывать пароль прямо в скрипте.
3. Отправлять готовый архив во внешнее хранилище утилитой синхронизации или клиентом S3.
4. Удалять локальные архивы старше нескольких дней, чтобы не забить диск.
5. Добавить скрипт в cron, например на ночное время, когда нагрузка минимальна.
6. Настроить уведомление на почту или в мессенджер, если скрипт завершился с ошибкой.

Такой подход одинаково работает для WordPress, 1С-Битрикс и любого другого сайта. Минус один: скрипт нужно сопровождать. Если на сервере сменился путь к сайту или имя базы, копии тихо перестанут содержать нужные данные, поэтому без проверки восстановления не обойтись и здесь.

### Что учесть для WooCommerce

В интернет-магазине на WooCommerce база меняется постоянно: заказы, остатки, покупатели. Откат всей базы на вчерашнюю копию означает потерю сегодняшних заказов. Поэтому перед восстановлением магазина всегда сохраняют текущее состояние базы, а при частичных сбоях переносят из копии только испорченные данные. Для активных магазинов частоту копирования базы увеличивают, а крупные работы планируют на часы с минимумом заказов.

## Резервная копия сайта в 1С-Битрикс

В 1С-Битрикс резервное копирование встроено в ядро. Инструмент находится в административной панели в разделе настроек, в группе инструментов резервного копирования. Он умеет создавать полную копию сайта, копировать только базу или только файлы, работать по расписанию и хранить архивы как на сервере, так и во внешнем хранилище.

### Как настроить бэкап в Битриксе

1. Открыть раздел резервного копирования в административной панели.
2. Выбрать состав: ядро, публичная часть, база данных. Исключить папки кеша и сами архивы бэкапов.
3. Выбрать место хранения. Облачное хранилище 1С-Битрикс доступно в рамках активной лицензии, также можно подключить собственное облачное хранилище через модуль облачных хранилищ.
4. Настроить автоматическое создание по расписанию. Для регулярного запуска без визитов на сайт агенты стоит перевести на cron, иначе расписание будет срабатывать только при заходах.
5. Запустить копию вручную и проверить, что архив создан полностью.

### Как восстановить сайт из архива Битрикса

Для восстановления используется скрипт restore.php, который распространяется 1С-Битрикс. Его кладут в корень пустого сайта вместе с архивом или указывают ссылку на архив, открывают в браузере и проходят шаги мастера: распаковка файлов, подключение к базе, развёртывание дампа. Тот же сценарий применяют для переноса сайта на другой сервер.

### Особенности больших сайтов на 1С-Битрикс

Интернет-магазины с десятками тысяч товаров и большой папкой /upload/ создают архивы на многие гигабайты. Полная копия каждый день здесь неудобна. Практичнее ежедневно копировать базу, а файлы — реже или инкрементально средствами сервера. Если сайт обменивается данными с 1С, копию базы полезно делать до ночного обмена, чтобы при сбое обмена вернуться в чистое состояние. Подробнее о настройке обмена — в статье [про обмен Битрикс с 1С](https://chugunov.pro/obmen-bitriks-s-1s-nastrojka/).

## Как часто делать бэкап и сколько копий хранить

Частота зависит от того, сколько данных вы готовы потерять. Если база копируется раз в неделю, при аварии в пятницу вы потеряете всё с понедельника: заказы, заявки, правки контента.

### Ориентиры по частоте

| Тип сайта | База данных | Файлы | Глубина хранения |
| --- | --- | --- | --- |
| Лендинг, визитка | При изменениях или раз в неделю | Раз в неделю или месяц | Несколько последних версий |
| Корпоративный сайт с блогом | Ежедневно | Раз в неделю | 2–4 недели |
| Интернет-магазин | Ежедневно, для активных магазинов чаще | Ежедневно или инкрементально | 2–4 недели плюс ежемесячные копии |
| Сайт с личным кабинетом | Несколько раз в день | Ежедневно | Не меньше месяца |

### Правило 3-2-1

Классический принцип хранения: три копии данных, на двух разных типах носителей, одна из них — вне основной площадки. Для сайта это означает: рабочий сайт, копия у хостинга и копия во внешнем облачном хранилище или на другом сервере. Если хостинг-провайдер потеряет данные или заблокирует аккаунт, внешняя копия останется доступной.

### Ротация

Хранить бесконечно много копий не нужно, но и одной последней мало. Взлом или порча данных часто обнаруживаются через несколько дней, и к этому моменту последняя копия уже содержит проблему. Удобная схема — ежедневные копии за последние две недели и по одной на каждый месяц.

## Где хранить резервные копии

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

### Варианты хранения

- **Облачное хранилище.** S3-совместимые хранилища и облачные диски. Подходят для автоматической выгрузки из плагинов, Битрикса и скриптов.
- **Отдельный сервер.** Копии по расписанию уходят на другой VPS у другого провайдера.
- **Локальный диск.** Периодическая выгрузка архива на компьютер или внешний диск владельца. Подходит как дополнительный уровень, но не как основной: такой процесс держится на дисциплине.

### Сколько места нужно под копии

Объём считают от размера сайта. Дамп базы обычно занимает немного и хорошо сжимается, а основную долю дают загруженные файлы: изображения товаров, документы, видео. Если папка uploads или /upload/ весит несколько гигабайт, то две недели ежедневных полных копий превратятся в десятки гигабайт.

Снизить объём помогают три приёма. Первый — копировать базу часто, а файлы реже. Второй — инкрементальные копии, когда сохраняются только изменённые с прошлого раза файлы; это умеют серверные утилиты синхронизации и некоторые плагины. Третий — исключить из архива всё, что можно восстановить без копии: кеш, миниатюры, которые CMS сгенерирует заново, и старые архивы. Перед исключением миниатюр стоит убедиться, что их пересоздание на вашем сайте действительно работает.

### Безопасность копий

В архиве лежит вся база: пользователи, email, телефоны, заказы. Поэтому доступ к хранилищу закрывают отдельным паролем, для облака создают ключ с минимальными правами — только запись в нужную папку. Если хранилище поддерживает шифрование, его включают. Архивы внутри корня сайта, если без них не обойтись, закрывают от прямого доступа из браузера.

## Проверка восстановления: без неё бэкапа нет

Копия, которую ни разу не разворачивали, — предположение, а не страховка. Архив может оказаться обрезанным из-за лимита места, дамп базы — неполным из-за ошибки кодировки, а папка uploads — исключённой из копии «для экономии».

### Как проверить бэкап

1. Раз в квартал взять случайную свежую копию.
2. Развернуть её на тестовом поддомене или локально.
3. Проверить главную, каталог, карточку товара, форму заявки, вход в админку.
4. Сравнить количество товаров, заказов, страниц с рабочим сайтом.
5. Записать, сколько времени заняло восстановление. Это ваш реальный срок простоя при аварии.

### Что делать перед рискованными работами

Перед обновлением ядра, плагинов, модулей, сменой версии PHP и переносом делают внеплановую копию и проверяют, что она создалась. Если работы идут по статье [об обновлении 1С-Битрикс без потери доработок](https://chugunov.pro/obnovlenie-1s-bitriks-bez-poteri-dorabotok/) или при [переносе сайта на другой хостинг](https://chugunov.pro/perenos-sajta-na-drugoj-hosting/), свежий бэкап — обязательный первый шаг.

## Сценарии, в которых выручает резервная копия

Ниже собирательные ситуации, которые показывают, почему схема бэкапов важнее конкретного плагина.

### Взлом сайта

На сайте появился вредоносный код, поисковик пометил его как опасный. Если есть копии за несколько недель, можно найти версию до заражения, сравнить файлы и восстановить чистые. Базу при этом откатывают осторожно: нельзя потерять заказы, пришедшие после взлома. Без копий лечение превращается в ручной поиск каждого изменённого файла.

### Неудачное обновление

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

### Ошибка сотрудника

Менеджер удалил раздел каталога вместе с товарами. Восстанавливать всю базу нельзя: пропадут заказы за день. Здесь помогает развернуть копию отдельно и перенести из неё только удалённые данные. Это работа разработчика, но она возможна только при наличии копии.

### Проблемы у хостинга

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

## Типичные ошибки и чек-лист

### На чём опасно экономить

- **Копии только у хостинга.** Одна площадка — одна точка отказа.
- **Нет копии базы, только файлы.** Сайт без базы — пустой шаблон.
- **Архивы в корне сайта.** Занимают место, мешают следующим копиям и могут быть скачаны посторонними.
- **Бэкап вручную «когда вспомню».** На практике это означает «никогда перед аварией».
- **Никто не следит за результатом.** Плагин полгода сообщал об ошибке, но письма уходили на старый адрес.
- **Одна копия.** Если она уже содержит вредоносный код или испорченные данные, откатиться некуда.

### Чек-лист

- Копируются и файлы, и база данных.
- Кеш и старые архивы исключены из копии.
- Расписание автоматическое, частота соответствует типу сайта.
- Минимум одна копия хранится вне сервера сайта.
- Доступ к хранилищу защищён, архивы не лежат в открытом доступе.
- Уведомления об ошибках приходят на актуальный адрес.
- Раз в квартал проводится тестовое восстановление.
- Перед обновлениями и переносом делается внеплановая копия.
- Записаны доступы к хранилищу и инструкция по восстановлению.

## Частые вопросы

### Как сделать резервную копию сайта, если я не разработчик?

Проверьте, делает ли копии хостинг, и включите плагин резервного копирования в WordPress или встроенный инструмент в 1С-Битрикс с выгрузкой во внешнее облако. Первую копию попросите проверить специалиста.

### Как создать резервную копию сайта перед обновлением?

Запустите внеплановую копию в плагине или разделе резервного копирования Битрикса, дождитесь завершения и убедитесь, что архив появился в хранилище. Только после этого начинайте обновление.

### Как сделать резервную копию сайта на WordPress без плагина?

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

### Где хранится резервная копия сайта в Битриксе?

Архивы 1С-Битрикс по умолчанию хранятся на сервере в служебной папке бэкапов, а при настройке — в облачном хранилище. Список доступных копий показан в разделе резервного копирования административной панели.

### Как сделать резервную копию баз сайта отдельно от файлов?

Через phpMyAdmin (экспорт в SQL), панель хостинга, утилиту mysqldump на сервере или настройку плагина и Битрикса, в которой выбрана только база данных.

### Как часто нужен бэкап сайта на WordPress?

Для блога и корпоративного сайта достаточно ежедневной копии базы и еженедельной копии файлов. Для магазина базу копируют ежедневно или чаще.

### Нужно ли копировать сайт, если у хостинга есть ежедневные бэкапы?

Да, хотя бы раз в неделю во внешнее хранилище. Копии хостинга удобны для быстрого отката, но срок их хранения ограничен, а доступ к ним зависит от состояния вашего аккаунта у провайдера.

### Можно ли хранить бэкапы на том же хостинге?

Как один из уровней — да. Как единственный — нет: при сбое или блокировке аккаунта вы потеряете и сайт, и копии.

### Сколько стоит настройка резервного копирования?

Настройка схемы для одного сайта обычно укладывается в несколько часов работы. Поддержка сайта у меня стоит от 2 000 ₽ в час, точный объём зависит от CMS, размера и хостинга.

### Что делать, если копии нет, а сайт сломан?

Не вносить хаотичных правок. Сначала скопировать текущее состояние файлов и базы как есть, затем разбираться с причиной. Иногда часть данных можно вернуть из копий хостинга, о которых владелец не знал.

## Итог

Резервная копия сайта — это файлы плюс база данных, созданные автоматически, сохранённые вне сервера сайта и проверенные восстановлением. В WordPress для этого используют плагины и бэкапы хостинга, в 1С-Битрикс — встроенный инструмент с хранением в облаке, на VPS — серверные скрипты.

Настроить такую схему один раз проще и дешевле, чем восстанавливать сайт по кусочкам после взлома, неудачного обновления или сбоя хостинга. Главное — не останавливаться на первом шаге и регулярно проверять, что из копии действительно разворачивается рабочий сайт.

Если нужно настроить резервное копирование или сайт уже пострадал и его надо поднять из архива, я как частный разработчик на WordPress и 1С-Битрикс настрою бэкапы, проверю восстановление и верну сайт в рабочее состояние. Работаю напрямую, без посредников — подробности на странице [восстановления сайта](https://chugunov.pro/uslugi/vosstanovlenie-sajta/).

- 02.09.2026

## Связанное на сайте

- Услуга [Перенос сайта на Битрикс](https://chugunov.pro/uslugi/perenos-sajta-na-bitriks/)
- Справочник API [Справочник API 1С-Битрикс](https://chugunov.pro/api-bitrix/)
- Глоссарий [Глоссарий: 1С-Битрикс](https://chugunov.pro/glossary/bitrix/)

Автор статьи [Чугунов Алексей](https://chugunov.pro/about/) Fullstack-разработчик: 1С-Битрикс, WordPress, PHP
[Обо мне](https://chugunov.pro/about/)

Рубрики блога

- [Продажи](https://chugunov.pro/category/sales/) 16
- [Продвижение](https://chugunov.pro/category/prodvizhenie/) 22
- [Создание сайтов](https://chugunov.pro/category/sozdanie-sajtov/) 75
- [Интересное](https://chugunov.pro/category/interesnoe/) 13

Остались вопросы?

Отправьте сообщение, и я свяжусь с вами в ближайшее время

Или звоните, сразу обсудим детали.

[+7 (915) 016-99-88](tel:79150169988)