Настройка postgresql для работы в связке с 1с 8.х на платформе windows server 2012, объём бд более 200 гб

Возможность сэкономить на дорогих лицензиях от Microsoft побуждает многие компании искать альтернативные варианты запуска 1С. Сегодня расскажу об одной из таких альтернатив — установке и настройке сервера 1С на Linux (Debian) в связке с базой данных PostgreSQL. Я не просто покажу, как запустить 1С на Linux, но и поделюсь полной информацией по эксплуатации этой системы, так как имею подобный опыт.

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти вступительный тест.

Введение

Сервер 1С не умеет работать со стандартной версией PostgreSQL. Её нужно патчить. Существует как минимум 2 версии postgresql с патчами для запуска 1С:

1. PostgreSQL Pro — https://1c.postgres.ru.
2. Версия от фирмы 1С. Установочный файл обычно называется Дистрибутив СУБД PostgreSQL для Linux x86 (64-bit) одним архивом. Скачать можно только с портала https://releases.1c.ru имея актуальную учетную запись.

Используя Linux сервер для установки 1С вы экономите деньги на следующих лицензиях:

• Microsoft Windows Server.
• Microsoft SQL Server.
• Клиентский доступ к MS SQL Server.

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

В этой статья я всё буду настраивать на базе дистрибутива Debian 11.

Если у вас еще не настроен сервер с Debian, рекомендую мои материалы на эту тему:

Далее переходим к самой настройке 1С. Если у вас нет отдельной серверной и сервера под это дело, то удобнее арендовать dedic, например, у Selectel. Для комфортной работы с 1С средней компании хватит бюджетного дедика за 5000-6000 р. в месяц. Я рекомендую устанавливать всё на гипервизор Proxmox на программный рейд mdadm, даже если у вас будет всего одна виртуальная машина. Это упрощает бэкап и перенос системы в случае необходимости. Для этого при заказе сервера в Selectel выберите соответствующий шаблон. Вручную ничего настраивать не придётся. Сразу получите установленный гипервизор Proxmox на софтовом mdadm raid1.

Предприятие 8. 3 на Debian 11

Начнем нашу настройку с установки сервера 1С. Для этого нам надо установить дополнительные пакеты в систему, которые находятся в разделах системного репозитория contrib и non-free. Их нужно добавить в конфиг репозиториев Debian. Для этого редактируем файл /etc/apt/sources.list и приводим его примерно к следующему виду:

deb http://mirror.yandex.ru/debian bullseye main contrib non-free
deb-src http://mirror.yandex.ru/debian bullseye main contrib non-free

deb http://mirror.yandex.ru/debian bullseye-updates main contrib non-free
deb-src http://mirror.yandex.ru/debian bullseye-updates main contrib non-free

deb http://security.debian.org/ bullseye-security main contrib non-free
deb-src http://security.debian.org/ bullseye-security main contrib non-free

Сами адреса репозиториев у вас могут быть другие. Выполняем обновление списка пакетов:

# apt update

Теперь устанавливаем нужные для работы 1С в linux пакеты. Начнем со шрифтов mscorefonts.

# apt install ttf-mscorefonts-installer

Установка будет идти достаточно долго, так как скачивается целая куча дополнительных пакетов и файлов.

Подключим репозиторий от Debian 10 для установки пакета libenchant1c2a, который нужен для установки сервера 1С. Без него получите ошибку примерно следующего содержания:

Не удалось установить пакеты, требуемые для работы. Чтобы установка платформы «1С:Предприятие» завершилась успешно, необходимо самостоятельно установить отсутствующие пакеты с помощью пакетного менеджера операционной системы и заново запустить установку платформы. Отсутствующие пакеты приведены ниже и их можно скопировать в буфер обмена:
libenchant1c2a gstreamer1.0-plugins-bad libegl1-mesa

# echo "deb http://mirror.yandex.ru/debian buster main" > /etc/apt/sources.list.d/buster.list

Добавляем еще несколько необходимых пакетов:

# apt update
# apt install imagemagick unixodbc sudo curl libenchant1c2a

Следующий важный этап подготовки к установке сервера 1С — настройка локали. Для этого выполняем команду в терминале:

