Здравствуйте, уважаемые специалисты 1С!
В данный момент перевожу небольшое предприятие с IM DB2, ибо купили новый сервер. На Microsoft SQL Server денег нет, ставлю им PostgreSQL. Ранее не особо работал с ней. Обычно в батнике делаю vacuum и reindex, затем резервирование через pg_dump. А по выходным ТиИ средствами 1С. Задался вопросом - есть ли встроенный шедулер в PostgreSQL? Еще один вопрос - в какой последовательности и какой регламент для баз вы обычно делаете - как часто ТиИ и резервные копии? Заранее благодарю за ответы.

(0) батником бэкап делаю.

http://victor-k-development.blogspot.ru/2010/01/postgresql-batch.html

(2) спасибо, подобный батник у меня есть.
вопрос в порядке выполняемых регл. заданий.

(3)https://wiki.postgresql.org/wiki/Automated_Backup_on_Windows
если коротко то виневый шедулер пользуют.на никсовой не помню как

на никсах крон

(4) спс, оказывается есть pgAgent, запускает либо sql скрипты, либо те же батники. однако, иногда страдает утечкой памяти.

апну свою же ветку. пока балуюсь на собственном домашнем серваке. там у меня стоит 64-битный PostgreSQL Pro 9.4.10 с накаченными патчами от 1С.
ткните носом пожалуйста, что я делаю не так. а именно backup средствами PostgreSQL:

CLS
ECHO OFF
CHCP 1251
SET PGBIN=C:\Program Files\PostgresPro 1C\9.4\bin\
SET PGHOST=localhost
SET PGPORT=5432
SET PGUSER=postgres
SET PGPASSWORD=copacabana
SET PGDATABASE=%1

SET STAGINGDIRECTORY=C:\Temp\
SET BACKUPDIRECTORY=E:\Backup1C\

SET DATETIME=%DATE:~6,4%-%DATE:~3,2%-%DATE:~0,2% %TIME:~0,2%-%TIME:~3,2%-%TIME:~6,2%
SET DUMPFILE=%PGDATABASE%_%DATETIME%.backup
SET LOGFILE=%PGDATABASE%_%DATETIME%.log

IF '%PGDATABASE%'=='' (ECHO The database name is not specified & GOTO End)

IF NOT EXIST %STAGINGDIRECTORY% MD %STAGINGDIRECTORY%
IF NOT EXIST %BACKUPDIRECTORY% MD %BACKUPDIRECTORY%

CD /d %STAGINGDIRECTORY%

SET DUMPPATH="%STAGINGDIRECTORY%%DUMPFILE%"
SET LOGPATH="%STAGINGDIRECTORY%%LOGFILE%"
SET FINALDUMPPATH="%BACKUPDIRECTORY%%DUMPFILE%"
SET FINALLOGPATH="%BACKUPDIRECTORY%%LOGFILE%"

CALL "%PGBIN%\pg_dump.exe" --blobs --if-exists --clean --create --format=custom --verbose --compress=9 --file=%DUMPPATH% 2>%LOGPATH%

IF NOT %ERRORLEVEL%==0 GOTO Error
GOTO Successfull

:Error
DEL %DUMPPATH%
ECHO %DATETIME%: Errors when creating a database backup %DUMPFILE%. See the report %LOGFILE%. >> %LOGPATH%
GOTO End

:Successfull
ECHO %DATETIME%: The backup %DUMPFILE% has been successfully created >> %LOGPATH%
ECHO F| XCOPY %DUMPPATH% %FINALDUMPPATH% /I /H /R /Y
ECHO F| XCOPY %LOGPATH% %FINALLOGPATH% /I /H /R /Y
DEL %DUMPPATH%
DEL %LOGPATH%
GOTO End

:End

Далее хочу восстановить это дело в новую базу, которую предварительно создал в PgAdmin III

Кодировка: UTF8
Шаблон: template0
Табличное пространство: pg_default
Сопоставление: Russian Russia. 1251
Тип символа: Russian Russia. 1251
Макс. число подключений -1

Почему-то база 1С тоже видится как template, это настораживает.
При попытке восстановления из дампа, выдается куча ошибок.

Выдаются ошибки следующего типа

C:\Program Files (x86)\pgAdmin III\1.22\pg_restore.exe --host localhost --port 5432 --username "postgres" --dbname "test" --no-password  --section pre-data --section data --section post-data --clean --verbose "E:\Backup1C\ut_11_2016-11-18  0-07-08.backup"
pg_restore: connecting to database for restore
pg_restore: [archiver (db)] Error while INITIALIZING:
pg_restore: [archiver (db)] could not execute query: РћРЁР?БКА:  РЅРµСЂР°СЃРїРѕР·РЅР°РЅРЅС‹Р№ параметр конфигурации: "row_security"
    Command was: SET row_security = off;

