Алло, у нас всё пропало!

— У нас всё пропало!
— А вы делали бэкапы?
— Конечно! Каждый день!
— Отлично. Тогда восстановим. Где они?
— Ну… в той же папке. Но её же и удалили…

А вот короткий, но жизненный:

Бэкап есть.
Проверки бэкапа нет.
Надежда — сильная вещь.

Что такое бэкап в enterprise?

Это резервное копирование большого объёма данных, которое:

• работает на уровне СХД или виртуализации (а не просто копирует файлики);
• интегрировано в бизнес-процессы (например, ежедневный бэкап баз данных, ВМ, CRM и т.д.);
• обеспечивает быстрое восстановление даже при полном падении инфраструктуры.
  
  Компоненты бэкапа в СХД/Enterprise

1. Источник данных

• Файловые сервера (NAS)
• Блочные тома (SAN, LUN)
• Виртуалки (VMware, Hyper-V, Proxmox)
• БД: Oracle, MSSQL, PostgreSQL и др.
• Почта, 1С, CRM и т.д.

2. Снапшоты на уровне СХД

• Делают снимки данных без нагрузки на систему.
• Используются для создания "замороженного" состояния тома перед копированием.
• Умеют: ZFS, NetApp, Dell EMC, HPE 3PAR, Huawei OceanStor и др.

3. Бэкап-сервер

• Управляет задачами копирования и восстановления.
• Примеры: Veeam, Commvault, Veritas NetBackup, Acronis Cyber Protect, Bacula (про Русских буду писать отдельно)

4. Цель хранения (backup target)

• Локальное хранилище (диски, ленточные библиотеки, NAS).
• Облако (S3, Azure, Google Cloud).
• Cold storage (ленты, оффлайн диски).
• Часто используется deduplication storage — экономия места.

5. Каталог метаданных

• Чтобы восстановить, нужна не только копия данных, но и знание структуры.
• Хранят, где лежит что, когда была копия, кто делал.

Поток работы (типичный):

1. СХД или гипервизор создаёт снапшот;
2. Бэкап-сервер запускает копирование с этого снапшота;
3. Данные шифруются, дедуплицируются и пишутся в хранилище;
4. Журналируются: дата, версия, пользователь;
5. Периодически проверяются (health-check + restore test).
   

Best practices (то, что реально работает)

• Стратегия 3-2-1: 3 копии, 2 разных носителя, 1 — вне основного ЦОД.
• Immutable storage — копии, которые нельзя удалить.
• Тест восстановления раз в месяц (и отчёт).
• Мониторинг задач бэкапа — всё логируется, оповещения по сбоям.
• Автоматическая очистка старья, чтобы не забивались тома.
  
  Коротко:

В enterprise бэкап — это не архив.
Это способ восстановить бизнес за часы, а не за недели.

Еще раз -

Как это устроено:

1. Основные данные — это виртуальные машины (например, на VMware, Hyper-V, Proxmox), базы данных, приложения типа 1С, CRM, почта и документы. Все они хранятся на системах хранения данных — таких как NetApp, ZFS, Dell EMC, HPE 3PAR и другие.
2. СХД делает регулярные снапшоты — моментальные снимки состояния данных. Это позволяет зафиксировать «замороженное» состояние без остановки работы систем. В случае изменения данных, снапшот сохраняет только дельту (изменения).
3. От снапшота данные передаются на бэкап-сервер. Это специальная программа или физический сервер, на котором стоит система резервного копирования — например, Veeam, Commvault, Acronis, Bacula и т. п. Он управляет процессом бэкапа: решает, что и когда копировать, куда отправлять, какие версии хранить, как шифровать и как быстро восстанавливать.
4. Данные с бэкап-сервера уходят на разные типы хранилищ:
   локальные (например, NAS или отдельные жёсткие диски в дата-центре) — для быстрого восстановления;
   удалённые (например, облачные S3-хранилища, MinIO, Amazon S3) — на случай серьёзных инцидентов;
   офлайн-хранилища (например, ленточные библиотеки или отключённые от сети диски) — как защита от вирусов и вымогателей.

