Бэкап VMware для 1С обрывается за 4 часа: как перенести копии в облако

Резервное копирование VMware в облако — это регулярная передача копий виртуальных машин с локального хоста ESXi на внешний сервер за пределами офиса: технология changed block tracking передаёт только изменённые блоки диска, а готовая копия базы 1С хранится там, где её не тронут авария сервера, шифровальщик или пожар в серверной. Восстановление занимает минуты, а не дни ручного ввода документов заново.

Почему бэкап VMware обрывается или не доходит до облака

У торговой компании на 40 сотрудников виртуальная машина с базой 1С:Управление торговлей копируется каждую ночь с 2:00 до 6:00: задание в Veeam Backup & Replication настроили три года назад и с тех пор не пересматривали. Бухгалтерия по утрам жалуется, что база тормозит, но до пятницы никто не подозревает, что сам бэкап давно проваливается. Перед закрытием месяца база разрастается на 10-12 ГБ логов проведения документов, окно бэкапа не укладывается в четыре часа, а офисный канал 50 Мбит/с не тянет повторный полный прогон. Задание обрывается на середине передачи, и в понедельник администратор находит в консоли Veeam строку failed с таймаутом сети: последняя рабочая копия датирована прошлой средой.

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

Ставка здесь не абстрактная. Без свежей копии базы бухгалтерия не закроет месяц в срок, отдел продаж теряет историю заказов за несколько дней, а восстановление вручную по бумажным накладным занимает не один рабочий день сотрудника. Если в базе есть персональные данные клиентов или сотрудников, потеря резервной копии — ещё и вопрос по 152-ФЗ: закон требует обеспечивать сохранность персональных данных, включая архивные копии (152-ФЗ).

Как исправить обрыв репликации виртуальной машины в облако

Первым делом проверяют не сеть, а окно бэкапа: если полная копия ВМ с базой 1С не укладывается в ночные часы, включают инкрементальный режим на changed block tracking, тогда после первого полного слепка передаются только изменённые блоки, а не весь VMDK заново. Это сокращает трафик в разы и снимает таймауты на медленном канале.

Чтобы прикинуть, уложится ли ночной бэкап в отведённое окно, считают так: суточный объём изменений делят на длительность окна и сравнивают с реальной скоростью канала, а не заявленной провайдером. База 1С на 50 ГБ с приростом 3-5 ГБ логов в сутки при канале 50 Мбит/с передаётся за 15-20 минут, но тот же расчёт для базы на 300 ГБ с активным документооборотом уже упирается в лимит канала: здесь без оптимизации расписания или переноса самой базы ближе к хранилищу не обойтись.

Настройки, которые чаще всего забывают проверить

• ✓ограничение скорости (throttling) в задании: если оно стоит «по умолчанию», ночной бэкап конкурирует за канал с другими задачами и обрывается на середине;
• ✓число и возраст снапшотов ВМ: незакрытые снапшоты копятся неделями и раздувают диск ESXi, из-за чего хосту не хватает места для консолидации;
• ✓сертификат и версия vCenter: просроченный сертификат при отсутствии поддержки VMware в России обрывает сессию к хранилищу без внятной ошибки в логе.

Если обрыв разовый, обычно достаточно перезапустить задание вручную и сузить окно бэкапа: сдвинуть старт на более раннее время или разбить крупную базу на отдельное задание со своим расписанием.

Что делать, если ошибка бэкапа повторяется каждую ночь

Разовый сбой лечится перезапуском. Но если задание падает три ночи подряд с одним и тем же кодом ошибки, дело не в сети, а в самой инфраструктуре. Разбирают по порядку:

1. ✓лог vixDiskLib на хосте ESXi: там видно, на каком именно этапе передачи рвётся сессия;
2. ✓состояние дисков датастора: SMART, свободное место, скорость записи под нагрузкой;
3. ✓целостность changed block tracking: известная проблема VMware, когда CBT повреждается после неудачного снапшота и вместо инкремента гонит полный объём диска каждую ночь.

Такой порядок экономит часы: если сразу менять расписание, а причина в повреждённом CBT, ошибка вернётся на следующую же ночь.

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

Как предотвратить потерю резервных копий 1С при сбое ESXi

Правило 3-2-1 для базы 1С

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