# dpkg-reconfigure locales

Нам нужно выбрать ru_RU.UTF-8 UTF-8. Так же убедитесь на всякий случай, что en_US.UTF-8 тоже выбрана. В дефолте так и должно быть, но я сталкивался с ситуациями, когда эту локаль тоже приходилось добавлять.

Имя файла будет server64_8_3_22_1851.tar.gz. Его нужно передать на Debian сервер. Я обычно winscp для этого использую. Распаковываем архив в отдельную директорию.

# mkdir 1c-server
# mv server64_8_3_22_1851.tar.gz 1c-server/
# cd 1c-server/
# tar xzvf server64_8_3_22_1851.tar.gz
# rm server64_8_3_22_1851.tar.gz

Вы получите единый установщик setup-full-8.3.22.1851-x86_64.run, который содержит все пакеты для сервера 1С. Запускаем его в пакетном режиме с некоторыми параметрами:

# chmod +x setup-full-8.3.22.1851-x86_64.run
# ./setup-full-8.3.22.1851-x86_64.run --mode unattended --enable-components server,ws

Полный список опций можно посмотреть в официальной документации. В данном случае я установил сам кластер серверов 1С и модуль расширения веб сервера. Не забудьте изменить версию платформы в имени файла на свою.

Регистрируем unit systemd для управления службой 1С:

 link /opt/cv/x_/8.3.22.1851/srvcv-8.3.22.1851@.service

Запускаем Сервер 1С на Debian и сразу добавляем в автозагрузку:

# systemctl start srv1cv8-8.3.22.1851@.default
# systemctl enable srv1cv8-8.3.22.1851@.service

Проверим, все ли службы запустились:

# netstat -tulnp | grep "rphost\|ragent\|rmngr"

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

На этом установка самого Сервера 1С закончена. Переходим к установке и настройке базы PostgreSQL для него.

Установка PostgreSQL Pro для 1С

Для работы с 1С в PostgreSQL необходимо внести некоторые изменения в виде патчей. Существует несколько редакций этих патчей, но наиболее известные две:

1. От самой 1С.
2. От компании PostgreSQL Pro.

Я не берусь судить сам, какая сборка PostgreSQL для 1С будет лучше. Я всегда использую от Postgresql Pro. Эта компания активно участвует в разработке самого движка БД, так что компетенций у нее достаточно. Есть мнение, что эти сборки лучше, чем от 1С. К тому же в последних версиях, я заметил, что эти сборки автоматически настраивают конфиг postgresql под параметры памяти и процессоров вашего сервера. Не нужно это делать потом вручную.

Загрузить PostgreSQL Pro для 1С можно по ссылке — https://1c.postgres.ru. Для этого ответьте на 3 вопроса установщика и в конце укажите вашу почту. Туда придёт инструкция по установке.

Инструкция достаточно простая. Подключаем репозитории postgresql:

# wget https://repo.postgrespro.ru/1c-15/keys/pgpro-repo-add.sh
# sh pgpro-repo-add.sh

Устанавливаем базу данных:

# apt install postgrespro-1c-15

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

# systemctl enable postgrespro-1c-15

Проверьте статус сервиса postgrespro-1c-15. Он должен быть запущен.

# systemctl status postgrespro-1c-15

Далее переходим к настройке postgresql.

Настройка PostgreSQL для работы с 1С

Первым делом зададим пароль внутреннего пользователя postgers, под которым будет работать сервер 1С.

# sudo -u postgres /usr/bin/psql -U postgres -c "alter user postgres with password 'postgrespwd';"
ALTER ROLE

Внесём некоторые изменения в конфигурацию postgresql. Она находится в файле /var/lib/pgpro/1c-15/data/postgresql.conf. Изменения некритичные и носят рекомендательный характер. Можете их не менять, если не хочется разбираться. 1С будет нормально работать и без них. Обратите внимание, что в этой сборке postgresql рекомендованные настройки, зависящие от ресурсов сервера, указаны в самом конце конфигурационного файла. Я предлагаю добавить или изменить следующие настройки:

