Настройка резервного копирования данных на серверах: чек-лист и куда переносить сайт

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

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

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

Пройдите список по каждой системе, где хранятся данные компании: сайт, кабинет, CRM, 1С, внутренние сервисы. Пункты, на которые нет уверенного «да», и есть ваш список рисков.

Состав копий

• У каждой системы есть копия вне инфраструктуры основного провайдера.
• В копию входит база данных, а не только файлы сайта.
• В копию входят файлы, загруженные пользователями: документы, фото, вложения.
• Конфигурация описана и хранится вне панели провайдера: переменные окружения, настройки веб-сервера, задания расписания.
• DNS-записи выгружены в файл, а не существуют только в панели.
• Сохранён список IP-адресов и правил CDN, включая адреса в белых списках у платёжных и сторонних сервисов.

Хранилище

• Копии уезжают в объектное хранилище другой компании, не той, где работает сервер.
• Учётная запись, которой сервер пишет копии, не имеет права удаления.
• В хранилище включено версионирование.
• Включена блокировка версий на 30–90 дней, чтобы архив нельзя было стереть.
• Доступы к хранилищу не лежат на том же сервере, который в него пишет.

Проверка

• За последние 90 дней проводилось учебное восстановление целиком, а не проверка наличия файлов.
• Записано, сколько часов занял подъём.
• Записано, на какую глубину откатились данные.
• Восстановление проверял не тот человек, который настраивал копирование.

Готовность к аварии

• Время жизни DNS-записей — 10 минут или меньше, чтобы переключение заняло минуты.
• Управление DNS находится не у того, кто хостит сайт.
• Корпоративная почта не зависит от того же провайдера, что и сайт.
• Есть список паролей, ключей и токенов, которые придётся сменить, если сервер окажется скомпрометирован.
• Назначен человек, принимающий решение о восстановлении, и есть канал связи с командой, не зависящий от основного домена.

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

В ночь с 1 на 2 ноября 2026 года хостинг-провайдер Beget сообщил о кибератаке. По описанию самой компании, атакующие получили доступ к управляющему контуру всей архитектуры и запустили скрипты, обнуляющие данные. Это другой сценарий, чем отказ оборудования: вышел из строя не узел, а слой управления над всеми узлами сразу. В тот же день компания объявила обстоятельства непреодолимой силы.

Масштаб объясняет, почему это касается почти любого бизнеса в рунете. По переписи хостингов на начало октября 2026 года на инфраструктуре провайдера размещалось около 334,5 тысячи действующих сайтов в зонах .ru, .рф и .su — порядка 14,6% всех работающих сайтов, которые удалось опознать. Клиентов — больше двухсот тысяч, жалоб за сутки сервисы мониторинга зафиксировали от 7,5 до 9,8 тысячи из трёх десятков городов. Среди задетых называли и сторонние сервисы: «Честный знак», BelkaCar, Yandex Pay, «РЖД Тур» — авария пошла по интеграциям и достала тех, кто у этого провайдера ничего не размещал.

Для нашей темы важны три пункта из промежуточных итогов. Бинарные резервные копии виртуальных серверов утеряны полностью. В облачной части — виртуальные серверы, объектное хранилище, Kubernetes — данные утрачены, вместе с ними настройки CDN и IP-адреса. Файловые копии сохранились, но доступ к ним открывают не сразу: прежде нужно вручную проверить больше тысячи серверов на закладки и вредоносные скрипты.

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

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

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

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

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

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

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

Отсюда критерий, который стоит применять ко всей инфраструктуре: сколько компаний должны одновременно отказать, чтобы вы потеряли данные. Если ответ «одна», количество копий значения не имеет. Три копии в трёх папках одного сервера — это одна копия с точки зрения риска.

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

Отраслевой ориентир формулируется как «три-два-один»: три экземпляра данных, на двух разных площадках или носителях, один — вне основной инфраструктуры. Для среднего бизнес-сайта или кабинета это не требует отдельного бюджета: рабочая система, копия у провайдера и копия в объектном хранилище другой компании закрывают схему целиком.

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

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

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

