Настраиваем автоматическое резервное копирование серверов, 1С, SQL, виртуальных машин, файлов и других критичных данных. Проектируем систему с учётом допустимой потери информации и необходимого времени восстановления, настраиваем хранение копий и обязательно проверяем восстановление на практике.
ОБСУДИТЬ ЗАДАЧУ
ЧТО МЫ ПРЕДЛАГАЕМ
Наличие резервной копии ещё не означает, что данные удастся восстановить после сбоя. Копия может оказаться повреждённой, устаревшей, недоступной или храниться на том же оборудовании, которое вышло из строя.
Поэтому резервное копирование рассматриваем как систему восстановления бизнеса после инцидента. Сначала определяем, какие данные критичны, сколько информации компания допустимо может потерять и как быстро необходимо вернуть системы в работу. После этого подбираем схему резервирования, настраиваем хранилища, расписание, контроль выполнения и тестовое восстановление.
Для баз данных особенно важно проверять не только наличие файлов резервных копий, но и возможность фактического восстановления. Стратегия резервирования не считается проверенной, пока восстановление не было успешно протестировано.
ЧТО ВХОДИТ В УСЛУГУ
Определяем, какие данные и системы существуют в инфраструктуре, где они находятся и что необходимо защищать в первую очередь: базы 1С, SQL, файловые серверы, виртуальные машины, документы, конфигурации серверов и другие корпоративные сервисы. Анализируем существующее резервирование: что копируется, куда, как часто, сколько версий хранится, есть ли уведомления и проводилось ли восстановление.
Совместно с клиентом фиксируем допустимую потерю данных во времени — RPO, и требуемое время восстановления критичных сервисов — RTO. Эти параметры определяют частоту копирования, архитектуру хранения и объём необходимых ресурсов.
Учитываем текущий объём данных, скорость роста, количество версий, срок хранения, типы резервных копий и необходимость нескольких экземпляров. Определяем, где должны находиться копии и как они будут создаваться, чтобы система не зависела от одного устройства или площадки.
Настраиваем автоматическое копирование файловых ресурсов, серверных данных или системы целиком. Для виртуальной инфраструктуры создаём резервные копии, позволяющие восстанавливать не только отдельные файлы, но и рабочие виртуальные машины.
Для 1С учитываем используемую архитектуру: подход к файловым и клиент-серверным базам может различаться. Для SQL Server настраиваем резервирование с учётом модели восстановления и необходимых типов копий — полных, дифференциальных и журналов транзакций.
При необходимости используем NAS, локальное резервное хранилище, отдельную удалённую площадку или облачное хранение. Схема подбирается с учётом объёма данных, безопасности, скорости каналов и необходимого времени восстановления.
Используем доступные средства шифрования, если резервные данные требуют дополнительной защиты. Для сценариев с вирусом-шифровальщиком ограничиваем одинаковую доступность рабочих данных и резервов и предусматриваем независимую, изолированную или удалённую копию.
Определяем периодичность создания копий и настраиваем контроль выполнения заданий. Подключаем уведомления об ошибках, чтобы неуспешное резервирование не оставалось незамеченным длительное время.
Восстанавливаем данные из резервной копии и проверяем их пригодность на практике. Фиксируем, что резервируется, где находятся копии, периодичность и сроки хранения, порядок контроля и основные действия при восстановлении.
ПРИМЕРЫ ЗАДАЧ
Рабочие данные → ежедневная автоматическая копия → локальное резервное хранилище → дополнительная удалённая или облачная копия. Отказ основного сервера не должен означать потерю единственного резерва.
SQL создаёт резервные копии базы и журналов по согласованному расписанию, копии переносятся в отдельное хранилище, выполнение заданий контролируется, а восстановление периодически проверяется на практике.
Виртуальные машины резервируются на отдельное хранилище, критичные данные дополнительно копируются вне основной площадки, затем проверяется возможность восстановления виртуальной машины.
Рабочий сервер и резервное хранилище не должны быть одинаково доступны с пользовательских учётных записей. В схему включается независимая, изолированная, защищённая от изменения или удалённая копия.
Филиалы создают копии критичных данных, резервные данные централизованно передаются на отдельную площадку, а состояние заданий контролируется из единой точки.
Фиксируем инцидент, определяем причину, выбираем последнюю подходящую копию, подготавливаем среду, восстанавливаем данные или систему, проверяем целостность и возвращаем сервис пользователям.
КАК ПРОХОДИТ РАБОТА
Изучаем существующие данные, серверы, базы, хранилища и текущую схему резервирования.
Фиксируем, какие системы необходимо восстановить в первую очередь.
Согласовываем допустимый объём потери данных для каждой критичной системы.
Фиксируем требуемое время восстановления.
Определяем объём, тип и количество площадок для резервных данных.
Выбираем способы копирования, периодичность и глубину хранения.
Разворачиваем программное обеспечение, хранилища и расписания.
Контролируем полное первоначальное резервирование.
Проверяем работоспособность копии на практике.
Подключаем контроль заданий и уведомления об ошибках.
Фиксируем документацию и при необходимости берём резервное копирование на постоянное сопровождение.
ЧТО ПОЛУЧАЕТ КЛИЕНТ
Настроенное резервирование согласованного объёма файлов, серверов, виртуальных машин, 1С и SQL с заданным расписанием.
Для ключевых систем определены допустимая потеря данных и требуемое время восстановления, на которых строится схема резервирования.
Настроены необходимые локальные, удалённые или облачные хранилища, глубина хранения и несколько экземпляров данных там, где это требуется.
При необходимости применяются шифрование и независимое хранение копий, чтобы резерв не был уязвим тем же способом, что и рабочая инфраструктура.
Выполнение заданий контролируется, а ошибки и неуспешные копирования не остаются незамеченными.
Проводится тестовое восстановление, подтверждающее, что резервная копия пригодна для реального возврата данных или системы в работу.
Зафиксировано, что и где резервируется, сроки хранения, порядок контроля и основные действия для восстановления после сбоя.
Заменили временные подключения на управляемую офисную сеть, разделили проводной и беспроводной трафик и устранили обрывы соединения.
Настроили единую корпоративную VPN-систему, которая автоматически направляет зарубежный трафик через защищённый сервер, а российские сервисы оставляет на прямом подключении.
Подключили два новых медицинских аппарата к действующей сети клиники, настроили защищённый обмен файлами и разграничение доступа без масштабной перестройки инфраструктуры.
Спроектировали и развернули серверную инфраструктуру для стабильной работы 1С ERP: разделили серверные роли, оптимизировали SQL, настроили терминальный доступ, резервное копирование и мониторинг.
Модернизация, после которой сеть кафе получила стабильную и отказоустойчивую IT-инфраструктуру, рассчитанную на ежедневную работу без простоев.
Переезд без остановки бизнеса: как перенести 1С из облака на собственный сервер
Стоимость настройки резервного копирования — от 30 000 ₽.
Оборудование, дисковое пространство, лицензии программ резервного копирования и облачные ресурсы рассчитываются отдельно.
На итоговую стоимость влияют:
Для предварительной оценки достаточно указать состав серверов и критичных систем, примерный объём данных и описать, как резервное копирование организовано сейчас.
ЧАСТЫЕ ВОПРОСЫ
Да. RAID помогает сохранить работоспособность при отказе отдельных дисков, но не является полноценной резервной копией. Он не защищает от случайного удаления, логического повреждения данных, вируса-шифровальщика, ошибки администратора или потери всего сервера.
Такую копию можно использовать как дополнительную для отдельных сценариев, но она не должна быть единственной. При отказе или компрометации сервера одновременно могут стать недоступны и рабочие данные, и резерв.
Провести восстановление. Проверка наличия или целостности файла сама по себе не подтверждает, что данные удастся вернуть в рабочее состояние.
Да. Настраиваем расписание и контроль выполнения заданий. При этом автоматизация не отменяет мониторинг: система должна сообщать о неуспешном копировании.
Да. Настраиваем резервирование файловых и клиент-серверных сценариев 1С, а также SQL Server. Для SQL стратегия зависит от модели восстановления базы и требований к допустимой потере данных.
Зависит от того, сколько данных компания готова потерять. Частота определяется на основе RPO для конкретной системы: если допустима потеря информации только за час, копирования раз в сутки недостаточно.
Единого числа нет. Количество версий и глубина хранения определяются объёмом данных, требованиями бизнеса и бюджетом. Для критичных систем желательно не хранить весь резерв только в одной физической точке.
Да. При выборе учитываем объём данных, скорость интернет-канала, стоимость хранения, безопасность и необходимое время восстановления.
Только если сама копия не будет уничтожена или зашифрована вместе с основной системой. Поэтому важно ограничивать доступ к резервному хранилищу и иметь независимую копию.
Да. Инфраструктура и объём данных меняются, поэтому разовый тест при первоначальной настройке не гарантирует работоспособность схемы в дальнейшем. Для критичных систем восстановление стоит проверять периодически.
Укажите состав серверов и критичных систем, примерный объём данных и расскажите, как резервное копирование организовано сейчас — этого достаточно для предварительной оценки.
