По статистике инцидентов значительная доля простоев связана не с «редким катаклизмом», а с отсутствием проверенной копии, устаревшим скриптом после переезда сервера или с тем, что бэкап давно падает, а алерт никто не настроил. Руководитель слышит «у нас всё копируется» — и узнаёт правду только в день катастрофы.
Резервное копирование — та область IT, где все согласны, что «это важно», но мало кто регулярно проверяет, что копии действительно восстанавливаются. Сбой диска, ошибка администратора, ransomware или пожар на площадке — и выясняется: бэкап лежал рядом с оригиналом, последний успешный снимок недельной давности, а база 1С не попадала в расписание после переезда сервера. Ниже — практический чек-лист для владельца бизнеса и IT-ответственного: что настроить, как проверить и сколько это стоит в сравнении с простоем.
Реальные истории (обезличенно)
Торговая сеть: бэкап «настроен хостингом», но restore никто не пробовал. Сбой БД — восстановление сутки, ручной ввод накладных, штрафы контрагентам. Стоимость инцидента на порядок выше годового сопровождения бэкапов.
Производство: копии 1С на NAS в той же подсети. Ransomware зашифровал и прод, и NAS. Спасла только месячная лента в облаке, которую «когда-то включил бывший админ».
Интернет-магазин: после переезда на новый VPS cron бэкапа остался со старым путём. Три месяца «успешных» логов с нулевым размером архива. Потеря данных при падении диска — полная.
Общий урок: без теста restore и offsite бэкап — галочка в анкете, а не защита.
Зачем бэкап — бизнес-языком
Простой интернет-магазина на 4 часа в пик сезона может стоить сотни тысяч рублей упущенной выручки. Потеря учётной базы 1С — недели восстановления документов, претензии налоговой, срыв отгрузок. Бэкап — страховка с известной премией: несколько тысяч рублей в месяц на хранение и настройку против непредсказуемого убытка. Настройка и сопровождение входят в услуги системного администрирования; ориентиры по часам — в прайс-листе.
Правило 3-2-1 и что оно значит на практике
- 3 копии данных — рабочая версия плюс минимум две резервные.
- 2 типа носителей — например, диск сервера и объектное хранилище в облаке.
- 1 копия вне площадки — другой ЦОД, облако, офис на другом адресе; не в том же шкафу, что прод.
Копия «на втором разделе того же диска» или на NAS в той же комнате — не считается надёжной защитой от пожара, затопления и шифровальщика, который шифрует всё доступное по сети.
Бэкап на том же диске, что и рабочие данные. Пожар, ransomware или сбой диска убивают и оригинал, и копию одновременно.
Чек-лист: что именно бэкапить
1С и учётные данные
- Файловые базы — каталог целиком в момент остановки сеансов или через средства 1С.
- Клиент-сервер — дамп СУБД (MS SQL, PostgreSQL) по расписанию + согласованность с открытыми сеансами.
- Конфигурация, расширения, внешние обработки — отдельно от «голой» базы, в Git или архиве.
Восстановление учёта — зона ответственности специалистов по 1С; бэкап без понимания порядка остановки служб даёт битые файлы.
Сайт и приложения
- Код (репозиторий Git — уже бэкап, но проверьте, что remote не единственная копия).
- Загружаемые файлы, медиа, пользовательский контент.
- Конфиги веб-сервера, SSL-сертификаты, переменные окружения (секреты — в vault, не в открытом архиве).
- База CMS / интернет-магазина.
Инфраструктура
- Виртуальные машины — снимки или image-level backup.
- Конфиги firewall, VPN, DNS-зоны.
- Почтовые ящики и календари, если критичны для операций.
| Объект | Частота (минимум) | Хранение (ориентир) |
|---|---|---|
| База 1С (клиент-сервер) | Ежедневно, инкремент + полный еженедельно | 30–90 дней + годовой архив |
| Файловая 1С | Ежедневно | 30–60 дней |
| БД сайта | Ежедневно | 14–30 дней |
| Файлы сайта | Ежедневно или при изменениях | 14–30 дней |
| Конфиги серверов | При каждом изменении (Git) | История в Git |
Чек-лист: как бэкапить правильно
- Автоматизация — cron, Veeam, restic, Borg, облачные агенты; не «админ раз в месяц копирует руками».
- Шифрование — копии в облаке и на носителях вне офиса зашифрованы; ключи у заказчика, не только у подрядчика.
- Иммутабельность — где возможно, WORM или версионирование без права удаления с прод-сервера (защита от ransomware).
- Мониторинг джобов — алерт, если бэкап не завершился или размер аномально мал.
- Документация — runbook восстановления: порядок действий, контакты, RTO/RPO.
- Тест restore — не реже раза в квартал на изолированном стенде; фиксировать дату и результат.
RPO и RTO: сколько потерь допустимо
RPO (Recovery Point Objective) — сколько данных можно потерять по времени. Ежедневный бэкап в 03:00 при сбое в 18:00 — потеря почти суток транзакций. Для активной торговли нужны инкременты каждые 1–4 часа или непрерывная репликация.
RTO (Recovery Time Objective) — за сколько часов система должна подняться. Без репетиции RTO «на бумаге 2 часа» превращается в 2 суток в реальном инциденте.
Согласуйте RPO/RTO с владельцем бизнеса: это определяет бюджет на частоту копий и вторую площадку.
Облако, свой сервер и гибрид
Локальный бэкап — быстрое восстановление мелких файлов, но не единственная линия защиты.
Облачное хранилище (S3-совместимое, Yandex Object Storage и аналоги) — offsite, платите за объём; исходящий трафик при restore учитывайте в смете.
Гибрид — локально быстрый restore + облако на случай катастрофы площадки.
Стоимость хранения 500 ГБ в облаке — порядка нескольких тысяч рублей в месяц; разовая настройка политик — от нескольких часов работы по ставке администрирования (от 2 500 ₽/час).
Ransomware и права доступа
- Учётная запись бэкапа не должна иметь права записи в прод-файлы «на чтение и запись» — только чтение источника и запись в репозиторий копий.
- Отдельная сеть или VLAN для backup-сервера.
- Обучение сотрудников: фишинг — главный вход шифровальщика.
Интеграции и 1С: особые случаи
После внедрения обмена сайта с 1С или новых интеграций проверьте, что в бэкап попали новые каталоги, службы Windows/Linux и задания планировщика. Типичный сбой — «перенесли базу на новый диск, cron остался со старым путём».
Квартальный аудит бэкапов (чек-лист на одну страницу)
- Все критичные системы из таблицы выше в расписании?
- Последние 7 дней джобы завершались успешно (логи)?
- Копия offsite актуальна и доступна с учётными данными не только у одного уволенного админа?
- Проведён тест восстановления 1С и сайта на стенде в этом квартале?
- RPO/RPO документированы и согласованы с бизнесом?
- После изменения инфраструктуры обновлён runbook?
Назначьте ответственного за «день восстановления» — раз в квартал 2–3 часа поднимают тестовую копию базы и проверяют пару документов. Это дешевле любого реального инцидента.
Сколько стоит «ничего не делать»
Восстановление учёта с нуля, ручной ввод накладных, простой склада и магазина — легко уходит в миллионы рублей и недели времени. Абонентское сопровождение серверов с настроенным бэкапом и мониторингом — доли этого бюджета. Бэкап — не статья «когда останется бюджет», а обязательный слой вместе с firewall и обновлениями.
Сценарии восстановления по типам сбоев
Удалён один файл или папка
Восстановление из инкрементальной копии за нужную дату — минуты или часы. Требуется знать путь и время удаления.
Сбой диска на сервере
Поднятие VM из image-level backup или развёртывание на новом железе. RTO от 2 часов до суток без репетиции.
Повреждение базы 1С
Остановка сеансов, restore дампа на стенд, проверка целостности, переключение. Нельзя «просто скопировать файл» активной клиент-серверной базы без процедуры.
Ransomware
Изолировать сеть, не платить сразу, поднимать с иммутабельной или offsite-копии, менять все пароли и ключи. Локальные копии в той же сети часто зашифрованы вместе с продом.
Облачные сервисы и виртуализация
Облако не отменяет бэкап: удаление bucket-а, ошибка скрипта, компрометация аккаунта — реальные кейсы. Включите versioning, cross-region replication, MFA на удаление. Для VMware/Hyper-V — агенты Veeam или аналоги; снимайте состояние гостевых ОС, а не только хоста.
| Угроза | Локальный бэкап | Offsite + тест restore |
|---|---|---|
| Сбой одного диска | Часто спасает | Избыточно, но надёжно |
| Пожар / затопление ЦОД | Не спасает | Обязательно |
| Ransomware в сети | Редко спасает | Иммутабельная копия |
| Ошибка администратора | Зависит от версий | Point-in-time restore |
Юридические и регуляторные аспекты
Персональные данные клиентов и сотрудников в бэкапах остаются ПДн: храните копии с тем же уровнем защиты, что и прод, шифруйте при передаче в облако. Для бухгалтерии сроки хранения документов диктуют политику архивных снимков — согласуйте с бухгалтерией и сопровождением 1С.
Чек-лист для владельца бизнеса (без технического жаргона)
- Спросите IT: когда последний раз успешно поднимали копию базы на тесте?
- Есть ли копия в другом здании или облаке?
- Придёт ли SMS/письмо, если ночной бэкап сломался?
- Сколько часов простоя допустимо — записано ли это?
- Кто принимает решение платить выкуп при шифровальщике — и есть ли план B?
Один слайд: RPO, RTO, дата последнего теста restore, место хранения offsite. Если ответов нет — бэкап-стратегии как таковой нет.
Стоимость внедрения и сопровождения
Первичная настройка политик для SMB (сервер 1С + сайт + offsite) — обычно 16–40 часов работы администраторов по ставке от 2 500 ₽/час из прайса. Ежемесячно — мониторинг джобов, доработка политик, участие в тестах restore. Дешевле страховки от одного дня простоя склада в декабре.
Microsoft 365, Google Workspace и почта
Облачная почта тоже требует бэкапа: удаление ящика сотрудником, sync ransomware с локального Outlook, ошибочная политика retention. Встроенные корзины не заменяют долгосрочный архив. Для критичной переписки с контрагентами — сторонний бэкап SaaS или экспорт по регламенту.
Тестирование восстановления: пошаговый сценарий
- Выберите дату снимка не старше недели.
- Разверните изолированную VM без доступа к прод-сети.
- Восстановите базу 1С или сайта по runbook.
- Проверьте вход, несколько документов, целостность связей.
- Зафиксируйте фактическое RTO и расхождения с планом.
- Обновите runbook, если шаги устарели.
Повторяйте ежеквартально и после смены версии 1С, CMS или схемы бэкапа. Новые интеграции — повод проверить, что в расписание попали новые каталоги; см. сопровождение разработки.
Типичные отговорки и ответы
- «Хостинг сам бэкапит» — уточните срок хранения, географию и пробовали ли restore.
- «Дорого» — сравните с одним днём простоя магазина или неделей ручного восстановления учёта.
- «Некому заниматься» — задача для аутсорс-администрирования.
- «В облаке ничего не потеряется» — облако не защищает от удаления и логических ошибок.
Взаимодействие с бизнесом при инциденте
Заранее согласуйте: кто объявляет простой, как уведомляются клиенты, кто принимает решение о восстановлении из вчерашней копии с потерей сегодняшних заказов (RPO в действии). IT без связи с продажами тянет restore «идеальный» неделю; бизнес без IT жмёт «поднимите хоть что-нибудь» — и получает битую базу. Runbook включает контакт директора и правило: при ransomware не платить выкуп до изоляции и оценки offsite-копии.
Инструменты: что выбрать SMB
Для Linux часто используют restic, BorgBackup, rsnapshot + offsite sync; для Windows и VM — Veeam Community или платные редакции; для облака — снимки дисков и versioning bucket. Универсального «лучшего» нет — важны автоматизация, шифрование, мониторинг и документированный restore. Выбор инструмента — задача администратора после аудита; не покупайте «коробку» без привязки к вашим RPO/RTO.
Итог
План внедрения на 4 недели
Неделя 1: инвентаризация систем, определение RPO/RTO с бизнесом, аудит текущих копий.
Неделя 2: настройка автоматических job, offsite, шифрование, алерты на сбой.
Неделя 3: runbook, тест restore 1С и сайта на изоляте, правки по результатам.
Неделя 4: обучение ответственных, квартальный график повторных тестов, отчёт руководству.
Бюджет четырёх недель — ориентир 40–80 часов × от 2 500 ₽ по прайсу — сопоставимо с одним серьёзным инцидентом без копий.
Три копии, два носителя, одна offsite; автоматизация, шифрование, мониторинг и регулярный тест restore. Отдельно — 1С, сайт, конфиги и понятный runbook. Если последний успешный тест восстановления был больше полугода назад, у вас не бэкап-стратегия, а иллюзия безопасности.
Страховые полисы «киберрисков» часто требуют доказательств бэкапа и процедур восстановления. Даже если полиса нет, требования крупного B2B-клиента к вам как к поставщику могут включать тот же чек-лист — подготовьте ответы заранее.
Включите бэкап в онбординг новых сотрудников IT: где runbook, как запустить тест restore, кому звонить ночью. При смене подрядчика передача знаний о копиях обязательна — иначе новый админ месяц «настраивает с нуля», не зная о старом облачном bucket.
Добавьте напоминание в календарь руководителя: раз в квартал — один вопрос IT «покажите восстановление из копии». Ответ за пять минут на тестовом стенде укрепляет уверенность сильнее, чем десятки страниц политик ИБ.
Проверьте, что бэкап покрывает не только «боевые» серверы, но и тестовый стенд, если на нём воспроизводили критичные данные или подключали реальные ключи API. Утечка с теста с копией прод-базы — тот же инцидент ПДн, что и с прода.
Храните копию регламентов восстановления не только на сервере, который может упасть: распечатка в сейфе, копия в защищённом облаке у руководителя, контакт дежурного вне корпоративной почты. В инциденте недоступна как раз «вся инфраструктура целиком».
Раз в год пересматривайте политику хранения: вырос объём базы, добавились филиалы, новый склад в 1С — старые окна копирования могут не успевать завершиться до начала рабочего дня и нагрузки пользователей.
Бэкап — единственный механизм, который вы покупаете в надежде никогда не использовать, но обязаны проверить до инцидента. Откладывание «до следующего квартала» оставляет компанию один инцидент от остановки учёта и продаж. ITRTS настраивает копирование, проводит аудит и сопровождает тесты restore — начните с экспресс-проверки: за несколько часов станет ясно, защищены ли данные 1С, сайта и серверов на самом деле сейчас. Чем раньше проверка — тем дешевле исправление до первого серьёзного сбоя диска, ошибки администратора или атаки шифровальщика, сбоя дискового массива или ошибки при обновлении сервера.