В полный список входит четыре группы. База данных: заказы, заявки, пользователи, история. Загруженные пользователями файлы: они лежат не в репозитории, а на диске сервера. Конфигурация: переменные окружения, ключи интеграций, настройки веб-сервера, правила обработки почты, задания расписания. И то, что живёт вообще не на сервере: DNS-записи, настройки CDN, список IP-адресов, доступы к сторонним сервисам.

Четвёртую группу теряют чаще всего, потому что она не похожа на данные. В разобранной аварии вместе с облачной частью утрачены именно настройки CDN и IP-адреса. Сайт после этого можно собрать заново, а восстановить, какой адрес был прописан у платёжного провайдера в белом списке и какие правила кеширования стояли на раздаче картинок, — только по памяти.

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

Решается двумя способами, и лучше применять оба. Первый — отдельная учётная запись для хранилища с правом записи и без права удаления. Второй — блокировка версий на стороне хранилища. В объектных хранилищах, совместимых с S3, для этого есть механизм Object Lock, работающий по принципу «записал один раз — читаешь много».

Как это устроено на примере документированной реализации в Yandex Object Storage. Блокировка работает только при включённом версионировании. Доступны три режима: governance — версию может удалить администратор хранилища со специальным подтверждением; compliance — не может удалить никто и срок хранения нельзя сократить; legal hold — бессрочная блокировка, которую снимает отдельная роль. Срок по умолчанию задаётся на уровне бакета в днях или годах.

Практический выбор обычно такой: compliance на 30–90 дней для копий базы и governance для файловых архивов, где иногда нужна ручная чистка. Это та настройка, которая отличает архив, переживающий компрометацию сервера, от архива, который исчезнет вместе с ним. Похожие механизмы есть и у других провайдеров объектных хранилищ, но режимы и ограничения стоит сверять по документации конкретного — они различаются.

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

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

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

Мониторинг резервного копирования отвечает на вопрос «создалась ли копия». Это не тот вопрос, который волнует в день аварии. Волнует другой: сколько времени займёт подъём и что при этом потеряется. Ответ даёт только учебное восстановление.

Берётся свежая копия, на отдельной площадке разворачивается полная версия проекта, по ней проходят пять-шесть ключевых действий: открыть главную, авторизоваться, оформить заказ, проверить письмо, посмотреть данные в админке. Фиксируются две цифры: сколько часов занял подъём и какой глубины данные вернулись. Эти две цифры и есть реальное качество резервирования, остальное — намерения.

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

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

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

Список обычно длиннее, чем кажется. Пароли к базам данных, ключи для деплоя, токены платёжных систем и мессенджеров, пароли почтовых ящиков, ключи доступа к объектным хранилищам, секреты интеграций с 1С и CRM. Отдельно — ключи, дающие доступ к другим вашим серверам: через них компрометация расходится дальше.

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

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

Правильная задача — развести по разным компаниям четыре слоя. Домен и DNS: держать у регистратора или в DNS-сервисе, не связанном с хостингом, и заранее понижать время жизни записей до пяти-десяти минут. Рабочие серверы: там, где удобно эксплуатировать. Резервные копии: в объектном хранилище другой компании, с блокировкой версий. Почта: в отдельном сервисе, потому что в аварию она становится единственным каналом связи с клиентами и командой.

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

Сразу раскроем карты: ссылка на Timeweb Cloud ниже — партнёрская, мы получаем вознаграждение за переходы. Поэтому называем не «лучшего провайдера», а то, что сами используем, и критерии, по которым это можно проверить без нас. Цены и состав услуг меняются, их стоит сверять на сайтах провайдеров, а не в статьях — включая эту.