pg_restore: dropping INDEX byusosname
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 23861; 1259 46184 INDEX byusosname postgres
pg_restore: [archiver (db)] could not execute query: РћРЁР?БКА:  РёРЅРґРµРєСЃ "byusosname" РЅРµ существует
    Command was: DROP INDEX public.byusosname;

pg_restore: dropping INDEX byusname
pg_restore: [archiver (db)] Error from TOC entry 23860; 1259 46181 INDEX byusname postgres
pg_restore: [archiver (db)] could not execute query: РћРЁР?БКА:  РёРЅРґРµРєСЃ "byusname" РЅРµ существует
    Command was: DROP INDEX public.byusname;

pg_restore: dropping INDEX byusdescr
pg_restore: [archiver (db)] Error from TOC entry 23859; 1259 46183 INDEX byusdescr postgres
pg_restore: [archiver (db)] could not execute query: РћРЁР?БКА:  РёРЅРґРµРєСЃ "byusdescr" РЅРµ существует
    Command was: DROP INDEX public.byusdescr;

Что я делаю не так?

Может быть что-то с кодировкой, но я кроме

>> Сопоставление: Russian Russia. 1251
>> Тип символа: Russian Russia. 1251

везде (при установке PostgrePro и в 1С) выставил UTF-8

Да и ровно такие же и в том же количестве ошибки вываливались на PostgreSQL с сайта releases.1c.ru

базы нужно создавать средствами 1с, а потом туда заливать бэкап

ошибка, может быть будет исправлена

Думаю, что через pg_restore надо восстанавливать, нафиг PgAdmin. Напишу батник, попробую.

(14) Не, ну можно еще в dt выгружать, но фирма 1С так не рекомендует делать, насколько я знаю из ИТС.

Дамп

pg_dump -Fc -U postgres base > base.dump



Восстановление

pg_restore -U postgres -d newbase base.dump

(17) спасибо. pgAdmin выполняет ту же команду по сути, а результат отличный от того что выполняется в cmd.exe. странно.

с бэкапами разобрался. ставлю на сервер предприятия PostgresPro и служба запускается. но PgAdmin не видит ее и 1С кстати тоже. запуск идет от имени "Сетевая служба"

порты?

5432 открыт

C:\Users\Администратор>netstat -a

Активные подключения

  Имя    Локальный адрес        Внешний адрес          Состояние
  TCP    0.0.0.0:135            Fileserver:0           LISTENING
  TCP    0.0.0.0:445            Fileserver:0           LISTENING
  TCP    0.0.0.0:1540           Fileserver:0           LISTENING
  TCP    0.0.0.0:1541           Fileserver:0           LISTENING
  TCP    0.0.0.0:1560           Fileserver:0           LISTENING
  TCP    0.0.0.0:1688           Fileserver:0           LISTENING
  TCP    0.0.0.0:3389           Fileserver:0           LISTENING
  TCP    0.0.0.0:5357           Fileserver:0           LISTENING
  TCP    0.0.0.0:5432           Fileserver:0           LISTENING

при попытке запустить вручную

pg_ctl -D "C:\Program Files\PostgreSQL\8.3\Data" -l logfile start
пишет что служба уже запущена, но попробуем запустить ее, потом
server started
а потом отказано в доступе.
это я такой упоротый, или у всех так?

(33) Права не только по портам, но и по разрешениям у юзеров. Смотреть конфиг надо.

Например тут почитать: http://pgcookbook.ru/article/no_pg_hba_conf_entry_for_host.html

или тут: http://catalog.mista.ru/public/88792/

(24), (25) спасибо, добрый человек.

в общем, странное дело - перезагрузился, pgAdmin нашел базы. загружаю базы из dt

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

server_addr=tcp://fileserver:1541 descr=192.168.1.176:1541:10060(0x0000274C): Попытка установить соединение была безуспешной, т.к. от
другого компьютера за требуемое время не получен нужный отклик, или было разорвано уже установленное соединение из-за неверного
отклика уже подключенного компьютера.;
line=1043 file=src\DataExchangeTcpClientlmpl.cpp
Выполняется ожидание возможности запуска.    ф
При появлении возможности, запуск будет выполнен автоматически
Нажмите "Выполнить запуск" для немедленной попытки запуска.
Нажмите "Отмена" для отказа от запуска.

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

это он 192.168.1.176 сервер 1С не может найти вроде как

внешний комп в той же сетке то?

(30) да, это сервер, который стоит через комнату от меня, он в той же сетке. мой локальный комп видно с сервера и наоборот.

настройте днс ннормально, чтобы со всех компов по имени можно было обратится на любой комп (через nslookup, а не через "служба доступа файлов и принтеров мелкософт")

(32) а в этом ли дело, если указать на старом сервере базу, и с локального компьютера туда заходит?
в pg_hba.conf вход с паролем разрешен во все базы с любого компьютера

(33) в этом

(34) все оказалось проще - админ не открыл порты в брэндмауэре. чего-то я затупил, потом проверил через telnet fileserver 1541 и 1560. они закрытые были. в общем, сейчас все взлетело. спасибо за помощь.