Нужно спрашивать в поддержке postgrespro.

не сталкивался, и не 1С.

но я бы, возможно, добавил --quote-all-identifiers и --inserts к pg_dump, и заодно поменял бы gzip на pigz (если есть такая возможность в Astra SE).

К сожалению мы используем бесплатную версию postgrespro-1c-15, поддержки нет.

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

Мы используем виндовую софтину «Effector Saver» (не реклама, ссылка не реферальная). Она умеет закрывать коннекты, правильно «готовит» и бэкапит базу по расписанию цепляясь к линукс-серверу, выгружает в сетевой каталог NAS, ротацию тоже обеспечивает. Когда нибудь я научусь делать всё это скриптами из Линукс, но пока меня эта софтина устраивает.

Вообще 1с так бекапить не совсем правильно.

Вполне правильно. Многие базы работают 24/7, никаких перерывов там не бывает.

А иначе можно неконсистентный бэкап получить.

pg_dump гарантирует консистентный бэкап, 1С или нет.

То есть ты хочешь сказать что можно прямо вот не разгоняя юзеров, в процессе их активной работы, взять и сделать pg_dump? А потом взять и восстановиться с него, и базу после этого не придётся «в порядок» приводить? Может она для постгреса консистентная, не факт что она будет таковой для самой 1с. Типа как с XFS бывает после сбоя, FS консистентна, структура не нарушена, открытые на момент ребута файлы содержат нули. Но всё цело, с точки зрения структуры ФС, а не данных на ней. Ну, ОК, как скажешь.

Я реально в этом не шарю, возможно эта софтина действительно ненужный костыль. Мне её 1сники присоветовали когда то, но для них самих линукс и постгрес в нём тёмный лес, они виндузятники все.

не реклама, ссылка не реферальная

Рекламировать можно и нереферальными ссылками. И даже вообще без ссылок.

Можно, но это не реклама. Я ни копейки с этого не получу. Просто поделился тем что сам использую.

Восстанавливать нужно в пустую, свежесозданную базу.

А уже в настройке конфигурации переключаешь их по мере необходимости.

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

Не отмазывайся, все знают что ты их рекламный агент.

Эти «все» сейчас с тобою в одной комнате?

Да.

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

То есть ты хочешь сказать что можно прямо вот не разгоняя юзеров, в процессе их активной работы, взять и сделать pg_dump?

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

Типа как с XFS бывает после сбоя, FS консистентна, структура не нарушена, открытые на момент ребута файлы содержат нули.

Это было исправлено, если не ошибаюсь, в 2008-м. Битые файлы, впрочем, получить можно, как и на любой не-CoW ФС.

Мне её 1сники присоветовали когда то, но для них самих линукс и постгрес в нём тёмный лес, они виндузятники все.

1С официально рекомендует использовать средства резервного копирования СУБД, это всё. Выгрузку в собственном кроссплатформенном формате, которая делается в монопольном режиме, они рекомендовать не спешат.

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

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

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

Благодарю. Странно что именно они мне её и рекомендовали, выгрузку в монопольном режиме через свой формат. Но возможно тогда среди них единства не было, я вообще саппорт по линукс серверу с postgresql тогда получить от них никак не мог. Либо тупо игнор, либо, если через начальство давить — «используйте microsoft sql и windows, как все, зачем вам эта экзотика».

Теперь буду знать что штатные средства резервного копирования СУБД в случае с 1с это не больно и не страшно, а моя практика устарела.

Странно что именно они мне её и рекомендовали, выгрузку в монопольном режиме через свой формат

Именно как бэкап оно имеет большой минус — может оказаться, что оно не восстанавливается даже на той версии платформы, на который делалось. Зато может загрузиться на другой 🤷 Лично имел такой неприятный опыт. Нагуглить можно по запросу «1с ошибка формата потока». Хотя сейчас это вроде редкость. Этот формат подходит для переноса между разными СУБД или в/из файловой базы, используется для передачи базы кому-то. Использовать как бэкап можно, но совершенно точно не как единственный.

