Резервное копирование: 7 ошибок, которые обнаруживаются слишком поздно

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

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

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

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

Ошибка №1. RAID, синхронизацию и снимки считают полноценным резервным копированием

Это одна из самых распространённых ошибок при организации хранения корпоративных данных.

В компании устанавливают NAS с несколькими дисками, настраивают RAID и считают, что теперь файлы находятся в безопасности.

Но RAID решает прежде всего задачи доступности и, в зависимости от уровня, устойчивости к отказу определённого количества дисков. Он не заменяет независимые резервные копии.

Почему RAID не является backup

Предположим, на файловом сервере установлены четыре накопителя, объединённые в RAID 5.

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

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

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

Если шифровальщик получит доступ к файлам на сервере, RAID не помешает ему зашифровать данные.

Синхронизация тоже не всегда помогает

Другая распространённая схема — синхронизировать рабочую папку с другим компьютером, NAS или облачным хранилищем.

Синхронизация удобна для поддержания актуального состояния файлов на нескольких устройствах.

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

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

А как насчёт снимков файловой системы?

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

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

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

Ошибка №2. Все резервные копии находятся в одной зоне риска

Представим небольшую организацию.

Рабочие документы размещены на сервере, а резервные копии автоматически сохраняются на NAS, установленный в той же серверной стойке.

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

Но при серьёзном инциденте одновременно могут пострадать и основной сервер, и резервное хранилище.

Какие риски возникают

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

Особенно опасна ситуация, когда сервер резервного копирования, основной сервер и NAS администрируются одной учётной записью с широкими полномочиями.

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

Принцип 3-2-1

Один из распространённых подходов — стратегия резервного копирования 3-2-1.

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

При этом сама по себе схема 3-2-1 не гарантирует защиту от шифровальщиков.

Если все резервные копии доступны через одни и те же административные полномочия, они всё ещё могут оказаться уязвимыми.

Изоляция резервных копий

Для критичных данных желательно предусмотреть дополнительную защиту: отключаемые носители, изолированное хранилище или неизменяемые резервные копии.

Неизменяемость, или immutability, ограничивает возможность изменения и удаления сохранённых резервных данных в течение установленного периода.

Эффективность этого механизма зависит от конкретной реализации, настроек хранения и защиты административных полномочий.

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

Рекомендации по изолированным копиям и восстановлению после атак приведены в руководстве CISA по противодействию шифровальщикам.

Ошибка №3. Копируется не всё, что действительно нужно компании

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

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

После аварии обнаруживается, что восстановить файловую папку можно, а полноценную работу компании — нет.

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

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

Не забывайте о файлах вне основных серверов

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

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

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

Облачные данные тоже требуют внимания

Использование облачной почты или онлайн-хранилища не освобождает организацию от необходимости определить свою стратегию восстановления.

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

Отдельный вопрос — ключи и пароли

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

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

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

Ошибка №4. Копирование выполняется без учёта работающих баз данных

Обычное файловое копирование не всегда подходит для активно работающих информационных систем.

Например, база данных может изменяться непосредственно во время создания резервной копии.

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

Особенно важно для 1С

Способ резервирования 1С зависит от архитектуры информационной базы.

В файловом варианте данные хранятся в файле 1Cv8.1CD.

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

Другой предусмотренный платформой способ — выгрузка информационной базы в файл .dt с соблюдением требований соответствующей версии.

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

Это особенно важно, если компания использует Microsoft SQL Server или PostgreSQL.

Подробности: методические рекомендации 1С по резервному копированию информационных баз.

Резервирование виртуальных машин

Похожая проблема может возникать при резервном копировании работающих виртуальных машин.

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

Поэтому простое копирование файлов виртуального диска не следует автоматически считать корректной резервной копией.

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

Для приложений, требующих специальной обработки данных, следует предусмотреть application-aware backup или другие поддерживаемые производителем процедуры.

Проверяйте не только запуск системы

После восстановления виртуальная машина может успешно загрузить Windows, но это ещё не подтверждает работоспособность размещённой на ней базы.

Необходимо проверять основные прикладные сервисы, состояние данных и выполнение контрольных операций.

Ошибка №5. Резервные копии есть, но нужная версия уже удалена

Наличие ежедневного backup не гарантирует защиту от ошибок, которые обнаруживаются через несколько дней или недель.

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

Проблему заметили только в следующем месяце.

Если система сохраняет только несколько последних ежедневных копий, исходная версия документа к этому времени может быть уже удалена.

Аналогичная ситуация возможна, когда незамеченная ошибка приложения постепенно повреждает данные или вредоносное ПО остаётся в инфраструктуре до обнаружения инцидента.

Зачем нужна политика хранения

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

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

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

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

Не путайте сроки хранения с частотой копирования

Ежедневное копирование определяет, как часто создаются новые точки восстановления.

Политика хранения определяет, как долго они остаются доступными.

Оба параметра необходимо настраивать совместно.

Контролируйте свободное место

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

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

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

Ошибка №6. Никто не контролирует резервное копирование

Автоматизация необходима, но сама по себе не гарантирует работоспособность backup.

Нередко задания настраиваются один раз, после чего администратор перестаёт регулярно проверять их фактическое выполнение.

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

Какие события необходимо контролировать

