Прошу совета и помощи
сервер с Ubuntu x32 на нем стоит сервер 1С тоже x32 и postgresql сервер, тоже x32
Пользователи работают в базе круглосуточно. Раньше я делал архивные копии следующим образом:
1. делал копию базы с помощью pg_dump
2. восстанавливал дамп с помощью pg_restore в другую базу на сервере
3. заходил в конфигуратор новой базы и делал выгрузку в *.dt файл.
сейчас база выросла до 13+ Гб и при восстановлении базы в новую из бекапа выдает что не хватает памяти. Излазил форумы и вычитал, что во всем виновата платформа x32 и что с x64 таких проблем нет. Но переустановить сервер возможности нет, да и и доплачивать за переход ключа сервера 1С с x32 на x64 - долго и начальству трудно объяснить лишние траты.
наткнулся в сети на любопытный способ делать бекап не выгоняя пользователей из системы: http://catalog.mista.ru/public/200829/,  но как-то страшновато пробовать такое. Может у кого есть еще идеи?

зачем делать дт?

что бы можно было восстановить базу в случае чего

(2) а дампа pg разве недостаточно чтобы восстановить базу?

(0) есть еще одно ограничение - размер внутренней таблицы в базе. Если (если не ошибаюсь) размер на таблицу вырастет over 2Гб, то в *.dt уже не выгрузишь.

Юзай только pg. Можешь настроить онлайн репликацию.

https://wiki.postgresql.org/wiki/Streaming_Replication

(2) а вообще - глупое оправдание.
Юзай дампы pg.

pg дампы как-раз не восстанавливаются. в этом и проблема. Ругается на недостаток памяти. Поэтому дампы я могу делать сколько угодно, только от них нет толка, если я восстановить их не могу

(7) сколько памяти на сервере?

(8) оперативки 8Гб, на жестком 80% места свободно

(9) Раздел swap какой?

(10) Swap 8Gb
вот текст ошибки при восстановлении дампа

postgres@s1C:~$ pg_restore -d 1C_test /home/suser/backup/CM
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 33447; 0 26975807 TABLE DATA config postgres
pg_restore: [archiver (db)] COPY failed: ERROR:  out of memory
ПОДРОБНО:  Failed on request of size 1073741823.
КОНТЕКСТ:  COPY config, line 24422
WARNING: errors ignored on restore: 1

(11) пробовал выгрузку делать в текстовом виде?

(12) сейчас попробую

(11) Может у тебя прав просто нету?

(14) не похоже. раньше все работало. Увеличился только размер базы. в интернете пишут что на x64 такой проблемы не наблюдается

может поставить на соседнюю машину x64 версию postgres и проверить?

Посмотри базовый курс по PostgreSQL от 16-18 декабря 2015.
https://www.youtube.com/playlist?list=PLaFqU3KCWw6KzGwUubZm-9-vKsi6vh5qC

dt вообще не рекомендуется для бекапов.  С какой-то 8.3 получше стало, но все же..

(17) спасибо. Гляну

(16) уже думал. Но если даже восстановит нормально, что мне это даст? просмотреть или в случае чего накатить обратно я все равно не смогу на рабочий сервер

(20) это тебе даст понимание того, что пора бы уже переходить на х64

(15) А у  тебя эта ошибка сразу возникает или постгре лопатит некоторое время и потом отваливается?

(20) оставишь базу на этом сервере, перенастрришь на него сервер 1С и будет счастье

(22) после получаса восстановления вываливается эта ошибка

при восстановлении ругается на таблицу "config" (TABLE DATA config) может это таблица битая? кто знает что это за таблица?

VACUUM и REINDEX делал?

Я чет не понял, замена 32-х разрядного postgres на 64-разрядный денег и ключей не просит. 1C можно и 32-разрядным оставить. Или сам линукс 32-разрядный?

Сорри, вижу и сервер 32-х.  А 8 гиг оперативки как скушало?

(28) в линуксе за PAE доплачивать не надо

тут надо конфиг постгри покурить

(29) знаю, а postgres об этом знает?

Если память не изменяет у меня на 32гб база крутилась в PostgreSQL 8.4 64bit и 1С Сервер 32Bit достаточно долго. Вроде не было таких проблем. А вот реиндексацию частенько приходилось делать.

VACUUM и REINDEX пробовал, про 8 гигов сожранной оперативки я не говорил. просто на сервере установлено 8 гигов, но занято максимум бывает 3-4 гига.

сейчас буду пробовать выгрузку в dt и загрузку из него. и исправление базы с помощью chdbfl.exe

(33) примерно так и должно быть, PAE это для ядра операционки, но не для процессов.
А исправление базы самим 1С пробовал?

(33) Посмотрел, в таблице Config похоже лежит конфигурация, в бинарном виде. Было похожее однажды, когда вылетало при выгрузке конфигурации. Причина - злоупотребление динамическими обновлениями.

(34) пробовал - ошибок нет
(35) уууу... Динамическое обновление - это про мою контору :) тут бывает по 5 обновлений за час.

такс. из dt'шника база загрузилась номарльно. значит дело именно в кривой таблице config. буду на выходных играться с восстановлением базы