Пока весь мир увлечённо контейнеризирует микросервисы и разворачивает Kubernetes-кластеры, в серверных комнатах тихо гудят физические серверы. На них крутятся базы 1С, почтовые серверы Exchange, боевые PostgreSQL-инстансы. И бэкапятся они часто при помощи самописного скрипта в cron, который «вроде работает». До первого шифровальщика. Само по себе расписание в crontab тут ни при чём - вопрос в том, что за такой задачей никто не следит.
Кибер Бэкап - система резервного копирования от компании «Киберпротект». Это бывшая линейка Acronis: после ухода Acronis с российского рынка в 2022 году продукт «Acronis Защита Данных» перешёл к «Киберпротекту» и был переименован. Сегодня он числится в реестре отечественного ПО как российский, сертифицирован ФСТЭК и поддерживает Astra Linux и «Альт». За вывесками импортозамещения скрывается вполне зрелый инструмент с серьёзной технической начинкой.
Разберём, что он умеет именно в разрезе физических серверов, чем Стандартная редакция отличается от Расширенной и как всё это настроить, чтобы бэкапы действительно спасали.
Виртуальные машины бэкапятся на уровне гипервизора - это удобно и быстро. С физическим сервером всё сложнее: нужен агент на самой машине, нужно корректно обработать открытые файлы и базы данных, а при восстановлении - учесть, что целевое железо может отличаться от исходного.
Кибер Бэкап решает эти задачи через несколько механизмов. Агент устанавливается прямо на сервер (Windows или Linux) и работает с дисками на блочном уровне. Технология Changed Block Tracking (CBT) отслеживает изменённые блоки между сеансами копирования - инкрементный бэкап сервера с терабайтами данных укладывается в минуты, а не в часы. Для консистентности данных агент использует VSS (Volume Shadow Copy) на Windows и собственные механизмы на Linux, чтобы снимок базы или почтового сервера был целостным.
Отдельная история - bare-metal restore и восстановление на отличающемся оборудовании (dissimilar hardware). Взяли бэкап со старого Dell PowerEdge, развернули на новый Supermicro - драйверы и загрузчик подтянутся автоматически. Для этого используется загрузочный носитель на базе Linux или WinPE: загружаете сервер с него, подключаетесь к хранилищу бэкапов, выбираете копию - и получаете рабочую систему на новом железе. Контроллеры RAID, сетевые карты, чипсет распознаются и подставляются.
А если нужно мигрировать физический сервер в виртуальную среду (P2V) или наоборот (V2P), Кибер Бэкап делает это через обычное восстановление резервной копии в нужную среду. Сценарий P2V особенно востребован при переезде с устаревшего железа: вместо того чтобы настраивать виртуалку с нуля, вы восстанавливаете бэкап физического сервера прямо в VMware, Proxmox или oVirt. Обратная миграция V2P пригодится, когда виртуалка упёрлась в потолок производительности гипервизора и пора переселять нагрузку на выделенный сервер.
Система поддерживает три классических типа резервного копирования, и выбор между ними - это баланс между скоростью, объёмом хранилища и временем восстановления.
| Параметр | Полный | Инкрементный | Дифференциальный |
|---|---|---|---|
| Что копирует | Все данные целиком | Изменения с последнего бэкапа любого типа | Изменения с последнего полного бэкапа |
| Размер копии | 100% данных | 1-5% от полного (типично) | 10-30% от полного (типично) |
| Скорость создания | Медленно | Быстро (CBT) | Средне |
| Скорость восстановления | Быстро (один файл) | Медленнее (цепочка) | Средне (два файла) |
| Зависимость | Нет | От всей цепочки | Только от полного |
CBT здесь - ключевая технология для физических серверов. Драйвер отслеживает изменённые блоки на уровне тома между сеансами копирования. Когда запускается инкрементный бэкап, агент уже знает, какие именно блоки изменились, и читает только их. На сервере с 4 ТБ данных и 50 ГБ суточных изменений разница между «копировать всё» и «копировать только изменённое» - это часы против минут.
Дополнительно работает дедупликация на узле хранения (сжатие повторяющихся блоков между бэкапами разных серверов) и сжатие данных при передаче. Коэффициент дедупликации для однотипных серверов с Windows может достигать 1:10 - десять серверов с похожей ОС и набором ПО занимают в хранилище место чуть больше одного полного бэкапа.
Общая теория по типам копирования и по тому, когда какой уместен, - в статье виды резервного копирования.
Скопировать файлы базы данных - это не бэкап базы. Если SQL Server в момент копирования пишет транзакцию, вы получите неконсистентный набор файлов, который не восстановится. Кибер Бэкап умеет работать с приложениями «изнутри».
Для MS SQL и Exchange агент использует VSS-провайдеры Microsoft - база замораживается на долю секунды, создаётся консистентный снимок, копирование идёт с него. Для PostgreSQL в Кибер Бэкап 18 появилось многопоточное полное копирование: несколько потоков параллельно читают данные, что заметно ускоряет бэкап крупных инстансов. Oracle поддерживается через RMAN-интеграцию, MongoDB - через mongodump с консистентным снимком.
Список поддерживаемых приложений этим не ограничивается: CommuniGate Pro, Active Directory, сервисы VK Workspace (Почта и Диск). Для почтовых серверов это означает восстановление отдельного ящика или даже конкретного письма, для AD - отдельного объекта без отката всей базы ntds.dit.
Pre/Post-скрипты дают возможность автоматизировать кастомную логику: остановить сервис перед бэкапом, сбросить кеш, проверить целостность после. Скрипты выполняются с правами агента, поддерживают любые shell-команды на Linux и PowerShell либо bat на Windows. Типичный сценарий - вызвать pg_dump для дополнительной логической копии перед блочным бэкапом или остановить очередь сообщений, чтобы не терять транзакции.
Гранулярное восстановление позволяет достать из бэкапа отдельную таблицу SQL или конкретное письмо из Exchange без восстановления всей базы. Для Exchange и CommuniGate Pro работает поиск по теме, отправителю и дате - не нужно монтировать весь почтовый архив ради одного сообщения.
Ш