Home » 1C » Бэкап и восстановление базы 1С в бд postgresql, обслуживание базы

Бэкап и восстановление базы 1С в бд postgresql, обслуживание базы

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

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

Данная статья является частью единого цикла статьей про сервер Debian.

Введение

Ранее я рассказывал о том, как установить и настроить postgresql для работы с 1С, а затем как провести анализ производительности базы 1С и по возможности увеличить быстродействие. После успешного выполнения первых двух задач, мы можем приступать к эксплуатации системы. Когда рабочая база 1С уже на сервере, обязательно нужно настроить ее регулярный бэкап. Желательно так же периодически проводить очистку и переиндексацию sql базы. Это увеличит ее быстродействие. Выполнять эти операции лучше всего автоматически, в нерабочее время. Именно этим мы и займемся в этой статье.

Бэкап и восстановление базы 1C в бд postgresql

Способов бэкапа базы данных postgresql много. Я буду использовать самый простой — выгрузка базы данных в обычный текстовый sql скрипт с помощью pg_dump. Подробно о работе этой утилиты и ее настройках можно прочитать вот тут — https://postgrespro.ru/docs/postgrespro/9.6/app-pgdump. В сети много примеров и готовых скриптов для решения вопроса архивации баз postgresql. Например, есть вот такой скрипт. Когда я его увидел, мне просто стало лень с ним разбираться. Написать простенький свой мне гораздо проще.

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

Редактируем в файле /etc/postgresql/9.6/main/pg_hba.conf строку, приведя ее к такому виду:

local   all             all                                     trust

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

# systemctl restart postgresql

Бэкап базы данных выполняется простой командой:

# pg_dump -U postgres base1c | pigz > /backup/base1c.sql.gz
postgresимя пользователя базы данных
base1cназвание бд с 1С
pigzархиватор
base1c.sql.gzфайл, куда будет сохранена резервная копия

Обращаю внимание на архиватор pigz. Я его использую, потому что он умеет жать данные, нагружая все ядра процессора, в отличие от gzip. Прирост производительности 2-3 раза. Рекомендую. На debian он ставится из стандартного репозитория:

# apt-get -y install pigz

В centos из epel:

# yum -y install epel-release
# yum -y install pigz

Попробуйте вручную в консоли выполнить команду и посмотреть на результат. Вы должны получить заархивированный файл с текстовыми sql командами в открытом виде. Теперь попробуем восстановить базу данных 1С из архива. Тут будут нюансы. Первым делом разархивируем файл:

# unpigz /backup/base1c.sql.gz

Файл будет распакован, а архив удален. Чтобы сохранить архив, можно использовать такую команду:

# unpigz -c /backup/base1c.sql.gz > base1c.sql

Создадим на сервере новую базу данных, в которую будем восстанавливать резервную копию. Перед этим посмотрим список баз данных на сервере:

# psql -U postgres -l

Список баз postgresql

Создаем новую базу данных:

# createdb --username postgres -T template0 base1c-restored

Смотрим, что получилось:

Добавление базы postgresql через консоль

Базу данных создали. Теперь загружаем в нее наш бэкап 1с:

# psql -U postgres base1c-restored < /backup/base1c.sql

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

Я сначала пошел по другому пути. Создал в консоли пустую базу, загрузил в нее бэкап через консоль postgresql. Архив вроде бы загрузился, но в базу я не мог войти, не проходила авторизация. То есть возникли какие-то проблемы. Когда сделал, как описал выше, без проблем все заработало сразу. Проверил базу, все было в порядке.

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

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

# cat /root/bin/backup-sql.sh
#!/bin/sh

# Устанавливаем дату
DATA=`date +"%Y-%m-%d_%H-%M"`

# Записываем информацию в лог с секундами
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start backup base1c" >> /var/log/postgresql/service.log

# Бэкапим базу данных base1c и сразу сжимаем
/usr/bin/pg_dump -U postgres base1c | pigz > /backup/$DATA-base1c.sql.gz

echo "`date +"%Y-%m-%d_%H-%M-%S"` End backup base1c" >> /var/log/postgresql/service.log

# Удаляем в папке с бэкапами архивы старше 3-х дней
/usr/bin/find /backup -type f -mtime +3 -exec rm -rf {} \;

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

Использование программы PostgreSQL Backup