Бэкап-сервер может использовать разные технологии, чтобы минимизировать нагрузку на сеть и систему:

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

Часто используется принцип «3-2-1»: нужно иметь 3 копии данных, хранить их на 2 разных типах носителей, и как минимум одну — вне основной площадки. Также часто реализуют immutable backup — то есть копии, которые нельзя изменить или удалить. Это защита от шифровальщиков.

И, конечно, важно не просто копировать данные, но и тестировать восстановление. Без регулярных проверок ты не уверен, что вообще сможешь что-то вернуть.

Как использовать бэкап для восстановления после сбоя

1. Оценка сбоя

Сначала нужно понять: что именно сломалось?

• Удалён файл?
• Повреждена БД?
• Упала виртуалка?
• Сломалась вся система/СХД/сервер?

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

2. Выбор нужной точки восстановления

В любой системе бэкапа ты видишь список бэкапов: по дате, по содержимому, по типу (полный, инкремент, снапшот).

Выбираешь:

• нужный день и час;
• нужную версию файла, ВМ, БД или папки;
• и формат восстановления — в оригинальное место или в новое.

3. Восстановление (restore)

Зависит от типа данных:

• Файл — возвращается напрямую;
• БД — часто восстанавливается в отдельную папку или отдельную БД, потом подключается;
• Виртуалка — может быть запущена как "Instant Recovery" прямо с бэкапа;
• Целый диск или LUN — восстанавливается через снапшот или экспорт в СХД.

В некоторых системах (например, Veeam или Proxmox) можно запустить ВМ прямо из бэкапа без полного восстановления — это позволяет выиграть время.

Как тестировать бэкапы

Тестирование нужно, потому что:

«Файл backup_final_REAL_ONE_v2.zip существует — это не значит, что он открывается».

Вот что важно тестировать:

1. Файл открывается и читается?

• Распакуй архив, открой PDF, запусти базу.
• Если бэкап зашифрован — проверяй пароль, ключ, доступность.

2. Можно развернуть ВМ или восстановить БД?

• Запусти восстановленную виртуалку на тестовой площадке.
• Подключи восстановленную базу — она запускается? Таблицы на месте?

3. Система после восстановления работоспособна?

• Файлы открываются?
• Программа запускается?
• Данные не битые?

4. Восстановление идёт быстро?

• Считается хорошим результатом, если ключевые сервисы можно восстановить за 1 час.
• Если восстановление идёт полдня — это надо пересматривать стратегию.

Как часто тестировать?

• Минимум раз в месяц.
• Лучше — раз в неделю автоматический тест восстановления (например, виртуалки в isolated VLAN).
• После любых изменений в бэкап-сценариях (новая версия, новые данные, другой формат).

Золотые правила восстановления

1. Не восстанавливай сразу в продакшн. Всегда сначала в тестовую среду.
2. Документируй процесс восстановления. Кто, как, с каких точек.
3. Проверяй доступность бэкапов. Иногда бэкап есть, но путь не доступен.
4. Включай тест восстановления в политику ИБ.
5. Делай restore-тесты вслепую. Пусть коллега выберет бэкап и даст тебе задачу: «восстанови базу на вчерашний день». И смотришь — насколько ты готов.
   
   (пример) ЧЕК-ЛИСТ: Тест восстановления бэкапа 1С

1. Подготовка

• Назначена ответственная роль (админ/ИТ-специалист)
• Выделен тестовый сервер или отдельная среда (VLAN, виртуалка)
• Подготовлен актуальный бэкап:
  .dt файл (для файловой базы)
  .bak или дамп SQL (для серверной)
  архив с каталогами (infobase/, conf/, ext/, если нужно)

2. Проверка целостности бэкапа

• Файл бэкапа открывается и не повреждён
• Проверена контрольная сумма (если ведётся)
• Проверена дата создания и имя базы