Для рабочих серверов среднего проекта мы берём облачные серверы в Timeweb Cloud: инфраструктура в российских дата-центрах, аттестация по требованиям 152-ФЗ, почасовая оплата, за счёт которой стенд для учебного восстановления можно поднять на несколько часов и погасить. Там же есть объектное хранилище, совместимое с S3 API, с тройной репликацией внутри дата-центра и бесплатным входящим трафиком — удобно, когда копии льются каждую ночь.

Одна честная оговорка по этому хранилищу: на момент написания статьи оно размещается в одной локации — Санкт-Петербурге. Три реплики внутри одного дата-центра защищают от отказа диска и узла, но это не географическое резервирование. Для схемы «копия вне основного провайдера» этого достаточно, для схемы «копия в другом регионе» — нет, и тогда нужен второй адресат.

Второй вариант для продакшена, который мы используем на проектах с требованиями по размещению и выделенным ресурсам, — облачные серверы Selectel: собственные дата-центры уровня Tier III, аттестованные сегменты под персональные данные, выделенные конфигурации. Это уже уровень компании, которая держит собственную инфраструктуру, а не арендует чужую.

Третий — Yandex Cloud. Для продакшена он дороже перечисленных, но именно его объектное хранилище мы чаще всего советуем под неудаляемые копии: это единственная из трёх площадок, у которой режимы блокировки версий — governance, compliance и legal hold — подробно описаны в публичной документации, так что настройку можно проверить по бумаге, а не на словах поддержки.

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

И про то, чего делать не надо. Публичные подборки «лучшие аналоги» в большинстве случаев тоже партнёрские, только без раскрытия: порядок в них определяется размером вознаграждения, а цены устаревают через квартал. Проверяйте по четырём вопросам: можно ли выгружать копии за пределы провайдера и есть ли блокировка версий; есть ли документированный способ забрать все данные самому, без обращения в поддержку; как разделены аккаунт клиента и управляющий слой провайдера; как быстро отвечает поддержка в обычный день. Пятый вопрос не технический, но важнее остальных: как провайдер ведёт себя во время инцидента. Отсутствие публичных аварий — это не отсутствие риска, а отсутствие информации.

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

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

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

Что копируется — перечень систем и для каждой состав копии. Куда — площадка, учётная запись, кто имеет к ней доступ. Как часто и сколько хранится — отдельно по файлам, базе и конфигурации. Допустимая потеря данных и допустимое время простоя — две цифры, согласованные с бизнесом, а не выбранные техническим специалистом. Кто проверяет восстановление и по какому сценарию. И последнее: кто принимает решение о восстановлении и по какому каналу с ним связываются, если основная почта лежит вместе с сайтом.

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

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

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

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

Хостинг делает бэкапы сам. Этого достаточно?

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

Как часто нужно делать резервное копирование данных на серверах?

Частота выводится из допустимой потери. Сайт-визитка и каталог без заказов — раз в сутки. Кабинет, корзина, заявки — раз в сутки файлы и несколько раз в сутки база. Если терять нельзя ничего, нужен журнал транзакций и восстановление на точку во времени.

Сколько хранить копии?

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

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

Хранение для среднего проекта — сотни рублей в месяц, это не статья расходов. Основные деньги в работе: описать инфраструктуру, развести слои, настроить выгрузку с блокировкой версий и один раз проверить восстановление. Если инфраструктура уже описана, это несколько часов; если её приходится разбирать по ходу — день-два.

Можно ли отсудить у провайдера потери от простоя?

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

Что делать прямо сейчас, если данные остались только у упавшего провайдера?

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

Первое — пройти чек-лист из этой статьи по каждой системе и выписать пункты без уверенного «да». Это займёт вечер и даст точный список рисков вместо общего беспокойства.

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

Третье — вынести из панели провайдера наружу два слоя: управление DNS и резервные копии. Самые дешёвые изменения из возможных и самые полезные в аварию.

Четвёртое — описать конфигурацию рядом с кодом: DNS-записи, адреса, правила раздачи, перечень интеграций и секретов.

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