Здравствуйте ребята, начну с самого начала.
Сервер собран на Линуксе, около 25 пользователей на винде. Платформа 8.3.19.1522, Бухгалтерия предприятия, редакция 3.0 версия 3.0.122.97
Первоначальная задача была обновить релиз БП
Начал с релиза БП, сделал бекап (dt), и обновлять релиз, не вышло, просит свежею версию платформы.
Было решение восстановить бекап и отдать базу бухгалтеру, а вечером скачать платформу и обновить.
Во время восстановления бекапа, минут через 10 конфигуратор выдал ошибку -
Неверный формат файла для загрузки информационной базы
Ошибка формата потока
по причине:
Ошибка формата потока.
После конфигуратор перезапустился и база открылась просто пустая.
Еще раз пробовал накатить бекап, не помогло, решил взять старый бекап полу годичный, тоже не сел та же ошибка потока.
Самое первое что пришло в голову это почистить кэш у пользователя и сервера.
В сервере почистил по пути    
rm -rf /tmp/* и rm -rf /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/snccntx*
Не помогло, конфигуратор выдает ту же ошибку.
Вспомнил может диск на сервере переполнен, места еще 60 процентов, ошибка тоже не в этом.
Затем создал на клиентском компе файловую базу и накатил бекап туда, бекап сел и всю конфигурацию вижу, значит бекап не поврежден раз на файловой базе заработал, значит проблема на сервере.
На сервере решил переустановить платформу не обновляя релиза, т.к. бекап на старом релизе, тоже не помогло ошибка та же самая.
Может есть какие то догадки, помогите ребят пожалуйста.

Если есть живой dt, логично попробовать создать базу на сервере с нуля.
Ну и платформу обновить, может как раз та ошибка из-за которой 1С в ноябре армагеддон устраивала (вероятность правда небольшая) .

создай на сервере новую чистую пустую базу, загрузи dt в неё

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

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

>бекап сел и всю конфигурацию вижу

дт это не бэкап... никогда не рассчитывайте что из дт 100% восстановится база. Повезло сейчас - без гарантии что завтра снова повезёт

(4) да нормально там всё с dt, в последних релизах программисты в платформе намудрили, идет многопотоковая загрузка dt, она и глючит. Отключается параметрами запуска, сейчас не помню какими, есть в интернете

FirstLineSupport, подскажи пожалуйста какие параметры задать по запуске?

(7) /RestoreIB "<путь к файлу>.dt" -JobsCount 1

(6) даже 100500 лет назад 1С предупреждала что примерно 1% дт не позволит восстановить базу

(9) данный конкретный dt развернулся у ТС в файловую базу без ошибок, поэтому предполагается, что выгрузка здорова.

(0) правильно понимаю что на линуксе сервер 1С с постгре?

(11)+ фоновые задания же блокируешь?
в другую пустую новосозданную базу dt нормально восстаналивается?

Да все правильно 1с с PostgreSQL.
Фоновые задания блокирую через 1с администрирование сервера, галочка блокировать регламентные задания.
Новую базу ещё не создал, сегодня вечером буду делать.

(13) Если не срастеться, то...Выложи дт ев файлообменник, ссылку в почту из профиля. Попробую развернуть на локальном сервере на МССкуле на 22.1750.  Если получится, то могу "вернуть" дтшник с свежей платформы после ТИИ...

(0) dt это не бэкап, сколько можно повторять?
А, уже говорили? Ну еще раз не помешает.

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

(16) >все возможные варианты

ещё вариант - перенести из файловой базы в чистую серверную только данные, без конфигурации

Принял буду пробовать.

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

Здравствуйте ребят, тему можно закрывать, все спасибо большое за поддержку и помощь!!!
Так что было сделано:
1. Создал чистую базу на сервере, не помогло ошибку писал туже самую.
2. Обновил платформу, загружал dt и в старую базу и в новую созданную базу, не помогло ошибка та же.
3. Грузил dt с параметрами одно потоковой загрузки, в параметрах запуска прописываем /RestoreIB "<путь к файлу>.dt" -JobsCount 1, не помогло.
Дело в том что, лет 5 назад, собирал сервер не я, мое дело было закупить конф., ключи, скопировать с файловой базы у клиента dt и передать человеку,
он все подготовил, загрузил и настроил, мое дело поставить и до настроить у клиента.
Затем этот человек слился и дальнейшее обслуживание осталось на мне, не оставив паролей, где все хранится и т.д.
Хотел собрать сервер заново уже со своими паролями и настройками и перекинуть базу с ключами на новый сервер, но времени оставалось мало.
К моему счастью человек объявился и выдал пароли.
И все стало очень просто:
1. Почитав 2 дня статей о Linux, PostgreSQL, pg_dump и pg_restore
2. Нашел где хранятся бекапы (спасибо человеку что он создал планировщик)
3. Все восстановил
Теперь я всегда делаю бекапы через pg_dump — выгрузить базу данных PostgreSQL в виде скрипта или в архивном формате, и всем советую так делать.

(20) Спасибо, что описал решение.

Но имей в виду, что pg_dump это примерный аналог dt, настоящим бэкапом не считается.