# если сервер 1С установлен на этой же машине, то слушаем только localhost
listen_addresses = 'localhost'
# увеличиваем дефолтное значение подключений
max_connections = 150

# systemctl restart postgrespro-1c-15

В целом, больше ничего добавлять в конфигурацию PostgreSQL для её настройки работы с 1С не обязательно. Всё и в таком виде будет нормально функционировать. Более детальная настройка требует погружение в специфику работы PostgreSQL. Этим можно заняться в процессе эксплуатации системы, когда накопится статистика и будут видны узкие места (например, неоптимальные настройки по потреблению оперативной памяти).

Создание баз 1С

Во время установки обязательно выбрать компонент Администрирование сервера 1С.

После установки запускаем Администрирование серверов 1С Предприятия x86-64 и добавляем туда сервер 1С на Debian, который мы установили ранее. Можно по dns имени, если оно настроено, либо просто по ip.

Если получите ошибку: «Консоль управления (MMC) не может создать оснастку.«, то сделайте следующее.

Запустите командную строку с правами администратора. Это важно. И выполните там:

"C:\Program Files\1cv8\8.3.19.1150\bin\RegMSC.cmd"

Не забудьте поменять версию платформы на свою. После этого оснастка управления сервером 1С нормально заработает. Подключаем наш сервер на Debian.

Дальше всё управление выполняется как обычно. Создавайте новую базу. В качестве сервера БД указываем 127.0.0.1, пользователя postgres и пароль, который вы задали ранее.

Если получите ошибку «Ошибка соединения с рабочим процессом.» и дальше некоторые подробности сетевых проблем, то добавьте DNS запись или запись в файл hosts с именем и ip адресом вашего сервера 1С. Потом попробуйте создать базу снова. Так же эта ошибка может появляться, если включен и не настроен firewall. Вам как минимум нужно открыть порты tcp 1540, 1541, 1560.

После этого к базе можно подключиться обычной платформой и залить конфигурацию.

В целом, на этом настройка сервера 1С закончена. Дальше ставятся софтовые лицензии и начинается работа. Если у вас лицензия аппаратная, то необходимо установить и настроить HASP Licence manager.

Установка и настройка HASP Licence manager

Для того, чтобы компьютеры могли получать лицензии по сети от сервера, куда вставлен usb ключ, на него надо установить и запустить HASP Licence manager. Для начала вставьте ключ в сервер или пробросьте в виртуальную машину гипервизора (proxmox умеет это делать) и проверьте, видит ли его система:

# lsusb | grep -i hasp

Вы должны увидеть устройство с именем наподобие Aladdin Knowledge Systems HASP copy protection dongle. Если его нет, то разбирайтесь с подключением и пробросом usb портов, если у вас это виртуальная машина. Одним из вариантов проброса hasp ключа по сети является использование usbipd-win.

Дальше идем на страницу https://download.etersoft.ru/pub/Etersoft/HASP/stable/x86_64/Debian/, выбираем свою версию системы и скачиваем файл:

• haspd_8.23-eter3debian_amd64.deb

Устанавливаем пакет haspd, но перед этим установим пару пакетов — make и libc6-i386, если они у вас отсутствуют:

# apt install make libc6-i386
# dpkg -i haspd_8.23-eter3debian_amd64.deb

Если получите ошибку:

/etc/init.d/haspd: 24: SourceIfNotEmpty: not found

То у вас скорее всего пакет с ошибкой в systemd unit. Исправить ошибку очень просто. Открываем файл /etc/init.d/haspd и в 24 строке добавляем пропущенное равно = в указанном параметре. Должно быть вот так:

SourceIfNotEmpty=/etc/sysconfig/haspd

После этого перечитываем настройки systemd:

# systemctl daemon-reload

Запускаем службу haspd и добавляем в автозагрузку:

# systemctl start haspd
# systemctl enable haspd

Проверяем, запустился ли hasp:

# netstat -tulnp | grep hasp
tcp        0      0 0.0.0.0:1947            0.0.0.0:*               LISTEN      1330/hasplmd        
tcp6       0      0 :::1947                 :::*                    LISTEN      1330/hasplmd        
udp        0      0 0.0.0.0:1947            0.0.0.0:*                           1330/hasplmd        
udp6       0      0 :::1947                 :::*                                1330/hasplmd        