Для бэкапа базы данных постгрес есть удобная и бесплатная для двух баз программа под windows — PostgreSQL Backup. Я ее установил, проверил, сделал бэкап, потом восстановил из бэкапа. Все отлично работает. Из полезных функций:

  • встроенный планировщик
  • автоматическое сжатие бэкапа
  • отправка оповещений на email

Программа PostgreSQL Backup

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

Обновление статистики и реиндексация в postgresql

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

Выполняем очистку и анализ базы данных 1С:

# vacuumdb --full --analyze --username postgres --dbname base1c

Реиндексация таблиц базы данных:

# reindexdb --username postgres --dbname base1c

Завернем все это в скрипт с логированием времени выполнения команд:

# cat /root/bin/service-sql.sh
#!/bin/sh

# Записываем информацию в лог
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start vacuum base1c" >> /var/log/postgresql/service.log
# Выполняем очистку и анализ базы данных
/usr/bin/vacuumdb --full --analyze --username postgres --dbname base1c
echo "`date +"%Y-%m-%d_%H-%M-%S"` End vacuum base1c" >> /var/log/postgresql/service.log

sleep 2

echo "`date +"%Y-%m-%d_%H-%M-%S"` Start reindex base1c" >> /var/log/postgresql/service.log
# Переиндексирвоать базу
/usr/bin/reindexdb --username postgres --dbname base1c
echo "`date +"%Y-%m-%d_%H-%M-%S"` End reindex base1c" >> /var/log/postgresql/service.log

Сохраняем скрипт и добавляем в планировщик. Хотя я для удобства сделал еще один скрипт, который объединяет бэкап и обслуживание и уже его добавил в cron:

# cat all-sql.sh
#!/bin/sh

/root/bin/backup-sql.sh
sleep 2
/root/bin/service-sql.sh

Добавялем в /etc/crontab:

# Бэкап и обслуживание БД
1 3 * * * root /root/bin/all-sql.sh

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

Описанные выше операции очистки и переиндексации можно делать в ручном режиме в программе под windows — pgAdmin. Рекомендую ее установить на всякий случай. Достаточно удобно и быстро можно посмотреть информацию или выполнить какие-то операции с базой данных посгрес.

Программа pgAdmin

Заключение

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

Напоминаю, что данная статья является частью единого цикла статьей про сервер Debian.

Онлайн курс Основы сетевых технологий

Теоретический курс с самыми базовыми знаниями по сетям. Курс подходит и начинающим, и людям с опытом. Практикующим системным администраторам курс поможет упорядочить знания и восполнить пробелы. А те, кто только входит в профессию, получат на курсе базовые знания и навыки, без воды и избыточной теории. После обучения вы сможете ответить на вопросы:
  • На каком уровне модели OSI могут работать коммутаторы;
  • Как лучше организовать работу сети организации с множеством отделов;
  • Для чего и как использовать технологию VLAN;
  • Для чего сервера стоит выносить в DMZ;
  • Как организовать объединение филиалов и удаленный доступ сотрудников по vpn;
  • и многое другое.
Уже знаете ответы на вопросы выше? Или сомневаетесь? Попробуйте пройти тест по основам сетевых технологий. Всего 53 вопроса, в один цикл теста входит 10 вопросов в случайном порядке. Поэтому тест можно проходить несколько раз без потери интереса. Бесплатно и без регистрации. Все подробности на странице .

Помогла статья? Есть возможность отблагодарить автора

Автор Zerox

Zerox
Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству.