Восстановление, так и делается. Убивается старая тестовая база создаётся новая и в нее заливается дамп.

Ошибка «лишние данные после последнего ожидаемого столбца» возникает при обработке данных в таблице, когда в ней присутствует неправильное количество столбцов

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

Я восстанавливая дамп в только что созданную чистую базу.

/usr/bin/pg_dump -U postgres $i | gzip > $BACKUPDIR/$i/$DATE-$i.gz 2>> $LOGS/$DATE.log

Есть мнение, что это НЕ удачное решение. Перенаправляй в лог весь скрипт. А так скорее всего попадёт последняя команда

Да, и если проверяешь $?, не забудь про

set -o pipefail

Попробуй ещё делать дамп с --format=c. По крайней мере, у меня с ним нет проблем (но у меня и PG от 1С, а не postgrespro).

Можно ещё попробовать написать в поддержку 1С, хотя сильно рассчитывать на это я бы не стал.

попробуй если БД небольшая сдампить не командой COPY а через INSERT. Может быть проблемы со спец символами в текстовых полях 1С БД

У меня такая конструкция работает 20+ лет на различных версиях 1с и различных Linux c базами 24/7. Впервые вижу такую ошибку.
Попробуйте перед бэкапом vacuumdb -U postgres --analyze --dbname basename, может мусор какой залетел.

Не совсем понял про перенаправление всего скрипта. То есть в crontab прописать:

0 0 0 0 0 /script.sh >> /logfile.log 2&>

Или я не правильно понял?

Раньше так и делал всегда, но восстановление переодически всеравно не проходит, только ОШИБКА менее информативна:

2023-12-11_02-01-42 : Restore database erp_study_check from /backup/db-backups/erp_study/2023-12-11_00-01-erp_study.dump pg_restore: ошибка: не удалось распаковать данные: incorrect data check

А тестирование средствами 1С не пробовали?

Доброго времени суток! У 1с есть утилита командной строки для создания резервных копий: ibcmd

/opt/1cv8/x86_64/8.3.21.1775/./ibcmd infobase dump –dbms=PostgreSQL –db-server=localhost –db-user=‘postgres’ —db-pwd=‘пароль_суперпользователя_postgres’ —db-name=название базы данных /home/postgres/имя_базы.dt —user=администратор_базы —password=пароль_администратора_базы

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

Да и у меня это отлично работает на ubuntu, centos. Но теперь к нам пришел AstraLinux, и новые «отечественные» сервера… Получается что в момент создания файла дампа в него попадают некорректные данные.

Можно попробовать, спасибо, но хотелось бы ограничится средствами СУБД в данном случае.

Так а просто найти эту строчку, где возникает ошибка и глазами посмотреть что там не так?

zgrep 88b8b413-bc88-4af9 my_dump.sql.gz

Если вы говорите, что ошибки бывают разные, то может проблема на уровне физического носителя.

Вот картинка - imgbb, сложно понять что пошло не так, но если выше и ниже все данные строки в одной линии то в проблемном месте данные на много строк размазаны.

Насколько я понимаю - то, что вы называете «на много строк размазано» это у вас blob (bytea). Возможно картинка. Или другие какие-то двоичные данные.

А поле перед ним 3236026 это возможно размер этих данных.

Т.е. выглядит вполне нормально. Он просто большой рядом с другими.

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

А теперь к странностям:

предыдущий картинка img1 - это строки из файла дампа который я скачал себе 18 го числа.

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

открытые на момент ребута файлы содержат нули.

Это баг вообще то давно исправили …

а вчём проблема? postgresql давно версионник!

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

при большой БД таблицу конфигурации нужно отдельно складывать.

Можно подробнее?

Типа такого :

https://infostart.ru/1c/articles/956734/

Понятно.

Это требуется, когда база находится на поддержке у двух и более конфигураций поставщика и (или) очень много изменений внесено в конфигурацию.

Внесение изменений не расширениями звучит как legacy, должны страдать.

А теперь к странностям:

На мой взгляд - где-то у вас на пути «дамп»->«сжатие»->«скачал себе» теряются данные.

