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

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

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

Именно поэтому копия на соседнем диске или постоянно подключенном накопителе не всегда обеспечивает достаточную защиту: одна авария или вредоносная программа может затронуть сразу несколько экземпляров. 

Один из классических подходов к резервированию — правило 3-2-1: иметь три экземпляра данных, использовать два разных типа хранения и держать хотя бы одну копию отдельно от основной инфраструктуры.

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

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

Зачем резервные копии переносят в облако

Отдельную инфраструктуру для хранения резервов необязательно создавать самостоятельно. Для этого существует BaaS (Backup-as-a-Service), когда резервное копирование предоставляется как облачная услуга. Такой подход позволяет отделить резерв от основной системы и не покупать дополнительные серверы и накопители по мере роста объема информации.

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

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

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

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

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

Главное — не создать копию, а суметь восстановить данные

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

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

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

Чтобы оценить собственную систему, полезно проверить несколько вещей: 

Такой подход меняет само отношение к бэкапам. Вместо вопроса «есть ли у нас резервная копия?» появляется более полезный: «что произойдет, если основные данные исчезнут прямо сейчас?».

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

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

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

Следите за нашими публикациями в Telegram на канале «Другой город» и ВКонтакте