Все в порядке. Теперь лицензии должны нормально работать, а клиенты их получать по сети.

Бэкап баз 1С на postgresql

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

# sudo -u postgres psql -U postgres -l

Я создал две тестовые базы: buh30 и zup31. Их и будем бэкапить. Я для этого предлагаю использовать обычный pg_dump, а затем дамп сразу же сжимать архиватором pigz. Его отличительная особенность в том, что он умеет жать всеми ядрами процессора, а не только одним, как, к примеру, gzip. Более подробно про pigz я рассказывал в заметке.

В самом простом случае бэкап базы данных выглядит следующим образом:

# sudo -u postgres /usr/bin/pg_dump -U postgres buh30 | pigz > /mnt/backup/buh30.sql.gz

Если посмотреть на dump, то в случае успешного создания, в начале дампа будет строка:

-- PostgreSQL database dump

а в конце:

-- PostgreSQL database dump complete

В будущем эта информация нам понадобится для мониторинга создания бэкапов и получения уведомления, если дамп не завершился корректно.

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

#!/bin/bash

BASES=("buh30" "zup31")
#BASES=`sudo -u postgres /usr/bin/psql -U postgres -l | grep "_buh\|_zup" | awk '{print $1}'`
DATA=`date +"%Y-%m-%d_%H-%M"`
LOGS=/var/lib/pgpro/service_logs
BACKUPDIR=/var/lib/pgpro/backup

for i in ${BASES[@]};
    do
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Start backup $i" >> $LOGS/$DATA.log
    sudo -u postgres /usr/bin/pg_dump -U postgres $i | pigz > $BACKUPDIR/$DATA-$i.sql.gz
    echo "`date +"%Y-%m-%d_%H-%M-%S"` End backup $i" >> $LOGS/$DATA.log
    done

В скрипте предложены 2 варианта указания списка баз для бэкапа:

1. Последовательное перечисление.
2. Бэкап всех баз, что имеют в своем названии _zup или _buh.

Я обычно ставлю некоторые метки в именах баз, чтобы потом было проще формировать списки для бэкапа. Например, все тестовые базы можно помечать в имени _test — company_buh30_test и потом исключать из списка бэкапа все базы с дополнением _test в названии. Либо просто все рабочие базы сразу именовать с приставкой _buh или _zup и по этому признаку их выводить в список.

Для работы скрипта в таком виде, не забудьте создать каталоги:

# mkdir -p /var/lib/pgpro/service_logs
# mkdir -p /var/lib/pgpro/backup

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

На выходе у вас получится примерно такой список бэкапов баз 1С из postgresql.

В дальнейшем мы их будем забирать отсюда и удалять.

Обслуживание баз 1С на сервере PostgreSQL

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

1. Чистку базы данных — vacuumdb.
2. Перестройку индексов — reindexdb.

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

#!/bin/bash

BASES=("buh30" "zup31")
#BASES=`sudo -u postgres /usr/bin/psql -U postgres -l | grep "_buh\|_zup" | awk '{print $1}'`
DATA=`date +"%Y-%m-%d_%H-%M"`
LOGS=/var/lib/pgpro/service_logs
BACKUPDIR=/var/lib/pgpro/backup

for i in ${BASES[@]};
    do
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Start vacuumdb $i" >> $LOGS/$DATA.log
    sudo -u postgres /usr/bin/vacuumdb --full --analyze --username postgres --dbname $i
    echo "`date +"%Y-%m-%d_%H-%M-%S"` End vacuumdb $i" >> $LOGS/$DATA.log
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Start reindexdb $i" >> $LOGS/$DATA.log
    sudo -u postgres /usr/bin/reindexdb --username postgres --dbname $i
    echo "`date +"%Y-%m-%d_%H-%M-%S"` End reindexdb $i" >> $LOGS/$DATA.log
    echo "=========================================" >> $LOGS/$DATA.log
    done