Если хотеть выяснить что именно пишется вместо данных - оба блоба выдернуть из этих двух дампов и сравнить. Как минимум начала-то у них одинаковые a47dc7.

Или память, или диск, или сеть (или флешка, или что еще может быть под «скачал себе») - как-то так выглядит.

По запросу pg_dump bytea Гугл много чего говорит. Но не про потерю же данных.

Вопрос не ко мне а к программерам 1С, опять же все это тянется уже более 20 лет так что им виднее …

Пока выходит так:

• 18.12.23 в 00:01 создается дамп базы
• 18.12.23 в 00:02 с бэкапа разворачивается чистая БД (неудачно)
• 18.12.23 в ~08:30 я скачиваю дамп себе на ПК и смотрю на строку с ошибкой - img1
• 19.12.23 в ~13:10 я повторно скачиваю неудачный дамп себе на ПК и снова смотрю на строку, но в этот раз она выглядит иначе img1. Решаю попробовать снова восстановится с этого дампа и на этот раз все проходит гладко. Восстановление проходит исключительно на виртуалке не на моем ПК.

Инфраструктура:

3 лезвия подключены к СХД - все данные там. Нарезаны виртулки.

Выходит что через какой-то промежуток времени плохой дамп стал хорошим. Похоже что проблема в СХД…

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

1. Ежедневные дампы снимаются в 00:01 и затем разворачиваются в 02:00 на чистые тестовые базы (всего на данные момент 5 БД).
2. Иногда развертывание проходит с ошибками в одной или нескольких базах (как я уже показывал). Дампы, развернутые с ошибкой, я скачивал себе на ПК. Внутри находил строки, на которые ругался postgres при развороте. Так же при разархивировании файла дампа выдавалась ошибка: gz-error.
3. На следующий день создаются новые дампы и снова разворачиваются, возможно также с ошибкой. Но теперь предыдущие дампы, которые разворачивались с ошибкой, при повторном развороте отрабатывают без ошибок. Также я заново скачивал архив с предыдущим дампом и при разархивировании он не выдавал ошибок как в прошлый раз.

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

Такое ощущение что postgres «держит» дамп пока не создастся следующий. Хотя бывает, что дампы разворачиваются с первого раза.

Вообще похоже на плавающую ошибку в памяти. Память с ecc? Что журналы говорят?

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

Честно говоря не знаю как проверить память. Вот что выдает demidecode:

xxx@srv0:~$ sudo dmidecode -t memory
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.0 present.

Handle 0x002E, DMI type 16, 23 bytes
Physical Memory Array
        Location: System Board Or Motherboard
        Use: System Memory
        Error Correction Type: Single-bit ECC
        Maximum Capacity: 9 TB
        Error Information Handle: Not Provided
        Number Of Devices: 24

Handle 0x0031, DMI type 17, 40 bytes
Memory Device
        Array Handle: 0x002E
        Error Information Handle: Not Provided
        Total Width: 72 bits
        Data Width: 64 bits
        Size: 64 GB
        Form Factor: DIMM
        Set: None
        Locator: CPU0_DIMM_A1
        Bank Locator: NODE 1
        Type: DDR4
        Type Detail: Synchronous Registered (Buffered)
        Speed: 3200 MT/s
        Manufacturer: Samsung
        Serial Number: 4334ECDD
        Asset Tag:
        Part Number: M393A8G40BB4-CWE
        Rank: 2
        Configured Memory Speed: 2666 MT/s
        Minimum Voltage: 1.2 V
        Maximum Voltage: 1.2 V
        Configured Voltage: 1.2 V

....

Какие журналы нужно посмотреть?

dmidecode

Погоди, у тебя же Windows была на скрине с ошибкой контрольной суммы. Если проблемы проявляются не на одном компьютере, работающем с дампами, то основной подозреваемый — СХД, где они лежат. В общем, надо точно локализовать компьютер, где данные портятся.

А память проверить можно memtest86 или memtest86+. Я предпочитаю последний, но разница между ними несущественна.