Почти в каждой организации на вопрос о резервном копировании можно услышать: «Да, у нас всё копируется».
Проблема обычно обнаруживается позже — когда данные действительно нужно восстановить. Оказывается, что резервная копия находится на том же диске, задача копирования несколько месяцев завершалась с ошибкой, NAS недоступен, облачная синхронизация уже успела удалить нужный файл, а последняя рабочая версия базы была неделю назад.
Сам факт наличия файлов на другом диске или в отдельной папке ещё не гарантирует, что после сбоя ими действительно получится воспользоваться.
Что вообще считать резервной копией
Резервное копирование — это не просто создание второго экземпляра файла. Это организованный процесс, который позволяет вернуть данные в рабочее состояние после удаления, повреждения оборудования, ошибки пользователя, программного сбоя или инцидента информационной безопасности.
У нормальной системы резервного копирования есть несколько обязательных составляющих:
- понятно, какие данные необходимо сохранять;
- копирование выполняется регулярно и автоматически;
- есть несколько версий данных;
- копия физически или логически отделена от исходной системы;
- ошибки резервного копирования контролируются;
- восстановление периодически проверяется.
Копия на том же компьютере — плохая страховка
Одна из самых распространённых схем выглядит просто: на компьютере есть папка с рабочими данными, а рядом — папка «Backup».
Иногда её даже размещают на другом разделе того же физического SSD или жёсткого диска. Пользователь видит два диска — например C: и D: — и считает, что данные защищены.
Но если оба раздела находятся на одном физическом накопителе, его поломка уничтожит и исходные данные, и копию одновременно.
Тот же принцип относится к внешнему диску, который постоянно подключён к тому же компьютеру. Он защищает от отказа основного накопителя, но остаётся доступным операционной системе и вредоносным программам.
Если C: и D: находятся на одном физическом накопителе, отказ SSD или HDD способен уничтожить оба раздела одновременно.
Синхронизация — это не резервное копирование
OneDrive, Google Drive, Synology Drive и другие системы синхронизации очень удобны. Файлы автоматически появляются на нескольких устройствах, а сотрудники получают доступ к актуальной версии документов.
Но сама по себе синхронизация решает другую задачу: она поддерживает одинаковое состояние данных в нескольких местах.
Если пользователь случайно удалил файл, синхронизация может распространить это удаление на остальные устройства.
Если документ был повреждён или зашифрован вредоносной программой, новая повреждённая версия тоже может синхронизироваться.
Синхронизация удобна для ежедневной работы, а резервное копирование должно сохранять независимые версии, позволяющие вернуться к состоянию данных до ошибки или инцидента.
RAID тоже не заменяет backup
На серверах и NAS часто используется RAID. Он позволяет продолжить работу при отказе одного накопителя в конфигурациях, где предусмотрена избыточность.
Это полезный механизм повышения доступности системы, но он не является полноценной резервной копией.
Если пользователь удалит файл, он исчезнет со всего массива. Если база данных будет повреждена, RAID сохранит повреждённые данные. Если вредоносная программа зашифрует файлы, массив исправно запишет зашифрованные версии на все участвующие диски.
RAID помогает пережить отказ накопителя. Backup помогает вернуть данные. Это разные задачи.
Правило 3-2-1
Один из классических подходов к организации резервного копирования — правило 3-2-1.
Иметь как минимум три экземпляра данных: рабочий и две резервные копии.
Использовать как минимум два независимых типа или места хранения.
Как минимум одну копию хранить отдельно от основной инфраструктуры.
Это не единственно возможная схема и не универсальный рецепт для каждой организации, но она хорошо показывает главный принцип: все экземпляры данных не должны зависеть от одной точки отказа.
Что именно нужно резервировать
Одна из частых ошибок — настроить копирование отдельных документов и забыть обо всём остальном, что требуется для восстановления работы организации.
В зависимости от инфраструктуры резервное копирование может включать:
- рабочие документы сотрудников;
- базы 1С и других информационных систем;
- файловые ресурсы серверов;
- виртуальные машины;
- базы данных;
- конфигурации серверов и сетевого оборудования;
- корпоративную почту;
- данные внутренних web-сервисов;
- критичную техническую документацию.
При этом нет необходимости бесконечно копировать абсолютно всё. Сначала нужно определить, какие данные действительно критичны для продолжения работы организации.
Как часто нужно создавать резервные копии
Ответ «раз в сутки» подходит не всем. Частота резервного копирования должна зависеть от того, сколько данных организация готова потерять при аварии.
Если база меняется постоянно и потеря рабочего дня недопустима, копирование только один раз ночью может быть недостаточным.
Для файлового архива, который изменяется несколько раз в месяц, наоборот, нет смысла выполнять тяжёлое полное копирование каждые десять минут.
Если система выйдет из строя прямо сейчас, данные за какой период организация реально может позволить себе потерять: десять минут, час, день или неделю?
История версий важнее одной последней копии
Если система каждый день перезаписывает одну и ту же резервную копию, ошибка может долго оставаться незамеченной.
Например, важный документ был повреждён в понедельник, но проблему обнаружили только в пятницу. Если все старые версии уже удалены, «актуальная резервная копия» содержит тот же повреждённый файл.
Поэтому хорошая система backup хранит несколько точек восстановления: например, ежедневные, недельные и более старые версии в зависимости от задач организации и доступного места.
Шифровальщики меняют требования к резервному копированию
Резервное хранилище, постоянно доступное с теми же учётными данными, что и рабочая система, может оказаться уязвимым вместе с ней.
При серьёзном инциденте атакующий может попытаться удалить или зашифровать не только рабочие данные, но и доступные резервные копии.
Поэтому для важных данных полезно предусматривать копию, которую нельзя просто изменить из обычной рабочей среды: например, отдельное хранилище с другим уровнем доступа, неизменяемые версии или периодически отключаемый носитель.
Если одна скомпрометированная учётная запись позволяет удалить и рабочие данные, и все резервные копии, система резервирования имеет серьёзную единую точку отказа.
Самая забываемая часть — проверка восстановления
Программа резервного копирования может месяцами показывать зелёный статус. Но окончательно понять, работает ли система, можно только одним способом: попробовать что-нибудь восстановить.
Проверка может быть простой: выбрать несколько файлов и восстановить их в тестовую папку.
Для критичных систем полезно периодически проверять более полный сценарий: например, восстановление базы данных или виртуальной машины в изолированную среду.
Фраза «backup сегодня успешно выполнен» полезна. Но ещё полезнее знать: «мы действительно восстанавливали данные из этой системы и убедились, что они читаются».
Типовые ошибки резервного копирования
Резервная копия не хранится на том же физическом диске.
Синхронизация файлов не используется как единственный backup.
RAID не считается заменой резервному копированию.
Система хранит несколько предыдущих версий данных.
Ошибки задания резервного копирования кто-то контролирует.
Критичные данные копируются с подходящей периодичностью.
Хотя бы одна копия отделена от основной инфраструктуры.
Восстановление данных периодически проверяется на практике.
С чего начать небольшой организации
Резервное копирование не обязательно начинать с покупки сложной и дорогой корпоративной системы.
Сначала необходимо составить список действительно важных данных и понять, где они находятся.
После этого можно определить допустимый объём потери данных, период хранения предыдущих версий и время, за которое систему необходимо вернуть в работу.
Для небольшой инфраструктуры практическая схема может включать, например, автоматическое резервное копирование рабочих данных на отдельный NAS, хранение истории версий и дополнительную копию критичных данных в отдельном расположении.
Для более сложной инфраструктуры подход расширяется: резервируются серверы, виртуальные машины, базы данных, облачные сервисы и конфигурации оборудования.
Хороший backup обычно незаметен — пока не становится нужен
Резервное копирование редко является самой заметной частью IT-инфраструктуры. Оно не ускоряет компьютер сотрудника, не делает сеть визуально красивее и почти не участвует в ежедневной работе.
Поэтому к нему легко относиться по остаточному принципу.
Но в момент серьёзного сбоя именно наличие рабочей резервной копии может определить разницу между несколькими часами восстановления и полной потерей важных данных.
Поэтому главный вопрос не в том, существует ли где-то папка с названием Backup.
Главный вопрос звучит иначе: сможем ли мы восстановить из неё работу организации тогда, когда это действительно понадобится?