Я обычно запускаю этот скрипт по ночам сразу после выполнения бэкапа. Имейте ввиду, что подобное обслуживание может занимать много времени, которое будет зависеть от размера баз и производительности сервера. Убедитесь, что с базами никто не работает в часы обслуживания. Если в будни это сложно отследить, так как могут выполнять какие-то работы программисты 1С или обслуживающий персонал, то перенесите выполнение раз в неделю в какой-то выходной день.

Проверка бэкапов postgresql баз

То, что вы настроили дамп баз 1С, еще не значит, что у вас успешно работает бэкап. Дампы надо обязательно проверять. Я для этого использую еще один подобный сервер. Обычно просто клонирую виртуальную машину после того, как полностью её настрою. Тут встает вопрос лицензионности. Сервер 1С на Linux не просит на себя лицензию до какого-то числа пользователей. Точно не помню сколько их может быть, так как в проде всегда покупается лицензия. А вот клон запускается без лицензии только для проверки бэкапов. Пользователи к нему не подключаются. Не уверен, что такая схема эксплуатации допускается без приобретения лицензии, так что используйте её на свой страх и риск.

Как я уже сказал, делается копия рабочего сервера. На нём создаются те же самые базы 1С через панель администрирования. Далее мы на этот сервер забираем дампы с прода. Я это делаю с помощью rsync:

# rsync -av --progress --files-from=<(ssh root@10.20.1.30 '/usr/bin/find /var/lib/pgpro/backup -type f -mtime -1 -exec basename {} \; | egrep -v timestamp') root@10.20.1.30:/var/lib/pgpro/backup/ /data/backup/

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

Эта команда оформляется в скрипт и регулярно запускается. Дальше работает следующий скрипт, который восстанавливает базы данных из дампов.

#!/bin/bash

BASES=("buh30" "zup31")
#BASES=`sudo -u postgres /usr/bin/psql -U postgres -l | grep "_buh\|_zup" | awk '{print $1}'`
BACKUP_DIR="/data/backup"

for i in ${BASES[@]};
    do
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Drop database ${i}"
    sudo -u postgres /usr/bin/dropdb -U postgres ${i}
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Create database ${i}"
    sudo -u postgres /usr/bin/createdb -U postgres -T template0 ${i}
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Start extract $i"
    /usr/bin/find /data/backup -type f -name *${i}* -exec /usr/bin/unpigz '{}' \;
    echo "`date +"%Y-%m-%d_%H-%M-%S"` End extract $i"
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Start restore $i"
    sudo -u postgres /usr/bin/psql -U postgres ${i} < ${BACKUP_DIR}/`ls ${BACKUP_DIR} | grep ${i}` 1>/dev/null
    echo "`date +"%Y-%m-%d_%H-%M-%S"` End restore $i"
    echo "`date +"%Y-%m-%d_%H-%M-%S"` rm dump ${i}"
    /usr/bin/rm ${BACKUP_DIR}/`ls ${BACKUP_DIR} | grep ${i}`
    done

Для каждой базы 1C в postgresql последовательно выполняются следующие действия:

1. Удаление базы — dropdb.
2. Создание базы — createdb.
3. Распаковка дампа — unpigz.
4. Восстановление базы из дампа.
5. Удаление дампа.

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

Выгрузка баз 1С в dt из командной строки Linux

Для того, чтобы точно убедиться в целостности бэкапов баз 1С, настроим автоматическую выгрузку баз, восстановленных из них, в dt файлы. Если эта процедура пройдет успешно можно считать, что бэкапы живые. Существует 2 способа это сделать:

1. Использовать обычный клиент 1С в режиме конфигуратора.
2. Воспользоваться автономным сервером 1С.

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

Основная сложность с клиентом будет в том, что у нас сервер без графического окружения и устанавливать его мне не хочется, так что будем обходиться без него. Нам нужно будет установить программу xvfb для запуска клиента 1С в консоли. А для ее работы нужен пакет libwebkitgtk-3.0-0, которого нет в репах для Debian 11.

Я долго возился с этой историей и никак не мог разрешить все зависимости для корректной работы xvfb. В итоге решил вопрос подключением репозитория от stretch. Для этого создаем файл /etc/apt/sources.list.d/1с-stretch.list следующего содержания:

