О резервном копировании обычно вспоминают в двух случаях: когда заканчивается место на сервере или когда данные уже пропали. Во втором случае обсуждать схему хранения поздно — остаётся только выяснять, сохранилась ли хоть одна рабочая копия.
Проблема в том, что сам факт существования бэкапа ещё ничего не гарантирует. Копия может лежать на том же сервере, оказаться недоступной после поломки хранилища или быть зашифрована вместе с основной инфраструктурой. А задание, которое несколько месяцев завершалось с ошибкой, иногда обнаруживают только в день восстановления.
Клиенту требовалось надёжное резервное копирование серверной инфраструктуры: быстрое локальное восстановление внутри офиса и дополнительная копия на удалённой площадке. Мы построили многоуровневую схему на базе Veeam Backup & Replication, сетевого хранилища Synology и Google Cloud.
Что было у клиента
Серверная инфраструктура работала на Microsoft Windows Server 2019. Для виртуализации использовался Microsoft Hyper-V.
Также у клиента уже было сетевое хранилище Synology. Вместо покупки ещё одного устройства мы включили его в новую схему, предварительно подготовив для изолированного и безопасного хранения резервных копий.
Исходные условия позволяли решить задачу без полной замены инфраструктуры. Нужно было правильно распределить роли между существующим NAS, программой резервного копирования и облачным хранилищем.
Почему одной копии недостаточно
Локальный бэкап удобен прежде всего скоростью. Если нужно восстановить виртуальную машину или данные после ошибки, копию не приходится скачивать через интернет.
Но локальное хранение не защищает от всех сценариев:
- аварии, которая затронула серверную и хранилище;
- кражи или физического повреждения оборудования;
- ошибки конфигурации;
- вредоносного ПО, получившего доступ к сетевым ресурсам;
- шифровальщика, который добрался не только до серверов, но и до доступных резервных копий.
Поэтому локальный NAS стал одним из уровней, а не единственным местом хранения. Дополнительную копию мы вынесли в Google Cloud Bucket.
Первый уровень: Veeam Backup & Replication
Veeam Backup & Replication отвечает за создание резервных копий серверной инфраструктуры. Мы подготовили окружение, установили и настроили решение, а затем создали задания резервного копирования для виртуальных машин Hyper-V.
На этом этапе важно не ограничиваться кнопкой «создать задание». Нужно определить:
- какие виртуальные машины и данные входят в резервное копирование;
- как часто запускаются задания;
- сколько точек восстановления хранится;
- куда записываются копии;
- что происходит при ошибке;
- хватает ли хранилищу места на заданную глубину хранения.
Параметры должны соответствовать бизнес-задаче. Если данные меняются постоянно, редкий бэкап создаёт слишком большое окно потерь. Если хранить слишком много копий без расчёта объёма, место закончится и новые задания перестанут выполняться.
Второй уровень: изолированное хранилище Synology
Имеющийся Synology NAS подготовили как отдельное хранилище для бэкапов Veeam. Настроили доступ и разделили роли так, чтобы резервные копии не лежали рядом с рабочими данными на тех же виртуальных машинах.
Изоляция здесь не менее важна, чем объём дисков. Если к папке с бэкапами имеют доступ все серверы и пользователи, злоумышленнику или шифровальщику проще уничтожить и оригиналы, и копии.
Локальное хранилище даёт клиенту быстрый первый сценарий восстановления. При обычном сбое не нужно ждать загрузки большого объёма данных из облака — копия находится внутри инфраструктуры.
Третий уровень: Google Cloud
Для защиты от событий, которые могут затронуть весь офис, подготовили Google Cloud Bucket. Связь между Synology и облачным хранилищем настроили через Hyper Backup — приложение Synology для резервного копирования.
В результате дополнительная копия уходит за пределы основной площадки. Даже если локальные серверы и NAS одновременно окажутся недоступны, данные не будут существовать только в одной физической точке.
Удалённая копия не заменяет локальную: восстановление большого объёма из облака обычно занимает больше времени и зависит от канала связи. Поэтому эти уровни дополняют друг друга:
- Veeam управляет резервным копированием виртуальной инфраструктуры;
- Synology хранит локальные копии для быстрого восстановления;
- Google Cloud сохраняет дополнительную копию вне офиса.
Мониторинг: бэкап должен не только запускаться
Одна из самых неприятных ситуаций — годами платить за хранилище и в момент аварии узнать, что последнее успешное задание выполнялось несколько месяцев назад.
Чтобы этого не произошло, мы настроили мониторинг заданий и уведомления о неудачном выполнении. Если резервное копирование завершается с ошибкой, информация об этом поступает специалистам, и проблему можно исправить до того, как копия понадобится.
Само уведомление ещё не является проверкой восстановления, но закрывает важный риск: незаметную остановку заданий из-за нехватки места, проблем с доступом или другой технической ошибки.
Что сделали
В рамках проекта мы:
- подготовили серверную инфраструктуру к резервному копированию;
- установили и настроили Veeam Backup & Replication;
- создали задания резервного копирования для среды Hyper-V;
- подготовили Synology NAS для изолированного хранения бэкапов;
- развернули облачное хранилище в Google Cloud;
- настроили передачу дополнительной копии через Synology Hyper Backup;
- внедрили мониторинг заданий и уведомления об ошибках.
Клиент получил несколько независимых уровней защиты данных. Локальная копия позволяет быстрее реагировать на обычные сбои, удалённая снижает риск потери данных при проблеме на всей площадке, а мониторинг помогает вовремя заметить, что очередной бэкап не был создан.
Что стоит проверить в своей компании
Если в компании уже «есть бэкапы», задайте ответственному специалисту несколько конкретных вопросов:
- где физически находятся копии;
- отделены ли они от основной инфраструктуры;
- есть ли копия за пределами офиса;
- кто получает уведомления об ошибках;
- когда последнее задание завершилось успешно;
- выполнялось ли тестовое восстановление;
- сколько времени займёт возврат к работе.
Если на эти вопросы нет быстрых и понятных ответов, резервное копирование лучше проверить заранее. После сбоя, удаления данных или атаки шифровальщика времени на проектирование уже не будет.
