Перенос 1С на облачный сервер стоит начинать с проверки окружения и пробного восстановления. Если ограничиться копированием базы, после переключения могут перестать работать печать, обмен с банком или регламентные задания. Этот чек-лист поможет подготовить переезд, проверить результат и сохранить возможность отката.
1. Соберите паспорт текущей системы
Зафиксируйте все зависимости рабочей системы:
- версию платформы и конфигурации, расширения, доработки и внешние обработки;
- режим базы: файловый или клиент-серверный; для второго — СУБД, её версию и параметры подключения;
- размер данных, темп роста, число одновременных сеансов и периоды пиковой нагрузки;
- обмены с сайтом, банком, ЭДО и другими базами, расписания заданий, внешние компоненты;
- принтеры, сканеры, торговое оборудование, криптопровайдеры, сертификаты и каталоги вложений.
Сохраните параметры служб, публикаций и учётных записей. Пароли и закрытые ключи не помещайте в общедоступный документ. Замерьте время входа, проведения документа и построения отчёта для сравнения после переноса.
2. Проверьте платформу и лицензии
Согласуйте схему работы: удалённый рабочий стол, тонкий клиент или веб-клиент. Проверьте совместимость конкретных релизов платформы, ОС и СУБД по документации 1С. Не совмещайте перенос с обновлением конфигурации без отдельной репетиции: так сложнее локализовать причину ошибки.
Уточните, кто предоставляет клиентские и серверные лицензии 1С, ОС и СУБД, допустимо ли выбранное размещение и как восстанавливается активация после смены машины. Для пользовательской работы через Windows RDS отдельно учитывайте лицензирование удалённых сеансов: Microsoft описывает модели RDS CAL на пользователя или устройство. У провайдера может применяться другая договорная схема; её нужно проверить до переезда.
3. Подберите ресурсы и границы поддержки
Состав виртуальной машины выбирайте по фактической нагрузке, а затем проверяйте на копии базы. Учитывайте не только число пользователей, но и отчёты, пакетное проведение и фоновые обмены.
- Для процессора и памяти оцените пики в рабочее время и при регламентных операциях.
- Для дисков учитывайте задержку ввода-вывода и место под базу, журналы, временные файлы и рост данных.
- Для сети проверьте работу из реальных офисов и домашних подключений, включая печать.
- Уточните порядок увеличения ресурсов, необходимость остановки и ответственность за администрирование.
При сравнении предложений можно использовать описание услуги https://zeonit.ru/services/1c-cloud: на странице перечислены облачный сервер для 1С, поддержка, резервное копирование и помощь с переносом. Конкретные ресурсы, состав лицензий, сроки восстановления и границы работ следует закрепить в условиях выбранного размещения.
4. Настройте защищённый доступ
Не открывайте RDP всем адресам интернета. Организуйте доступ через VPN либо шлюз удалённых рабочих столов с ограничениями по пользователям и ресурсам. В документации Microsoft RD Gateway описан как защищённая точка входа, использующая SSL-туннель. Многофакторную аутентификацию включайте в выбранной точке доступа и проверяйте отдельно: один факт установки шлюза не означает, что второй фактор настроен.
Разделите обычные и административные учётные записи, выдавайте минимально необходимые права. Ограничьте сетевой доступ к СУБД и служебным интерфейсам, установите обновления, включите журналирование входов. Согласуйте, кто получает уведомления о неудачных входах, заполнении диска и сбоях копирования.
5. Подготовьте копию и проверьте восстановление
Для файловой базы копирование выполняйте после завершения всех подключений, включая служебные. Для клиент-серверной базы используйте согласованную процедуру резервного копирования средствами СУБД: именно такой подход рекомендует документация 1С. Простое копирование файлов работающей SQL-базы не используйте как универсальный способ переноса.
Отдельно сохраните внешние вложения, необходимые настройки и другие данные, не входящие в копию базы. Защитите резервные копии от доступа пользователей; храните хотя бы одну копию вне переносимой виртуальной машины.
Восстановите базу в изолированном тестовом окружении. Сначала заблокируйте реальные обмены, рассылки и фоновые задания, чтобы тестовая копия не отправляла документы наружу. В SQL Server проверка RESTORE VERIFYONLY проверяет читаемость и полноту резервного набора, но не восстанавливает базу и не проверяет структуру всех данных. Поэтому она не заменяет пробное восстановление и функциональные тесты.
6. Отрепетируйте рабочие сценарии
Проверьте сценарии с представителями подразделений под их рабочими ролями. Проверьте вход, отчёты, проведение документов, доступ к вложениям, печатные формы и реальную печать из удалённого сеанса. Протестируйте внешние компоненты, подпись и интеграции в безопасном тестовом режиме.
Сравните контрольные отчёты и остатки на одинаковый момент, измерьте длительность операций и восстановления. По результатам согласуйте RPO — допустимую потерю данных по времени — и RTO — целевое время восстановления работы. Включите передачу копии в план простоя.
7. Выполните переключение по плану
- Согласуйте окно работ, ответственных и критерии отмены переноса. Предупредите пользователей.
- Остановите новые подключения и запись данных, включая обмены и задания. Убедитесь, что пользователи завершили работу.
- Создайте финальную согласованную копию выбранным способом, перенесите её по защищённому каналу и восстановите в целевом окружении.
- Проверьте контрольные данные, права и ключевые операции. Получите подтверждение ответственного пользователя.
- Переключите подключения. Включайте интеграции и задания контролируемо, исключая их одновременный запуск на старой и новой площадках.
8. Зафиксируйте откат и приёмку
До открытия записи в новой базе задайте предельное время диагностики и условия возврата: расхождение данных, недоступность критичного обмена или неприемлемая скорость. Старую систему сохраните защищённой от изменений. После появления новых документов простой возврат на старую базу приведёт к потере этих изменений; потребуется отдельное согласование и перенос либо сверка данных.
После запуска проверьте первую резервную копию уже нового окружения, уведомления мониторинга и выполнение заданий. Удалять старую площадку можно после приёмки, проверки восстановления и согласованного срока хранения. Завершённый перенос — это работающие пользовательские сценарии и проверенный способ вернуть систему в строй.