1C Сервер + PostgreSQL + Windows Server

Всем привет.

Изначально хочу сказать что у меня нет опыта эксплуатации PostgreSQL на линуксе, так что рекомендации (какой он хороший, быстрый, надежный и эта СУБД под него заточена) а так же любые другие ответы по линуксу мне пока не помогут. В ближайшем будущем я конечно планирую пробовать Ubuntu/Centos+PostgreSQL, но пока только Windows. Я откладываю перенос продакшина на линукс из-за того что абсолютно нет никакого опыта траблшутинга на этой ОС.

Работаю с этой связкой (PostgreSQL+Windows) чуть более 3 лет.
Есть сервера Win Server 2008 / Win Server 2012 и :
- 1С 8.2 и PostgreSQL 9.1.2-1.1C
- 1С 8.3.10 и PostgreSQL 9.4.2-1.1C
- 1С 8.3.12 и PostgreSQL 9.6.6-1.1С
- 1С 8.3.12 и PostgreSQL 9.6.7-1.1C
у разных клиентов, разные размеры баз, от 10ГБ до 100ГБ суть не в этом, по быстродействию пока нет проблем, все устраивает.

Хочу поделиться опытом и возможно получить помощи при решениях нескольких задач от более опытных ребят:)

! Аварийное выключение сервера, почти всегда приводит к тому что не запускается служба СУБД (ЭТО ПРОБЛЕМА!!! Которую я решал почти каждый раз по разному)

На связке 1С 8.3.10 и PostgreSQL 9.4.2-1.1C - никак службу не мог запустить, пока не запустил установщик СУБД той же версии и не переустановил, тем самым восстановив его файлики, список баз и настройки при этом сохранились, тогда просто повезло ( более детального описания нет, но факт остается фактом)

На этой же связке при похожем случае - помог сброс х-лога с помощью штатной утилиты pg_resetxlog
P.S. В 10 версии, убрали ее, взамен на pg_resetwal - пока не пользовался )

Далее про связку - 1С 8.3.12 и PostgreSQL 9.6.6-1.1С

У клиента, потух свет, УПС не выдержал из-за мертвой батарейки, аптайм сервера на тот момент был чуть больше 9 месяцев. После рестарта сервера служба СУБД не запускалась, ниже событья.
Записи в логах ОС (раздела приложения)
(событье) - Waiting for server startup...
(событье) - < 2019-01-22 09:08:38.011 MSK >LOG: redirecting log output to logging collector process
(событье) - < 2019-01-22 09:08:38.011 MSK >HINT: Future log output will appear in directory "pg_log".

Записи в логах СУБД (папка pg_log)
2019-01-22 09:08:38 EET LOG: database system was interrupted; last known up at 2019-01-22 09:06:00 EET
2019-01-22 09:08:38 EET FATAL: the database system is starting up
2019-01-22 09:08:38 EET LOG: could not receive data from client: An established connection was aborted by the software in your host machine.

2019-01-22 09:08:39 EET FATAL: the database system is starting up
2019-01-22 09:08:40 EET FATAL: the database system is starting up
2019-01-22 09:08:41 EET FATAL: the database system is starting up
...
И тд - много записей
потом
2019-01-22 09:10:17 EET FATAL: the database system is starting up
2019-01-22 09:10:20 EET LOG: database system was not properly shut down; automatic recovery in progress
2019-01-22 09:10:20 EET LOG: redo starts at 1E8/BF7FB740
2019-01-22 09:10:21 EET LOG: invalid record length at 1E8/BFA563C8: wanted 24, got 0
2019-01-22 09:10:21 EET LOG: redo done at 1E8/BFA563A0
2019-01-22 09:10:21 EET LOG: last completed transaction was at log time 2019-01-22 09:07:39.420616+02
2019-01-22 09:10:21 EET FATAL: the database system is starting up
2019-01-22 09:10:22 EET LOG: MultiXact member wraparound protections are now enabled
2019-01-22 09:10:22 EET LOG: database system is ready to accept connections
2019-01-22 09:10:22 EET LOG: autovacuum launcher started
2019-01-22 09:11:39 EET LOG: could not open file "postmaster.pid": No such file or directory
2019-01-22 09:11:39 EET LOG: performing immediate shutdown because data directory lock file is invalid
2019-01-22 09:11:39 EET LOG: received immediate shutdown request
2019-01-22 09:11:39 EET WARNING: terminating connection because of crash of another server process
2019-01-22 09:11:39 EET DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.

Мои действия
- Отключил службу СУБД
- Перезагрузил сервер с отключенной службой
- Удалил файлы "postmaster.pid" и "postmaster.opts" из папки Data
- Перезагрузил сервер, включил и запустил службу СУБД - и все заработало. (возможно мог поступить иначе, но мне - эти действия уже несколько раз помогли)
- После этого конечно выполнил обслуживание баз на уровне СУБД (вакуум / реиндекс) а так же протестировал базы из конфигуратора 1С, а потом выгрузил *.dt - и так делал каждый раз. Эти действия по моему мнению достаточны для того что сделать вывод - что базы не пострадали.

Но что меня до сих пор смущает, так это ситуация одного клиента.
У него Win Server 2008 + 1С 8.3.10 и PostgreSQL 9.6.7-1.1C. На сервере беда с материнской платой - и за последний месяц у него сервер уходил с синим экраном в аварийную перезагрузку более 30 раз, отваливаются диски, то системный, то диск с базами и тд (для наглядности привожу срин). При этом ни разу служба СУБД не падала, каждый раз восстанавливалась и работала как ни в чем не бывало, и у него настроены бэкапы средствами СУБД и средствами 1С, и все прекрасно выполняются, на днях без проблем развернул *.dt- шник на другом тестовом сервере. Я поражен и не могу понять с чем это связанно. Сейчас готовлю перенос на новый сервер и за одно хотел поделиться опытом.

У меня следующие вопросы. Личный опыт и конкретные рекомендации будут для меня очень полезными.
1) Ситуация такая: Cлужбу я так и не могу запустить и если на руках есть только папка DATA - могу ли я ее перенести и развернуть на другом сервере, подсунуть ее другой СУБД той же версии, а если версии отличаются ? Как правильно это сделать и достучатся до рабочих баз ?
2) Как правильно обновлять версии СУБД ? Пользовались pg_upgrade ?
3) Достаточны ли ежедневные регламентные задания Vacuum/Analize и Reindex - ? Или есть еще рекомендации ?
4) При аварийных выключения линукс сервера - там тоже служба СУБД PosgreSQL не поднимается самостоятельно ?