3. Развёртывание в тестовой среде

Для файловой базы:

• Создана новая директория
• Выполнен импорт:
  1cv8.exe /Restore path_to_base /IBName test_base

Для серверной базы:

• Создана новая база в SQL/PostgreSQL
• Загружен дамп (через pg_restore, SQL Server Manager или sqlcmd)
• Зарегистрирована новая база в 1С:Предприятие (в конфигураторе или через консоль)

4. Запуск и проверка базы

• База запускается без ошибок
• Работает авторизация пользователей
• Открываются справочники, документы, отчёты
• Работают регламентные задания, отчёты, обработка
• Данные соответствуют дате бэкапа (можно проверить по последним документам)

5. Функциональное тестирование (минимум):

• Создание нового документа
• Проведение типового отчёта
• Открытие журнала операций
• Проверка обмена с внешними системами (если есть)
• Проверка интеграции с 1С-отчётностью или онлайн-кассами (опционально)

6. Логирование и отчёт

• Зафиксировано:
  дата/время восстановления
  имя и дата бэкапа
  среда, куда восстановлено
  результат (успешно/с ошибками)
• Обновлён журнал тестов восстановления
• Отправлен отчёт ответственному (ИТ-директор, бухгалтерия, ИБ)

7. Удаление тестовой базы (по завершении)

• Тестовая база удалена
• Сервер/среда очищены
• Проверено, что нет утечек данных в боевую сеть

Рекомендуется:

• Проводить такой тест раз в месяц
• После любых изменений в схеме хранения, структуре БД или обновлений 1С

Настроить автоматический restore-тест для бэкапа с уведомлением по почте (если используете Veeam + SQL + скрипты)

Когда ты продаёшь заказчику решение по бэкапу (или даже просто объясняешь, зачем оно ему нужно), самое главное — перевести технику в бизнес-язык. Ниже — список того, что действительно важно донести, чтобы заказчик понял ценность и захотел платить.

1. Бэкап — это не про файлы. Это про выживание бизнеса.

Без бэкапа — не восстановишь бухгалтерию, не сдашь отчётность, не обслужишь клиента, не докажешь в суде, что ты был прав.

Нужно объяснить: бэкап — это страховка, а не дополнительная опция.

2. Бэкап — нужен не когда всё пропало, а до того.

Когда уже случилось — платить поздно.
Важно инвестировать до, а не после ЧП.
Это как пожарная сигнализация — не покупаешь её в момент пожара.

3. Потеря данных = потеря денег (а иногда и лицензий)

Примеры последствий:

• День простоя 1С — это минус в выручке, з/п сотрудникам, репутации.
• Потерянная база клиентов — нет повторных продаж.
• Отказ от восстановления — штраф от налоговой/ФНС или аудит.

Стоимость внедрения бэкапа в 10–100 раз ниже, чем стоимость инцидента.

4. У вас уже есть бэкап? Отлично. А вы уверены, что он работает?

Нужно задать неудобный, но важный вопрос:

Когда в последний раз вы пробовали восстановиться из бэкапа?

90% компаний думают, что у них всё хорошо — пока не пробуют восстановить.

5. Время восстановления = бизнес-репутация

Спросить:

• Как быстро вы хотите снова начать работать после сбоя?
• А клиенты будут ждать сутки, пока «технари что-то ковыряют»?

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

6. Мы не просто делаем копию. Мы обеспечиваем восстановление.

Бэкап без теста восстановления — это просто лишний файл на диске.

Мы предлагаем:

• Регулярное тестирование восстановления;
• Мониторинг и уведомления;
• Хранение в нескольких местах (3-2-1 стратегия).

7. Резервное копирование = часть кибербезопасности

Скажи прямо:

Если в вашу компанию попадёт вирус-вымогатель — вас спасёт только актуальный бэкап.

И покажи: можно хранить immutable-копии, делать offline-архивы, интеграцию с облаками (например, S3/MinIO).