1С в облаке: переносим базу с компьютера бухгалтера на сервер

Что ломается, когда база лежит на одном компьютере

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

• Работать можно только за этим компьютером. Заболел, уехал, остался дома — база недоступна.
• Второй человек не помещается. Общая папка по сети — стандартный первый шаг, и работает он плохо. Официально файловый вариант рассчитан на персональную работу одного пользователя или работу небольшого числа пользователей в локальной сети, и упор здесь на слово «небольшого»: пока один записывает документ, часть файла заблокирована для остальных.
• Копии лежат на том же диске. Это не резервные копии, а вторые экземпляры. Диск вышел из строя — исчезло и то и другое.
• Компьютер — единственная точка отказа. Ноутбук украли, на системный блок пролили чай, Windows не загрузилась. Сколько времени займёт восстановление и сколько данных потеряется, обычно никто не знает.

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

Три варианта и как выбрать между ними

Слова «1С в облаке» означают три разные вещи. Выбор между ними определяется двумя числами: сколько человек работает в базе одновременно и насколько конфигурация доработана под вашу компанию.

Дальше в статье — второй вариант. Он закрывает случай, который встречается чаще всего: бухгалтерия из двух-трёх человек и конфигурация, которую уже подстраивали под себя. Порог перехода к третьему варианту виден заранее: как только одна из внутренних таблиц базы упирается в свой предел — 4 ГБ на большинстве платформ, — файловый режим заканчивается. Это ограничение формата, а не настроек.

Что проверить до переезда

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

Какой нужен сервер

Считаем так: около 4 ГБ уходит на Windows и служебные процессы, дальше примерно по 512 МБ на каждого работающего — столько занимает один сеанс 1С. Та же арифметика лежит в требованиях 1С к серверной части. Отсюда три ступени.

Ещё три условия, которые важнее размера диска. Тип диска — только SSD или NVMe: файловая база — это постоянные мелкие чтения и записи одного файла, и на обычном жёстком диске работа становится мучительной. Локация — Россия: в бухгалтерской базе лежат данные сотрудников, а к серверу ближе те, кто в нём работает. Операционная система — Windows Server 2019 или 2022.

Шаг 1. Готовим сервер и ставим платформу

Провайдер выдаёт адрес сервера, имя администратора и пароль. Подключаемся стандартным клиентом Windows: Пуск → набрать mstsc → ввести адрес. Первым делом устанавливаем обновления Windows и перезагружаемся — на свежем сервере их обычно накопилось много, и лучше пройти это до того, как на нём появятся люди и данные.

Создаём папку для базы. Имя без пробелов и без кириллицы — так проще писать команды, и часть неочевидных ошибок отпадает сама:

New-Item -ItemType Directory -Path 'C:\1C\Buh'
New-Item -ItemType Directory -Path 'C:\Backup'

Дистрибутив платформы берём на портале releases.1c.ru — вход по логину пользователя портала 1С. Доступ к скачиванию для версий ПРОФ даёт действующий договор сопровождения ИТС; для базовых версий обновления доступны и без договора. Скачиваем ту же версию платформы, что записана в пункте 5 предыдущего раздела, или более новую.

Установка обычная: распаковать архив, запустить setup.exe, оставить компоненты по умолчанию. Компонент Сервер 1С:Предприятия в списке отмечать не нужно — он для клиент-серверного варианта, а у нас файловый.

Шаг 2. Выгружаем базу со старого компьютера

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

Дальше в окне запуска 1С выбираем базу, режим Конфигуратор, и в меню:

1. Администрирование → Выгрузить информационную базу
2. Сохранить файл под понятным именем, например buh.dt
3. Дождаться сообщения об успешном завершении

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

Шаг 3. Создаём базу и активируем лицензию

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

Запускаем 1С, в окне со списком баз нажимаем Добавить и выбираем:

1. Создание новой информационной базы
2. вариант Создание информационной базы без конфигурации — именно он нужен для загрузки выгруженной ранее базы
3. каталог — C:\1C\Buh, тип расположения — на данном компьютере

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

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

После активации проверьте, куда лёг файл лицензии. Общий каталог для всех пользователей компьютера — C:\ProgramData\1C\licenses:

Get-ChildItem 'C:\ProgramData\1C\licenses'

Если файл .lic оказался в профиле конкретного пользователя, перенесите его в этот каталог. Иначе лицензию не увидят ни остальные сотрудники, ни ночное задание резервного копирования, которое настроим в шаге 6.

Если лицензия на USB-ключе

Ключ HASP в арендованный сервер вставить некуда. Вариантов два. Можно оставить ключ в офисе и раздавать лицензии по сети — работает, но тогда 1С на сервере зависит от офисного интернета: пропал канал — пропала лицензия у всех. Второй путь надёжнее: обратиться к партнёру 1С и обсудить переход на программные лицензии. Условия зависят от вашего комплекта поставки, поэтому спрашивать нужно до переезда, а не после.

