24 апреля у нас прошел вебинар на тему “Backup, DR и миграция в облако”. 24 апреля у нас прошел вебинар на тему “Backup, DR и миграция в облако”.
24 апреля у нас прошел вебинар на тему “Backup, DR и миграция в облако”. 24 апреля у нас прошел вебинар на тему “Backup, DR и миграция в облако”.
24 апреля у нас прошел вебинар на тему “Backup, DR и миграция в облако”. 24 апреля у нас прошел вебинар на тему “Backup, DR и миграция в облако”.
24 апреля у нас прошел вебинар на тему “Backup, DR и миграция в облако”. 24 апреля у нас прошел вебинар на тему “Backup, DR и миграция в облако”.
24 апреля у нас прошел вебинар на тему “Backup, DR и миграция в облако”. 24 апреля у нас прошел вебинар на тему “Backup, DR и миграция в облако”.
Блог
05 июня 2024

24 апреля у нас прошел вебинар на тему “Backup, DR и миграция в облако”.

iiii Tech
123056, Россия, Москва, Москва, 123056, ул. Большая Садовая 5, к. 1, коворкинг SOK
+7 495 663 70 80

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

Итак, какие есть виды резервного копирования?
  • Файловый. Ручное или автоматическое перемещение файлов на другой носитель.
  • Виртуальная машина целиком. Это может быть самостоятельное решение, подключаемое к гипервизору или облачное решение.

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

  • Средствами приложения. Например, бекап базы данных встроенными в продукт средствами.

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

  • RPO (Recovery point objective) – максимальный период, за который бизнес может позволить себе потерять данные в случае сбоя или аварии.

  • RTO (Recovery time objective) - целевая длительность времени, в течение которой бизнес-процесс или система должны быть восстановлены с момента возникновения сбоя или аварии.

  • Максимальный срок хранения данных. Самая свежая копия может оказаться нерабочей.

Не стоит забывать, что помимо резервного копирования существует также и репликация данных. Чаще всего реплика имеет только одну копию данных, которая может содержать ошибки. Назначение реплики – как можно быстрее и с наименьшими потерями данных запустить копию приложения в другом месте. Необходимо периодически проводить реальное тестирование переключения на реплики.

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

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

Создание копии сервера с Veeam agent и его тестовое восстановление в новое облако. Оценка работоспособности в новом облаке, после которого на исходном сервере отключается внешнее соединение пользователей, чтобы предотвратить изменения в приложении. Далее инкрементальный бэкап и восстановление сервера на новой площадке.

На новой площадке подготавливаются аналогичного размера машины. Совместно с разработчиками установка и настройка приложения. Далее в БД приложение выгружается копия данных, тестируется работоспособность, доступность, производительность. Далее на исходном сервере отключается внешнее соединение пользователей, чтобы предотвратить изменения в приложении. После этого — дамп БД и восстановление БД приложения в новом облаке.

Подготовка как в предыдущем варианте, но после тестирования работоспособности настраивается асинхронная репликация БД между исходной площадкой и новой. Когда исходный сервер отключается, БД в новом облаке переводится в режим мастера.







Читайте также
/about/media/blog/skrytye-raskhody-na-upravlenie-it-podryadchikami-kak-edinoe-okno-podderzhki-prilozheniy-i-infrastruk/
Блог
Скрытые расходы на управление ИТ-подрядчиками: как единое окно поддержки приложений и инфраструктуры делает работу предсказуемой и сокращает издержки
30 апреля 2026
/events/bezopasnaya-infrastruktura-i-infrastruktura-bezopasnosti/
Семинар
Безопасная инфраструктура и инфраструктура безопасности
22 - 21 апреля 2026
/events/obzor-funktsiy-bi-zone-secure-sd-wan-1-6/
Вебинар
Обзор функций BI.ZONE Secure SD‑WAN 1.6
21 апреля 2026
Подпишитесь на рассылку Форайз!
Отправляем только полезные письма
Нажимая на кнопку, я соглашаюсь с политикой обработки персональных данных
Продолжая использовать этот сайт и нажимая на кнопку «Принимаю», вы даете согласие на обработку файлов cookie