• Задание резервного копирования завершилось ошибкой.
• Запланированное задание вообще не запускалось.
• Последняя успешная копия слишком старая.
• Размер новой копии необычно изменился.
• Время выполнения значительно увеличилось.
• Заканчивается свободное место в хранилище.
• Не удаётся передать вторичную копию.
• Изменились настройки или сроки хранения.
• Появились подозрительные попытки удаления архивов.

Почему одного зелёного статуса недостаточно

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

Например, администратор перенёс базу данных на другой сервер, но не изменил состав резервируемых объектов.

Формально задание продолжит работать, однако новая база не будет защищена.

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

Уведомления должны приходить ответственному сотруднику

Сообщения об ошибках не должны оставаться только в локальном журнале программы.

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

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

Ошибка №7. Восстановление никогда не проверяли

Самая неприятная ошибка обнаруживается обычно в тот момент, когда основной сервер уже недоступен.

Резервные архивы существуют, но никто не знает, как именно восстановить из них работоспособную систему.

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

Что такое проверка восстановления

Это не просто открытие каталога с резервными копиями.

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

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

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

Для виртуальной инфраструктуры — проверить запуск восстановленной системы и работоспособность зависимых сервисов.

Проверяйте восстановление в изолированной среде

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

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

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

Проверяйте разные виды восстановления

• Восстановление отдельного случайно удалённого файла.
• Восстановление предыдущей версии документа.
• Восстановление информационной базы 1С.
• Восстановление виртуальной машины.
• Восстановление данных при недоступности основного NAS.
• Восстановление после полной потери основного сервера.

Периодичность проверок следует выбирать с учётом критичности систем и допустимого времени простоя.

После значимых изменений инфраструктуры необходимо повторно проверять затронутые процедуры восстановления.

RPO и RTO: сколько данных компания может потерять и как долго ждать восстановления

При проектировании резервного копирования полезно определить два ключевых показателя: RPO и RTO.

RPO — допустимая потеря данных во времени

Recovery Point Objective показывает, к какому моменту времени должна быть возможность восстановить данные после аварии.

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

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

RTO — допустимое время восстановления

Recovery Time Objective определяет, за какой период необходимо восстановить работоспособность системы после её недоступности.

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

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

Значения RPO и RTO определяются совместно с владельцами бизнес-процессов.

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

Термины и подходы рассмотрены в руководстве NIST по планированию восстановления.

Как может выглядеть резервное копирование небольшой компании

Рассмотрим условную организацию, в которой используются Windows Server, сетевая папка сотрудников, бухгалтерская база 1С и NAS для хранения резервных копий.

Одна из возможных архитектур может включать несколько уровней защиты.

Первый уровень: резервирование рабочих систем

Настраивается резервное копирование файлов, виртуальных машин и информационных баз.

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

Второй уровень: локальное хранилище

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

Доступ пользователей к архивам ограничивается.

Третий уровень: изолированная копия

Дополнительный экземпляр размещается вне основной зоны риска и защищается от несанкционированного изменения и удаления.

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

Четвёртый уровень: контроль и восстановление

Ответственный специалист контролирует выполнение заданий, состояние носителей и актуальность копий.

По согласованному расписанию выполняются проверки восстановления критичных систем.

Конкретная схема зависит от бюджета организации, объёма данных, требований безопасности и согласованных RPO/RTO.

Что делать, если резервные копии давно никто не проверял

Если backup уже настроен, но отсутствует уверенность в его работоспособности, необязательно сразу заменять всю систему.

Сначала необходимо провести обследование существующей инфраструктуры и определить реальные риски.

Этап 1. Инвентаризация

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

Сопоставьте этот перечень с действующими заданиями резервного копирования.

Этап 2. Проверка хранилищ

Установите, где физически находятся копии, кто имеет к ним доступ и что произойдёт при потере основного оборудования.

Этап 3. Проверка актуальности

Определите дату последней успешной копии каждой критичной системы.

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

Этап 4. Выборочное восстановление

Восстановите несколько важных файлов и одну или несколько критичных систем в подходящей тестовой среде.

Документируйте результаты и фактическое время восстановления.

Этап 5. Устранение обнаруженных проблем

По результатам проверки скорректируйте расписание, область резервирования, политику хранения и схему изоляции копий.

Чек-лист: семь ошибок резервного копирования

Частые вопросы о резервном копировании

Достаточно ли одного NAS с RAID 5 или RAID 6?

Нет. RAID может повысить устойчивость хранилища к определённым отказам дисков, но не заменяет резервные копии на независимых носителях или в отдельной среде.

Если файлы синхронизируются с облаком, нужен ли backup?

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

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

Можно ли хранить все копии на одном внешнем USB-диске?

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

Для важных данных необходимо предусмотреть дополнительные экземпляры и защиту от потери носителя.

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

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

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

Нужно ли шифровать резервные копии?

Для архивов, содержащих конфиденциальные и персональные данные, шифрование является важным механизмом защиты.

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

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

Когда необходим аудит системы резервного копирования

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

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

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

Подробнее о подходе WEB-LABS к защите корпоративных данных — на странице «Защита данных и резервное копирование».

Вывод

Самая опасная ошибка резервного копирования — считать наличие архивов достаточным доказательством защищённости данных.

RAID, синхронизация и локальные снимки решают полезные задачи, но не заменяют полноценную систему backup.

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

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

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