Сколько лицензий понадобится

На сервере с удалённым рабочим столом счёт простой: каждая клиентская лицензия 1С обслуживает один одновременный сеанс. Трое бухгалтеров, которые работают в базе в одно и то же время, займут три лицензии — ровно столько же, сколько понадобилось бы на трёх отдельных компьютерах. Если лицензии уже куплены, докупать ничего не нужно: они просто переезжают вместе с базой.

Шаг 4. Загружаем базу на сервере

Лицензия получена, пустая база создана — осталось положить в неё данные. Открываем базу в режиме Конфигуратор и выбираем в меню: Администрирование → Загрузить информационную базу → указываем buh.dt. Загрузка полностью заменяет содержимое базы, поэтому предупреждение выглядит пугающе — так и должно быть, заменять пока нечего.

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

Шаг 5. Пользователи и доступ по RDP

Каждому сотруднику — своя учётная запись Windows. Общая учётка на всех кажется удобной ровно до первого разбирательства, кто и что сделал. Имена лучше писать латиницей: их придётся вводить в окне подключения, и раскладка там не всегда та, которую ожидаешь.

$pass = Read-Host -Prompt 'Пароль для ivanova' -AsSecureString
New-LocalUser -Name 'ivanova' -FullName 'Иванова Анна' -Password $pass -PasswordNeverExpires
Add-LocalGroupMember -SID 'S-1-5-32-555' -Member 'ivanova'

Последняя строка добавляет пользователя в группу «Пользователи удалённого рабочего стола» — без неё подключиться к серверу не выйдет. Группа указана не именем, а идентификатором S-1-5-32-555: он одинаков в любой Windows, а имя группы зависит от языка системы, и на англоязычном сервере команда с русским названием просто не сработает.

Теперь права на папку с базой. Работа в 1С — это запись в файл базы, поэтому обычного чтения мало:

icacls C:\1C /grant '*S-1-5-32-555:(OI)(CI)M' /T

Здесь M — право на изменение, (OI)(CI) — распространить его на вложенные файлы и папки. Кавычки обязательны: без них PowerShell попытается разобрать скобки как свои собственные.

Общий список баз

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

New-Item -ItemType Directory -Force -Path 'C:\ProgramData\1C\1CEStart' | Out-Null
Copy-Item "$env:APPDATA\1C\1CEStart\ibases.v8i" 'C:\ProgramData\1C\1CEStart\'

Add-Content -Path 'C:\ProgramData\1C\1CEStart\1CEStart.cfg' `
  -Value 'CommonInfoBases=C:\ProgramData\1C\1CEStart\ibases.v8i'

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

Ограничение в два подключения

Windows Server из коробки разрешает два одновременных подключения к рабочему столу, и это подключения для администрирования сервера. Чтобы на сервере постоянно работали пользователи, нужна роль Remote Desktop Services и лицензии RDS CAL — по числу пользователей или устройств. Они покупаются отдельно, в цену сервера не входят и к лицензиям 1С отношения не имеют.

То есть двое сотрудников уложатся в то, что уже есть. Начиная с третьего счёт складывается из четырёх частей, и полезно увидеть их сразу целиком:

• Аренда сервера — ежемесячно, по тарифу.
• Лицензия Windows Server — у части провайдеров входит в цену тарифа, у части оплачивается отдельно.
• Лицензии RDS CAL — если одновременно работают больше двух человек.
• Клиентские лицензии 1С — по числу одновременных сеансов; если они уже куплены, докупать не нужно.

Шаг 6. Резервные копии

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

Сначала закрываем папку с копиями от всех, кроме администраторов. Это обязательный шаг, а не предосторожность: в скрипте будет лежать пароль, а новая папка на диске C: по умолчанию открыта всем пользователям на чтение. По той же причине скрипт не кладём в C:\1C — там мы только что выдали права на изменение всем, кто заходит по RDP.

icacls C:\Backup /inheritance:r `
  /grant '*S-1-5-32-544:(OI)(CI)F' /grant '*S-1-5-18:(OI)(CI)F'

/inheritance:r убирает права, унаследованные от корня диска — именно они дают всем пользователям чтение. Два /grant возвращают полный доступ администраторам (S-1-5-32-544) и системной учётной записи (S-1-5-18), от которой работают служебные процессы Windows. Всё в одной команде: если убрать наследование отдельным вызовом, папка на секунду останется вообще без прав.

Теперь создаём в этой папке файл C:\Backup\backup.ps1. Учётные данные в первых строках — это пользователь 1С с правами администратора базы, а не учётная запись Windows:

$base = 'C:\1C\Buh'
$out  = 'C:\Backup'
$user = 'Администратор'
$pw   = 'ПАРОЛЬ_ПОЛЬЗОВАТЕЛЯ_1С'
$log  = 'C:\Backup\backup.log'

# Путь к платформе не пишем вручную: берём самую свежую установленную версию.
# Сортируем как версию, а не как текст — иначе 8.3.9 окажется старше 8.3.25
$exe = (Get-ChildItem 'C:\Program Files\1cv8\8.*\bin\1cv8.exe' |
        Sort-Object { [version]$_.Directory.Parent.Name } | Select-Object -Last 1).FullName

$file = Join-Path $out ('buh-' + (Get-Date -Format 'yyyy-MM-dd') + '.dt')
$now  = Get-Date -Format 'dd.MM.yyyy HH:mm'

$p = Start-Process -FilePath $exe -Wait -PassThru -ArgumentList @(
  'CONFIG', "/F$base", "/N$user", "/P$pw", '/DumpIB', $file
)

if ($p.ExitCode -ne 0) {
  Add-Content $log ($now + ' — выгрузка не удалась, код ' + $p.ExitCode)
  exit 1
}

Add-Content $log ($now + ' — готово: ' + $file)

# Копии старше двух недель удаляем, иначе диск закончится молча
Get-ChildItem (Join-Path $out '*.dt') |
  Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-14) } | Remove-Item

Если в вашей базе пользователи 1С не заведены вовсе, уберите из списка аргументов /N и /P — иначе 1С не поймёт, кого пускать. Ставим задание на три часа ночи:

schtasks /create /tn "Backup1C" /sc daily /st 03:00 /rl HIGHEST ^
  /ru "Администратор" /rp "ПАРОЛЬ_WINDOWS" ^
  /tr "powershell -NoProfile -ExecutionPolicy Bypass -File C:\Backup\backup.ps1"

В /ru указана учётная запись Windows, а не пользователь 1С: задание запускается от администратора, потому что выгрузке нужен доступ к файлу лицензии — тому самому, который мы положили в общий каталог в шаге 3. Имя учётной записи подставьте своё: у русской Windows это обычно «Администратор», у англоязычной — Administrator, а часть провайдеров заводит собственное имя и присылает его вместе с паролем.

Выгрузка требует, чтобы в базе не было ни одного сеанса. Если кто-то забыл выйти вечером, задание завершится с ненулевым кодом и запишет это в C:\Backup\backup.log. Заглядывайте в этот файл хотя бы раз в неделю — иначе о сломавшемся бэкапе вы узнаете в день, когда он понадобится.

Шаг 7. Закрываем удалённый рабочий стол

Сервер с открытым портом 3389 начинают перебирать в первые же часы после запуска — это фоновый шум интернета, он не связан с тем, интересна ли кому-то ваша компания. Два действия ниже убирают почти весь этот поток, третье подойдёт не всем.

Меняем порт. Порядок команд важен: сначала открываем новый порт в брандмауэре и только потом переключаем на него службу. Если сделать наоборот, вы отключитесь от сервера, а войти на новый порт ещё не сможете.

$port = 13389

New-NetFirewallRule -DisplayName 'RDP-custom-TCP' -Profile Any `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort $port
New-NetFirewallRule -DisplayName 'RDP-custom-UDP' -Profile Any `
  -Direction Inbound -Action Allow -Protocol UDP -LocalPort $port

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name 'PortNumber' -Value $port -Type DWord

Restart-Computer

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

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

net accounts /lockoutthreshold:5
net accounts /lockoutduration:15 /lockoutwindow:15

На обычные учётные записи правило действует сразу. На встроенного администратора — только если включена отдельная политика «Разрешить блокировку учётной записи администратора»: на серверах, поставленных начиная с осени 2022 года, она включена изначально, на более старых её включают вручную. Есть и приятная деталь: блокировка распространяется только на сетевые входы, то есть на RDP, а вход через консоль во время блокировки работает. Поэтому заранее найдите в панели провайдера доступ к консоли сервера — это и есть путь назад, если заблокируете сами себя.

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

Set-NetFirewallRule -DisplayName 'RDP-custom-TCP' -RemoteAddress '203.0.113.10'
Set-NetFirewallRule -DisplayName 'RDP-custom-UDP' -RemoteAddress '203.0.113.10'

Чего делать не нужно: отключать проверку подлинности на уровне сети (NLA). Она включена по умолчанию и требует пароль до того, как сервер начнёт выделять ресурсы под сеанс. Её отключение изредка советуют для решения проблем с подключением — это ровно тот совет, который стоит игнорировать.

Частые проблемы

Коротко: порядок действий

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