Второе условие: регулярный restore-тест, а не только зелёная галочка в отчёте о завершённом задании. Задание отчитывается «успешно» и при этом сохраняет повреждённый VMDK — это вскрывается лишь в момент реального восстановления, когда уже поздно.

Проверяют бэкап так же регулярно, как настраивают:

• ✓раз в квартал разворачивают копию базы на тестовом сервере и открывают её в 1С, а не просто проверяют, что файл открылся;
• ✓сверяют контрольные суммы или итоговые обороты за последний закрытый период с рабочей базой;
• ✓замеряют время восстановления целиком, от команды restore до готовой к работе базы, и сравнивают с тем, сколько бизнес может простоять.

Компаниям, которые держат VMware без действующей поддержки, стоит держать в поле зрения переход на решение из реестра отечественного ПО (реестр российского ПО): не срочно, но заранее, пока миграция не превратилась в аварийную. Резервная копия базы 1С от гипервизора не зависит и переживёт такую миграцию, если хранится в универсальном формате.

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

Сколько стоит бэкап VMware в облаке и как выбрать сервер под 1С

Компании с одной-двумя базами 1С и штатом до 30-40 человек обычно хватает виртуального сервера: ресурсы хоста делятся с соседями, а бэкап настраивается отдельным заданием со своим расписанием. Для баз 1С:ERP или 1С:УХ с несколькими сотнями пользователей окно бэкапа критично: там разумнее выделенный физический ресурс, где копирование не конкурирует за диск с продуктивной нагрузкой.

Аренда сервера под 1С начинается от 1 100 ₽/мес за пользователя, аренда самой конфигурации 1С — от 1100 руб/мес; настройку расписания бэкапа, throttling и restore-теста сисадмин выполняет по факту работ, сопровождение считается от 3800 руб/час. Под тяжёлую базу или собственный ESXi с бэкапом в наше облако подходит выделенный сервер в аренду; если хватает доли мощности — виртуальный сервер для 1С. Для крупных баз с высокой нагрузкой на бэкап есть отдельная конфигурация — сервер под 1С:ERP.

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

Перенос виртуальной машины с базой 1С на арендованный сервер вместе с настройкой бэкапа обычно занимает от одного до трёх рабочих дней в зависимости от объёма базы и числа интеграций: большая часть времени уходит не на копирование данных, а на проверку, что внешние обработки и обмены работают на новом месте.

Расписание, throttling и окно копирования настраивают один раз при переносе базы — это часть настройки сервера 1С, а не отдельная услуга, которую нужно заказывать заново каждый раз, когда база подрастёт.

❓ Частые вопросы

Как настроить резервное копирование VMware в облако для базы 1С?

Ставят прокси Veeam Backup & Replication или аналогичного ПО на хосте ESXi, указывают облачный репозиторий как цель задания, включают changed block tracking для инкрементов и задают окно копирования вне рабочих часов. Затем проверяют настройку восстановлением тестовой копии — без этого шага бэкап считается незавершённым.

Сколько нужно хранить резервные копии базы 1С по закону?

Конкретного срока хранения резервных копий закон не задаёт — 152-ФЗ требует обеспечить сохранность и доступность персональных данных, включая архивные копии. На практике для 1С держат минимум 2-3 последние полные копии плюс инкременты за 2-4 недели — этого хватает для отката к любой рабочей дате месяца.

Что делать, если хост ESXi вышел из строя и локальный бэкап недоступен?

Если копия хранилась только на том же физическом сервере, она, скорее всего, потеряна вместе с хостом — поэтому и нужна вторая копия за пределами офиса. Базу разворачивают из облачного бэкапа на новом сервере: при готовой инфраструктуре это занимает часы, а не дни на восстановление документов вручную.

Хватит ли обычного офисного интернета для ежедневной репликации ВМ в облако?

Для инкрементального бэкапа на changed block tracking канала 50-100 Мбит/с обычно достаточно — передаются только изменённые блоки. Полный еженедельный слепок крупной базы 1С может не уложиться в ночное окно на слабом канале; тогда сужают расписание или переносят саму базу ближе к облачному хранилищу.

Чем аренда сервера с готовым бэкапом отличается от настройки VMware своими силами?

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