deb http://deb.debian.org/debian/ stretch main contrib non-free

После этого обновляем пакеты и ищем libwebkitgtk.

# apt update
# apt search libwebkitgtk

Есть то, что нам нужно. Устанавливаем:

# apt install libwebkitgtk-3.0-0

Если все прошло успешно, то ставим дальше xvfb:

# apt install xvfb dbus-x11

Теперь попробуем сделать выгрузку базы 1С в dt напрямую через консоль:

# xvfb-run -a /opt/1cv8/x86_64/8.3.22.1851/1cv8 CONFIG /DumpIB ~/buh30.dt /Out ~/out.log /S 10.20.1.30\\buh30 /N admin /P password /DumpResult ~/result.log

Если у вас всё получилось с первого раза, поздравляю. У меня редко так получается. То лицензию не найдет клиент, то учётка неверная, то еще что-то. Постоянно возникают какие-то накладки, а так как у тебя нет графического окружения, ты не можешь посмотреть, что происходит с клиентом 1С и почему он не выполняет выгрузку в dt. Но эту проблему можно решить. Установим x11vnc, подключим сервер в экрану xvfb и посмотрим, что там происходит.

# apt install x11vnc

Теперь снова запустим xvfb-run и подключимся к его экрану.

# xvfb-run -a /opt/1cv8/x86_64/8.3.22.1851/1cv8 CONFIG /DumpIB ~/buh30.dt /Out ~/out.log /S 10.20.1.30\\buh30 /N admin /P password /DumpResult ~/result.log

Посмотрим параметры, с которыми запустился xvfb:

# ps ax | grep xvfb-run
22027 pts/0    S+     0:00 /bin/sh /usr/bin/xvfb-run -a /opt/1cv8/x86_64/8.3.22.1851/1cv8 CONFIG /DumpIB /root/buh30.dt /Out /root/out.log /S 10.20.1.30\buh30 /N Администратор /DumpResult /root/result.log
22037 pts/0    Sl+    0:00 Xvfb :100 -screen 0 1280x1024x24 -nolisten tcp -auth /tmp/xvfb-run.uNVA1Y/Xauthority
22157 pts/2    S+     0:00 grep xvfb-run

Я выделил жирным ту информацию, что для нас важна. Используем её для запуска vnc сервера:

# x11vnc -display :100 -bg -nopw -listen 10.20.1.30 -xkb -auth /tmp/xvfb-run.uNVA1Y/Xauthority

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

Если вы всё укажете верно, то выгрузка пройдёт корректно. На выходе у вас будет:

1. dt файл с базой 1С
2. out.log с информацией в нём в случае успеха: «Выгрузка информационной базы успешно завершена»
3. result.log с информацией в нем в случае успеха: «0»

Записи в лог файлах можно использовать для мониторинга результатов выгрузки. Напомню, что я выгрузку в dt настроил на втором сервере, где тестируются бэкапы. Вы можете всё то же самое настроить и на боевом, если у вас есть потребность в сохранении .dt выгрузок через консоль в linux сервере. Это достаточно удобно для автоматизации. Можно не только дампы postgresql баз снимать, но подстраховываться 1сными выгрузками. Единственное, в чем будет проблема, если делать это на боевом — вам придётся всех выгонять из баз, иначе выгрузка не пройдет. На резервном сервере с этим проблем нет, так как там никто не работает, поэтому dt я выгружаю именно там и потом передаю их на бэкап сервер. Плюс, на этом сервере стоит во всех базах блокировка регламентных заданий.

В завершении этой темы приведу свой простой скрипт по автоматизации этого процесса:

#!/bin/bash

BASES_ZUP=`/usr/bin/psql -U postgres -l | grep "_zup" | awk '{print $1}'`
BASES_BUH=`/usr/bin/psql -U postgres -l | grep "_buh" | awk '{print $1}'`
BACKUP_DIR="/data/dt"
USER_ZUP="adminzup"
PASS_ZUP="passzup"
USER_BUH="adminbuh"
PASS_BUH="passbuh"

