Резервное копирование данных компании: как настроить

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

Зачем компании резервное копирование

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

Резервное копирование закрывает четыре группы рисков:

• Отказ оборудования. Диск, RAID-массив или сервер выходят из строя в любой момент, а не по графику. Бэкап — единственный способ вернуть данные без дорогостоящего восстановления в лаборатории.
• Шифровальщики. Вирус-вымогатель шифрует не только рабочие файлы, но и подключённые сетевые диски. Отдельная, недоступная из сети копия остаётся единственной точкой отката.
• Человеческая ошибка. Случайное удаление папки, ошибочная операция в 1С, «обновил — всё сломалось». Свежая копия позволяет откатиться за минуты.
• Физические события. Пожар, затопление, кража сервера. Копия, которая лежит в том же помещении, гибнет вместе с оригиналами.

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

Для компаний, у которых нет своего системного администратора, настройку и контроль бэкапов разумно передать на ИТ-аутсорсинг и обслуживание серверов — так резервное копирование ведётся по регламенту, а не «когда дойдут руки».

Правило 3-2-1: основа надёжного бэкапа

Классическая схема, которую используют и в малом бизнесе, и в крупных компаниях, формулируется просто:

1. 3 копии данных — оригинал и как минимум два бэкапа.
2. 2 разных носителя — например, сетевой NAS и внешний диск или лента. Если сдохнет один тип носителя, второй останется.
3. 1 копия вне площадки — в другом помещении, городе или в облаке. Она защищает от пожара, кражи и шифровальщика, который «достаёт» до всего в локальной сети.

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

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

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

Что и как часто копировать

Универсальный список объектов резервного копирования выглядит так:

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

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

Частоту удобно подбирать через показатель RPO (recovery point objective) — максимально допустимую потерю данных во времени. Если бизнес готов потерять не больше одного рабочего дня, хватает ежедневной копии на конец дня. Если документы в 1С вносятся непрерывно и потеря даже пары часов болезненна, копии делают несколько раз в день. Чем меньше RPO, тем чаще копирование и тем больше места занимает хранилище, поэтому показатель считают осознанно, а не «почаще на всякий случай».

Ориентировочное расписание и сроки хранения собраны в таблице:

Источник данных	Частота копирования	Срок хранения	Где хранить
Базы 1С и ERP	ежедневно, перед обновлением — дополнительно	2–4 недели ежедневных + 1–2 месяца еженедельных	NAS или облако + внешний диск
Файлы и документы	ежедневно (инкрементально)	1–3 месяца	NAS, облако
Сайт (файлы + БД)	ежедневно, перед обновлением CMS	1–2 месяца	хостинг + внешняя копия
Почта на своём сервере	ежедневно	1–3 месяца	NAS, облако
Образ сервера (ОС + настройки)	еженедельно и после изменений	1–3 месяца	облако, внешний носитель

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

Полный, инкрементный, дифференциальный: какую схему выбрать

Схема резервного копирования определяет, сколько места занимают копии и как быстро они восстанавливаются. Три базовых типа:

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

Рабочая схема для СМБ — это комбинация: ежедневный инкрементный бэкап на отдельное хранилище (NAS или облако), еженедельный полный — на внешний носитель, и снимок сервера в облаке. Такой подход держит баланс между объёмом, скоростью и надёжностью восстановления.

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

Пример объёмов: база 1С на 50 ГБ при ежедневном полном копировании за месяц займёт около 1,5 ТБ, а при схеме «еженедельный полный + ежедневные инкременты» — в разы меньше, при этом восстановление всё равно займёт минуты. Именно поэтому для растущих баз выбирают комбинацию, а не «каждый день всё целиком».

NAS, облако или внешний диск: как выбрать хранилище

Хранилище подбирают под объём данных, скорость восстановления и бюджет. Три основных варианта с их ограничениями:

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

На практике для офиса на 15–20 человек с базой 1С хорошо работает связка «NAS + облако»: ежедневные копии уходят на NAS и дают быстрый откат за минуты, а раз в неделю — в облако или на внешний диск, который уносят из офиса. Так оперативные восстановления не зависят от интернета, а критичная копия остаётся вне площадки.

Сценарии потери данных и сколько они стоят

Чтобы понять, зачем вкладываться в бэкапы, достаточно прикинуть стоимость простоя по основным сценариям:

• Шифровальщик. Сотрудник открыл вложение из письма — зашифрованы файлы и подключённые сетевые диски. Без внешней копии данные либо выкупают у злоумышленников без гарантий, либо теряют навсегда.
• Отказ диска или RAID. Выход из строя сразу двух дисков массива или контроллера. Последствия зависят только от того, насколько свежа и цела резервная копия.
• Ошибка оператора. Удалили папку, перепровели документы в 1С задним числом, случайно очистили таблицу. Откат на вчерашнюю копию решает проблему за минуты.
• Неудачное обновление. После обновления 1С или серверного ПО система перестала запускаться. Здесь нужен и бэкап базы, и образ сервера.
• Увольнение администратора. Сотрудник ушёл и «забрал» с собой доступы или удалил данные. Копии вне его зоны контроля и ревизия прав закрывают этот риск.

Прямые потери — это не только данные, но и время сотрудников, которые простаивают без 1С и почты, сорванные отгрузки и испорченная отчётность. Один день простоя офиса на 15–20 человек зачастую обходится дороже, чем год регулярного обслуживания бэкапов. Ориентир по стоимости абонентского обслуживания, в которое входит и резервное копирование, смотрите на странице цены на ИТ-обслуживание.

Для планирования полезно зафиксировать целевые значения: например, RPO не более 24 часов (теряем максимум один рабочий день) и RTO не более 4 часов (восстановление за полдня). Это позволяет честно оценить, справится ли текущая схема бэкапов, и аргументировать бюджет на хранилище и автоматизацию.

Типовые ошибки при настройке

Большинство «внезапных» потерь данных происходит не из-за отсутствия бэкапов, а из-за ошибок в их настройке:

1. Копия на том же диске или сервере. Снимок рядом с оригиналом гибнет вместе с ним при поломке диска или шифровании.
2. Бэкап не проверяют. Задание завершается «успешно», но архив повреждён или в него попала пустая база. Формально копия есть, фактически — нет.
3. Нет копии настроек. Бэкап базы 1С без файла конфигурации и лицензий восстанавливается частично и требует ручной донастройки.
4. Копия доступна из той же сети. Шифровальщик, запущенный на рабочей станции, добирается и до сетевого хранилища, если у него есть права на запись.
5. Никто не следит за местом на диске. Хранилище заполнилось — новые бэкапы перестали создаваться, а узнают об этом только в момент аварии.
6. Бэкапы привязаны к одному человеку. Если доступ к хранилищу есть только у ушедшего администратора, копия для бизнеса фактически потеряна.

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

Как проверить восстановление

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

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

Такая проверка занимает около часа и стоит дешевле аварии. Полезно замерить два показателя: RPO — на какой момент данные будут восстановлены (сколько часов работы теряется), и RTO — сколько времени займёт само восстановление. Они показывают, соответствует ли схема бэкапов реальным требованиям бизнеса.

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

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

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

Сколько хранить и что проверять раз в месяц

Сроки хранения удобно выстраивать по схеме GFS (grandfather-father-son): ежедневные копии за последние 2–4 недели, еженедельные за 1–2 месяца и месячные снимки за полгода–год для баз и финансовых данных. Такая «лесенка» даёт и быстрый откат на вчерашний день, и возможность вернуться к состоянию месячной давности, если ошибку заметили не сразу.

Раз в месяц стоит проводить короткую ревизию бэкапов по одному и тому же списку:

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

Такая ревизия занимает 1–2 часа в месяц и чаще всего находит проблемы ещё до аварии: заполнившийся диск, тихо переставшее выполняться задание или архив, в который попадала пустая база. Это и есть та профилактика, которая отличает работающий бэкап от «где-то лежит архив».

Чек-лист настройки бэкапов

Короткий список, по которому можно проверить, что резервное копирование действительно защищает компанию:

• Составлен перечень данных: базы 1С, файлы, сайт, почта, настройки сервера.
• Копии хранятся минимум в двух местах, одно из которых — вне площадки.
• Расписание запускается автоматически по ночам, без участия сотрудников.
• Перед обновлениями 1С и серверного ПО снимается отдельный бэкап.
• Раз в месяц выполняется тестовое восстановление, результат фиксируется.
• Контролируется свободное место на хранилище и уведомления об ошибках заданий.
• Доступы к хранилищу есть как минимум у двух ответственных.
• Замерены RPO и RTO, сроки хранения копий перекрывают время обнаружения ошибки.

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

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