Серверы и виртуальные машины
Копируем машины целиком на уровне гипервизора. Восстановление возвращает сервер в рабочее состояние вместе с настройками, а не только файлы с него.
Proxmox Backup Server с инкрементальными копиями и дедупликацией.
Настраиваем резервное копирование серверов, баз 1С, файлов и конфигураций оборудования по схеме 3-2-1 — так, чтобы копия действительно восстанавливалась, а аварийное восстановление занимало известное время. Расписание, уведомления об ошибках, хранение вне основной площадки и регулярные проверки восстановления.
Типичная картина: копирование когда-то настроили, галочка в планировщике стоит, все спокойны. А когда копия действительно понадобилась, выясняется, что задание падало с ошибкой полгода, места на диске давно нет, копия лежит на том же сервере, который сгорел, или в архиве нет самого главного — базы 1С, которую однажды перенесли в другую папку.
Резервное копирование — это не «включить копирование». Это работающая система: что копируем, куда, как часто, сколько храним, кто узнаёт об ошибке и как быстро мы поднимемся, если сервера завтра не станет.
Копируем машины целиком на уровне гипервизора. Восстановление возвращает сервер в рабочее состояние вместе с настройками, а не только файлы с него.
Proxmox Backup Server с инкрементальными копиями и дедупликацией.
Настраиваем выгрузку баз средствами самой СУБД, а не копированием файлов на ходу. Для клиент-серверного варианта — по расписанию, с журналом транзакций там, где нужна точка восстановления в течение дня.
Копия файла работающей базы часто оказывается непригодной.
Общие папки, документы, архивы проектов. Настраиваем версионность, чтобы можно было вернуть файл в состоянии на прошлую неделю, а не только последнюю версию.
Отдельно закрываем сценарий «сотрудник удалил папку и никто не заметил».
Выгружаем настройки маршрутизаторов, коммутаторов, точек доступа и видеорегистраторов. При замене вышедшего из строя устройства конфигурация заливается за минуты.
Иначе сеть после отказа роутера настраивается заново по памяти.
Архив корпоративной почты, портал, CRM, внутренние системы. Проверяем, что копия включает не только данные, но и то, что нужно для запуска сервиса.
База без конфигурации — половина восстановления.
Для терминальных серверов и виртуальных рабочих мест копируем профили пользователей и их данные, чтобы восстановление сотрудника было рутиной, а не спасательной операцией.
Данные с личных ноутбуков защитить нельзя — их там быть не должно.
Хранилище под копии всегда больше объёма данных: помимо полной копии хранятся изменения за весь период глубины хранения. Прикиньте порядок цифр, а точный расчёт сделаем по вашим данным.
Суммарно по всем серверам, базам и файловым хранилищам. Если точной цифры нет — возьмите с запасом.
От этого зависит размер ежедневных изменений, которые копятся в хранилище.
Насколько глубоко нужно откатываться. Заражение шифровальщиком иногда обнаруживают через недели.
Оценка с учётом дедупликации и инкрементальных копий. Реальный объём зависит от характера данных — уточняем после разбора.
Правило 3-2-1 звучит абстрактно, пока не разложить его на конкретные площадки. Вот как оно выглядит на практике у среднего бизнеса.
| Копия | Где лежит | От чего защищает |
|---|---|---|
| Рабочие данные | Основной сервер компании | Ни от чего — это оригинал, а не копия. Считать RAID резервной копией нельзя: он спасает от отказа диска, но не от удаления файла и не от шифровальщика |
| Первая копия | Отдельный сервер или NAS на той же площадке | Отказ основного сервера, случайное удаление, неудачное обновление. Восстановление быстрое — данные рядом |
| Вторая копия | Другая площадка: инфраструктура Dinesco, ЦОД или облако | Пожар, залив, кража оборудования, шифровальщик, дошедший до хранилища копий. Восстановление дольше, но данные точно живы |
Отдельный сценарий — неизменяемые копии. Современные шифровальщики целенаправленно ищут и уничтожают резервные копии, поэтому для критичных данных мы настраиваем хранение, при котором копию нельзя удалить или перезаписать до истечения срока даже с правами администратора.
Вторая копия уезжает на нашу площадку. Не нужно покупать отдельное хранилище и искать, где его разместить, а копия физически находится не там же, где ваш сервер.
Самый простой способ закрыть требование «одна копия вне площадки».
Проектируем и настраиваем резервное копирование на вашем оборудовании: отдельный сервер копий, NAS, ленточная библиотека или облако по вашему выбору.
Подходит, когда данные не должны покидать контур компании.
Схема резервного копирования зависит от того, сколько данных и сколько площадок нужно закрыть. Ниже три размера — и во всех копия считается настроенной только после успешного восстановления.
Главное на этом размере — чтобы копия не лежала на том же диске, что и оригинал. Данные уезжают на отдельное устройство по расписанию, а восстановление проверяется вручную после настройки.
Сервер или рабочие места
│ по расписанию
Отдельное хранилище (NAS)
├─ Копии базы 1С
├─ Копии файлов
└─ Конфигурации сети
│
Проверка восстановления
Локальная копия спасает от отказа диска, но не от пожара, залива или шифровальщика. Появляется вторая копия за пределами офиса и защита от изменения: свежие копии нельзя перезаписать из основной сети.
Серверы и виртуальные машины
│
Локальное хранилище копий
│ быстрое восстановление
├──→ Копия вне офиса
│
Защита копий от перезаписи
│
Отчёты об успешности заданий
На нескольких площадках и десятках машин ручной контроль перестаёт работать. Задания централизуются, копии разъезжаются по площадкам, а восстановление проверяется регулярно на изолированном стенде, а не в момент аварии.
Площадка 1 Площадка 2
│ │
Локальные копии Локальные копии
└──── обмен копиями ────┘
│
Централизованное управление
│
Тестовое восстановление на стенде
Виртуализация со снапшотами и собственным сервером резервного копирования.
Подробнее →
Контроль выполнения заданий, свободного места и доступности сервисов.
Подробнее →
Защита хранилища копий от шифровальщиков и разграничение доступа.
Подробнее →Столько раз в сутки, сколько данных вы готовы потерять. Для бухгалтерии обычно достаточно ночной копии: потеря одного дня неприятна, но переживаема. Для активной торговли или производственного учёта копии снимаются несколько раз в день, а для критичных баз дополнительно ведётся журнал транзакций, позволяющий восстановиться на любой момент.
Нет. RAID защищает только от физического отказа диска. От удаления файла, повреждения базы, ошибки обновления и шифровальщика он не спасает — все изменения мгновенно попадают на все диски массива. RAID и резервное копирование решают разные задачи и нужны оба.
Больше, чем объём самих данных: хранится полная копия плюс изменения за весь период глубины хранения. Инкрементальные копии и дедупликация заметно снижают аппетит. Ориентир можно прикинуть в калькуляторе выше, точный расчёт делаем по реальным данным.
Да, и как вторая копия вне площадки это удобно. Важно учитывать два момента: восстановление большого объёма из облака занимает время, ограниченное шириной канала, и данные должны передаваться и храниться в зашифрованном виде. Если есть требования к месту хранения данных, подбираем российскую площадку.
Да, это обязательная часть работ. После настройки мы поднимаем копию в изолированной среде и убеждаемся, что сервис запускается и данные на месте. При сопровождении такие проверки повторяются регулярно, а результат фиксируется — вместе со временем, которое занимает восстановление.
Да, это частый запрос и разумный первый шаг. Смотрим, что реально копируется, куда, за какой период, выполняются ли задания без ошибок и восстанавливается ли копия. По итогам даём список замечаний с приоритетами — иногда достаточно донастройки.
Расскажите, что нужно защитить и что уже настроено. Предложим схему и посчитаем хранилище.
Хорошая система копирования отвечает на два вопроса, и оба задаёт бизнес, а не ИТ. Первый: сколько данных мы готовы потерять? Если копия снимается раз в сутки ночью, то авария в пять вечера стоит компании рабочего дня всех сотрудников. Второй: сколько времени мы готовы стоять? Восстановление виртуальной машины с локального хранилища — это десятки минут, выгрузка терабайта из облака — часы. Ответы на эти два вопроса определяют всю конструкцию: частоту, место хранения и бюджет.
Самое частое заблуждение. Зеркалирование дисков защищает от отказа диска — и только. Если файл удалили, база повредилась при некорректном выключении или шифровальщик прошёлся по общим папкам, RAID добросовестно продублирует это на все диски массива. Такие случаи в нашей практике встречаются регулярно: сервер с зеркалом, все спокойны, а восстанавливать нечего.
Скопировать файл базы, пока с ней работают пользователи, — значит получить архив в неопределённом состоянии. Иногда он открывается, иногда нет, и узнаёте вы об этом в худший момент. Правильный путь — выгрузка средствами СУБД: для клиент-серверного варианта это дамп базы по расписанию, для файлового — выгрузка после завершения работы или через копию виртуальной машины с корректным замораживанием состояния. Подробнее о том, как устроен сервер 1С, — на отдельной странице.
Современное вредоносное ПО перед шифрованием данных ищет и уничтожает резервные копии — сетевые папки с архивами, подключённые диски, доступные хранилища. Поэтому хранилище копий не должно быть просто общей папкой на сервере с правами на запись у всех. Мы разделяем сети, ограничиваем доступ к хранилищу, а для критичных данных настраиваем неизменяемые копии, которые нельзя удалить до истечения срока хранения. Это часть работ по информационной безопасности.
Задание, которое падает молча, хуже отсутствия задания: оно создаёт ложное спокойствие. Мы настраиваем уведомления об ошибках и подключаем задания копирования к мониторингу, чтобы контролировать не только сам факт запуска, но и свободное место в хранилище — оно заканчивается предсказуемо и всегда не вовремя.
Единственное доказательство работоспособности копии — успешное восстановление. Мы поднимаем копию в изолированной среде, запускаем сервис, проверяем целостность данных и фиксируем время, которое на это ушло. Так у компании появляется честный ответ на вопрос «за сколько мы поднимемся», а не предположение. В рамках сопровождения такие проверки проводятся регулярно.