/usr/bin/rm -f /data/dt/*

for i in ${BASES_BUH};
    do
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Start export dt database ${i}"
    /usr/bin/xvfb-run -a /opt/1cv8/x86_64/8.3.22.1851/1cv8 CONFIG /DumpIB ${BACKUP_DIR}/`date +"%Y-%m-%d_%H-%M-%S"`-${i}.dt /Out ${BACKUP_DIR}/`date +"%Y-%m-%d_%H-%M-%S"`-${i}-out.log /S 10.1.5.12\\${i} /N ${USER_BUH} /P ${PASS_BUH} /DumpResult ${BACKUP_DIR}/`date +"%Y-%m-%d_%H-%M-%S"`-${i}-result.log
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Finish export dt database ${i}"
    done

for i in ${BASES_ZUP};
    do
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Start export dt database ${i}"
    /usr/bin/xvfb-run -a /opt/1cv8/x86_64/8.3.22.1851/1cv8 CONFIG /DumpIB ${BACKUP_DIR}/`date +"%Y-%m-%d_%H-%M-%S"`-${i}.dt /Out ${BACKUP_DIR}/`date +"%Y-%m-%d_%H-%M-%S"`-${i}-out.log /S 10.1.5.12\\${i} /N ${USER_ZUP} /P ${PASS_ZUP} /DumpResult ${BACKUP_DIR}/`date +"%Y-%m-%d_%H-%M-%S"`-${i}-result.log
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Finish export dt database ${i}"
    done

В моем примере все базы промаркированы в имени файла приставкой _zup или _buh. У каждого типа базы своя учётка для экспорта в dt. Перед началом экспорта я удаляю все старые выгрузки, которые лежат в директории, так как они уже уехали на бэкап сервер. Если вам не нужно ничего удалять, уберите этот код с rm. Разумно оставить этот запасной сервер и в качестве хранения бэкапов, так как тут они уже проверены. А при передачи их по сети есть шанс, что они побьются и их по хорошему надо будет еще раз проверять уже на месте окончательного хранения.

С помощью автономного сервера база выгружается вот так:

# /opt/1cv8/x86_64/8.3.22.1851/ibcmd infobase dump --db-server=localhost --dbms=postgresql --db-name=basa1 --db-user=postgres --db-pwd=parol /mnt/backup/basa1.dt

Можете в скриптах использовать этот способ. Через консоль и автономный сервер можно загрузить данные в базу 1С из dt файла. К примеру, загрузим предыдущую выгрузку в новую базу:

# /opt/1cv8/x86_64/8.3.18.1363/ibcmd infobase create --db-server=localhost --dbms=postgresql --db-name=basa2 --db-user=postgres --db-pwd=parol --create-database --restore=/mnt/backup/basa1.dt

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

# /opt/1cv8/x86_64/8.3.18.1363/ibcmd infobase config check --db-server=localhost --dbms=postgresql --db-name=basa2 --db-user=postgres --db-pwd=parol

Мониторинг бэкапов 1С

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

1. Проверяю, что дамп 1с базы, сделанный напрямую из postgresql, завершился корректно.
2. Слежу за экспортом в dt баз, восстановленных с дампов боевого сервера.
3. Отправляю всё на бэкап сервер и слежу за тем, чтобы туда приехало всё, что должно приехать.

Статья уже получилась очень объемной, так что я не буду в ней раскрывать по шагам тему мониторинга, потому что всё это у меня уже описано в других статьях. Я дам на них ссылки и прокомментирую. Весь мониторинг настроен в Zabbix.

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

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

Все это есть с примерами в статье, которую я привёл.

Заключение

Я рассмотрел практически все аспекты, связанные с разворачиваем Сервера 1С с базой PostgreSQL полностью на Linux сервере. Весь материал не гипотетический, а основанный на моем лично опыте подобных установок. Все примеры, скрипты, подходы взяты с работающих по этой схеме серверов. Поэтому нужно понимать, что описанная выше настройка не набор лучших практик, а мой субъективных опыт. Возьмите его себе на вооружение, но настройте всё так, как нужно именно вам и как вы считаете правильно. Если я что-то делаю неверно и можно сделать лучше, удобнее, поделитесь этим в комментариях.

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

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

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите подробнее программу по ссылке.

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.