36 комментариев

  1. Аватар

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

    #!/bin/bash
    set -e -u -o pipefail

    db_list=( «$@» )
    SHORTHOSTNAME=»${HOSTNAME/.*/}»
    DATE=»$(printf ‘%(%Y-%m-%d)T’)»
    DIRECTORY=»/var/backup/postgresql/$DATE»

    if [ ! -d «$DIRECTORY» ]; then
    echo «Creating backup directory: $DIRECTORY»
    mkdir —parents «$DIRECTORY»
    fi

    PROC_NUM=$(( $(nproc) / 2 ))

    if [ «$PROC_NUM» -lt 1 ]; then
    PROC_NUM=1
    fi

    for i in ${db_list[@]}; do
    TIME=»$(printf ‘%(%H-%M-%S)T’)»
    FILE=»${DATE}_${TIME}_${i}_pg_dump.sql.gz»
    echo «Dumping PostgreSQL to $DIRECTORY/$FILE»
    sudo -u postgres pg_dump -d $i —clean —verbose | pigz —processes «$PROC_NUM» —stdout > «$DIRECTORY/$FILE»
    done

    Если очень надо, то можно использовать массив данных db_list чтобы распараллелить по процессам.

    В любом случае, спасибо за еще одно мнение.

  2. Аватар

    Автор, спасибо за статью. Есть одно дополнение для конфигураций 1С УПП, при котором pg_dump не работает.
    Если размер таблицы public.config (конфигурации 1С) превысит 1Гб, а для PostgreSQL это является пределом для поля большого размера, после чтения и распаковки в стандартный поток вывода stdout pg_dump.exe завершится с ошибкой:

    pg_dump: Ошибка выгрузки таблицы «config»: сбой в PQgetResult().
    pg_dump: Сообщение об ошибке с сервера: invalid memory alloc request size 11173708065
    pg_dump: Выполнялась команда: COPY public.config (filename, creation, modified, attributes, datasize, binarydata) TO stdout;

    Резервную копию тогда надо будет делать вот так: http://infostart.msk.ru/public/956734/
    _

    • Аватар

      Вот мой скрипт:

      #!/bin/sh
      # Скрипт резервного копирования баз данных PostgreSQL
      # Копирование базы 1С на лету во время работы пользователей с сохранением целостности с помощью команд pg_dump.exe, psql.exe
      # Для этого в общем случае алгоритм следующий:
      # Шаг 1. Выгружаем с помощью pg_dump все таблицы из базы данных, кроме данных таблицы config (т.е. для config выгружаем только ее схему)
      # Шаг 2. Выгружаем с помощью psql данные таблицы public.config с помощью COPY WITH BINARY
      # Шаг 3. Производим очистку и переиндексацю базы данных

      PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

      #Логин и пароль пользователя, имеющего право выполнять резервные копии баз данных
      dbUser=postgres
      PGPASSWORD=password
      export PGPASSWORD
      slog=/var/log/postgresql/service.log

      #Путь резервных копий
      pathB=/backups/sdb1/sql/databases

      #Резервирование базы данных
      #Задаем имя резервируемой базы данных
      database=gilev
      #Задаем переменную date для того чтобы резервная копия базы данных и таблицы config имели одно и то же время
      date=$(date «+%Y-%m-%d_%H-%M»)

      # Записываем информацию в лог с секундами
      echo «`date +»%Y-%m-%d_%H-%M-%S»` Запуск резервного копирования базы — ${database}» >> ${slog}

      #Выгружаем все таблицы из базы данных, кроме данных таблицы config (т.е. для config выгружаем только ее схему)
      #pg_dump -U $dbUser —exclude-table-data=config $database | pigz > $pathB/${database}_${date}_without_public.config.sql.gz
      #Выгружаем в несколько потоков (10 потоков)
      pg_dump —format=directory —jobs=10 —blobs -U $dbUser —exclude-table-data=config —file=$pathB/${database}_${date}_without_public.config $database

      #Выгружаем данные таблицы public.config с помощью COPY WITH BINARY:
      psql -U $dbUser —command=»COPY public.config TO ‘$pathB/${database}_${date}_public.config.sql’ WITH BINARY;» $database

      # Записываем информацию в лог с секундами
      echo «`date +»%Y-%m-%d_%H-%M-%S»` Резервное копирование базы — ${database}» выполнено >> ${slog}

      #Для выгрузки в сжатом состоянии. Как показала практика, не поддается сжатию
      #psql -U $dbUser —command=»COPY public.config TO PROGRAM ‘pigz -0 > $pathB/${database}_${date}_public.config.sql.gz’ WITH BINARY;» $database

      #Выполняем очистку и анализ базы данных 1С
      echo «`date +»%Y-%m-%d_%H-%M-%S»` Запуск очистки базы — ${database}» >> ${slog}
      vacuumdb -U $dbUser —full —analyze —dbname=${database}
      echo «`date +»%Y-%m-%d_%H-%M-%S»` Очистка базы — ${database} выполнена» >> ${slog}

      # Переиндексировать базу
      echo «`date +»%Y-%m-%d_%H-%M-%S»` Запуск реиндексации базы — ${database}» >> ${slog}
      reindexdb -U $dbUser —dbname=${database}
      echo «`date +»%Y-%m-%d_%H-%M-%S»` Реиндексация базы — ${database} выполнена» >> ${slog}

      # Удаляем в папке с бэкапами архивы старше 31-х дней
      find /${pathB} -type f -mtime +31 -exec rm -rf {} \;
      find /${pathB} -type d -mtime +31 -exec rm -rf {} \;

      unset PGPASSWORD

  3. Аватар
    Ростислав

    Поддерживает ли Postgres дифференциальные бекапы, как вы решаете это проблему?

    • Zerox

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

  4. Аватар

    Спасибо дружище!

  5. Аватар
    Валерий

    Не знаю в способе ли дело, но после восстановления бэкапа в базу не зайти ))) «Невосстановимая ошибка
    Ошибка при выполнении запроса POST к ресурсу /e1cib/login:
    по причине:
    Ошибка при выполнении операции с информационной базой
    Запись не найдена в менеджере имен базы данных.»
    Менял релизы платформы 1с (8.3.12.1595, 8.3.12.1790, 8.3.14.1565) , менял версии PostgreSQL ( 9.6, 10.5 )
    Тестирован на нескольких базах которые находятся в разных местах, на разных серверах…
    Так что коллеги этот PostgreSQL на Ваш страх и риск

    • Zerox

      Я 100% проверял все это и не раз. При обновлении postgresql делал дамп на старой версии и заливал в новую. Используется стандартная утилита pg_dump. Тут нечему не работать. Возможно проблема в чем-то другом.

      • Аватар
        Валерий

        К Вам никаких претензий. Пару месяцев назад у меня тоже получилось восстановить 5 баз разом, бэкапы были сделаны по Вашему примеру. Но после этого удачного случая не смог более его повторить… Я тут написал чтобы люди понимали что что-то может пойти не так и особо не расслаблялись. Сейчас я делаю автоматические бэкапы .dt файлов средствами 1с, проверенный вариант годами. Сама связка Linux + 1c + PostgreSQL вполне устраивает, но бэкапы PostgreSQL это конечно удручает. А может это и не в бэкапах PostgreSQL дело, а просто в кривых руках программеров 1с…

        • Zerox

          Тут есть нюансы. Я знаю, что начиная с версии 8.3.14 1с не работает с базами postgresql 9.x Я уже не помню точно, какую ошибку выдает, но возможно именно такую же, как вы описали. То есть тут много нюансов именно по всей связке. Сами бэкапы postgresql через pg_dump работают надежно.

  6. Аватар
    Александр

    Как в вашем скрипте перечислить базы 1с? Просто копировать рядом такую же строку, только менять имя базы ?

    • Zerox

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

      • Аватар
        Александр

        Так можно делать?
        #!/bin/sh

        # Записываем информацию в лог
        echo «`date +»%Y-%m-%d_%H-%M-%S»` Start vacuum BASE1» >> /var/log/postgresql/service.log
        echo «`date +»%Y-%m-%d_%H-%M-%S»` Start vacuum BASE2» >> /var/log/postgresql/service.log

        # Выполняем очистку и анализ базы данных
        /usr/bin/vacuumdb —full —analyze —username postgres —dbname BASE1
        echo «`date +»%Y-%m-%d_%H-%M-%S»` End vacuum BASE1» >> /var/log/postgresql/service.log

        /usr/bin/vacuumdb —full —analyze —username postgres —dbname BASE2
        echo «`date +»%Y-%m-%d_%H-%M-%S»` End vacuum BASE2» >> /var/log/postgresql/service.log
        sleep 3

        echo «`date +»%Y-%m-%d_%H-%M-%S»` Start reindex BASE1» >> /var/log/postgresql/service.log
        echo «`date +»%Y-%m-%d_%H-%M-%S»` Start reindex BASE2» >> /var/log/postgresql/service.log

        # Переиндексировать базу
        /usr/bin/reindexdb —username postgres —dbname BASE1
        echo «`date +»%Y-%m-%d_%H-%M-%S»` End reindex BASE1» >> /var/log/postgresql/service.log

        /usr/bin/reindexdb —username postgres —dbname BASE2
        echo «`date +»%Y-%m-%d_%H-%M-%S»` End reindex BASE2» >> /var/log/postgresql/service.log

        • Zerox

          Можно, но логичнее сделать вот так:

          #!/bin/sh
          
          # Записываем информацию в лог
          echo «`date +»%Y-%m-%d_%H-%M-%S»` Start vacuum BASE1» >> /var/log/postgresql/service.log
          
          # Выполняем очистку и анализ базы данных
          /usr/bin/vacuumdb —full —analyze —username postgres —dbname BASE1
          echo «`date +»%Y-%m-%d_%H-%M-%S»` End vacuum BASE1» >> /var/log/postgresql/service.log
          
          echo «`date +»%Y-%m-%d_%H-%M-%S»` Start vacuum BASE2» >> /var/log/postgresql/service.log
          
          /usr/bin/vacuumdb —full —analyze —username postgres —dbname BASE2
          echo «`date +»%Y-%m-%d_%H-%M-%S»` End vacuum BASE2» >> /var/log/postgresql/service.log
          sleep 3
          
          echo «`date +»%Y-%m-%d_%H-%M-%S»` Start reindex BASE1» >> /var/log/postgresql/service.log
          
          # Переиндексировать базу
          /usr/bin/reindexdb —username postgres —dbname BASE1
          echo «`date +»%Y-%m-%d_%H-%M-%S»` End reindex BASE1» >> /var/log/postgresql/service.log
          
          echo «`date +»%Y-%m-%d_%H-%M-%S»` Start reindex BASE2» >> /var/log/postgresql/service.log
          
          /usr/bin/reindexdb —username postgres —dbname BASE2
          echo «`date +»%Y-%m-%d_%H-%M-%S»` End reindex BASE2» >> /var/log/postgresql/service.log
  7. Аватар

    Хорошо бы увидеть в обновлении статьи как Вы решаете задачу одним скриптом с бекапом, вакуумом и индексированием одновременно 5 баз, к примеру :-)

    • Аватар

      Пожалуйста, можете добавить в статью. Добавить бекаприрование не составит труда.

      #!/bin/bash
      IFS=$’\n’

      DATA=`date +»%Y.%m.%d %H:%M»`

      echo «$DATA Start Postgres DB service» >> /var/log/postgresql/service.log
      for var in `psql -l -p 6432 | awk ‘{ print $1,$2}’ | grep -v «(» | grep -v «template*» | grep -v «test*» | grep -v «Список» | grep -v «Имя» | grep -v «+» | sed ‘s,|,,g’ | sed ‘s/[ \t]*$//’ | awk ‘NF > 0’`
      do
      #echo $var
      vacuumdb -p 6432 —full —analyze —dbname $var
      reindexdb -p 6432 —dbname $var
      done
      echo «`date +»%Y.%m.%d %H:%M»` END Postgres DB service» >> /var/log/postgresql/service.log
      echo «—————————————————-» >> /var/log/postgresql/service.log

    • Zerox

      А в чем тут проблема? Можно последовательно работать с каждой базой, перечислив базы вручную, или как предложил автор выше, циклом.

      • Аватар

        Проблема в том, что пример выше выполняет команды ПОСЛЕДОВАТЕЛЬНО. А нужно чтобы скрипт запускал каждую команду в фоне. Чтобы команды выполнялись ПАРАЛЛЕЛЬНО. Так как приходится ждать пока скрипт забекапит одну базу, потом приступит ко второй, затем третьей и тд. А надо, чтобы р-раз и htop показывает одновременный pg_dump каждой базы в отдельном процессе и нагружает соответственно ВСЕ ядра. А не 1.

        • Аватар

          вот надёргал из инетов что-то похожее https://pastebin.com/KRSnzcuB

        • Zerox

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

      • Аватар

        И вообще, хотелось бы увидеть от Вас обзор на barman :-)

  8. Аватар

    Спасибо за статью!

    createdb —username postgres -T template0 base1c-restored

    Чем отличается template0 от template1?

  9. Аватар

    статья хуйня. после рестора такого бэкапа 1с орет на несоответствие структуры

  10. Аватар

    подскажите пожалуйста, а обязательно ли делать — Обновление статистики и реиндексация, а в конфигах postgres есть параметр autovacum

  11. Аватар

    Добрый день. Не подскажете, как с паролем скрипт запускать? я все не могу добиться работы через файл .pgpass.
    В файле pg_hba.conf строка такая должна быть?
    local all all peer

    • Аватар

      D cronetab, где
      # Бэкап и обслуживание БД
      1 3 * * * root /root/bin/all-sql.sh

      Вместо root укажите postgres, тогда команды внутри скрипта будут запускаться от имени пользователя postgres и пароль для авторизации не понадобится. Своего рода использование su — postgres

  12. Аватар
    Владимир

    Автор!
    Спасибо тебе за то, что ты есть и публикуешь свои наработки!

  13. Аватар
    Алексей

    Отличная статья, спасибо!

Добавить комментарий

Ваш e-mail не будет опубликован.

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.