Что тебя смущает? Ты упоминаешь во всех случаях одно и то же имя базы

Бэкап - testSRC, восстановление - testDST. ИМХО разные. Или я где-то ошибся?

#!/bin/bash

PORT=5432
USERNAME='admin'
SERVERNAME='localhost'
ARCHIVEDIR='/Backup'
SUFFIX=''
DBNAME=''
DUMPGZ=''

if [[ $1 != '' ]]
then
    DBNAME=$1
else
    echo "Point dbname as first parametr"
    exit
fi

if [[ $2 != '' ]]
then
    DUMPGZ=$2
else
    echo "Point dump.gz file as second parametr"
    exit
fi

echo $DBNAME

if psql -U $USERNAME -h $SERVERNAME -p $PORT -lqt | cut -d \| -f 1 | grep -qw $DBNAME
then
    echo "Database with this name exists on this cluster"
    exit
else
    echo -n "Create database? (Y/n) "

    read answer
    case "$answer" in
        Y) psql -U $USERNAME -h $SERVERNAME -p $PORT -c 'create database '$DBNAME -d postgres
            ;;
        *) exit 0
            ;;
    esac
fi


echo -n "Restore database? (Y/n) "

read answer
case "$answer" in
    Y)
        if file $DUMPGZ | grep -qw "PostgreSQL custom database dump"
        #/Backup/bis_kamin55_psql/bis_kamin55_psql_daily_6_08.dump.gz: PostgreSQL custom database dump - v1.12-0
        then
            pg_restore -h $SERVERNAME -U $USERNAME -p $PORT -d $DBNAME -w -Fc $DUMPGZ
        else
            gunzip < $DUMPGZ | psql -h $SERVERNAME -U $USERNAME -p $PORT -d $DBNAME
        fi
        #pg_restore -h localhost -p 5433 -U dbadmin -w -Fc -d  bis_kamin55_psql_testrecovery /Backup/bis_kamin55_psql/bis_kamin55_psql_daily_6_08.dump.gz
        #if [[ $? -ne 0 ]]
        #then
        #    echo $?
        #fi
        ;;
    *) exit 0
        ;;
esac

В общем то же самое, почему удаляет непонятно

Значит, где-то ошибся и написал src вместо dst.

PostgreSQL 9.2.1

девять два ОДИН. ОДИН, Карл.

https://www.postgresql.org/support/versioning/

Current minor: 9.2.24

Final Release: November 9, 2017

Supported: No

Никого не смущает?

--clean
Clean (drop) database objects before recreating them. (This might generate some harmless error messages, if any objects were not present in the destination database.)

https://makandracards.com/makandra/62120-heads-up-pg_restore-clean-keeps-existing-tables

Heads up: pg_restore --clean keeps existing tables
When restoring a PostgreSQL dump using pg_restore, you usually add the --clean flag to remove any existing data from tables.

Note that this only removes data from tables that are part of the dump and will not remove any extra tables. You need to do that yourself. 
[https://makandracards.com/makandra/62111-how-to-drop-all-tables-in-postgresql]

–clean удаляет базу только если указан –create

А у меня тут вопрос нарисовался.
Что такое testsrc.bkp (кроме того, что это файл с «бекапом»)?
Что из себя представляет этот файл?
И каким образом база восстанавливается?

https://www.postgresql.org/docs/9.3/app-pgdump.html

Точно?

If you run pg_dump with the –clean option then the generated SQL dump would contain drop statements for all dumped objects (note that when using the custom format and pg_restore you don’t need to decide on this when dumping, but when restoring).

However if the target database contains tables (or other objects) that were not contained in the source, those would not be dropped.

Using pg_dump –clean (or pg_restore –clean) is pretty much the same behaviour as with Oracle’s impdp using the TABLE_EXISTS_ACTION=REPLACE. That too wouldn’t drop (replace) tables that were not part of the source.

To avoid having tables in the target that were not contained in the source, people very often simply drop the entire database before importing the dump. But this is (when using the –clean option) not really required.

Да, точно. –clean очищает объекты в базе к которой подключился pg_restore, а при –create — удаляет саму базу с именем из дампа, к какой базе он подключается при –create уже не имеет значения.

Да, точно. –clean очищает объекты в базе

ЛОР это нечто. ))) Приходит лопух который не хочет читать документацию и решить свою тухлую проблему и вопрошает о помощи. Подтягиваются в тему знатоки которые начинают за него читать доки и выяснять проблему. Лопух сидит, жрет попкорн и ждет решения.

Ну вот скажите, вам время своего не жалко? Может сразу лопуха в /dev/null?

Анек:

Стоят два еврея на Дерибасовской и жарко о чем-то спорят. Подходит третий и 15 минут слушает спор. В итоге он восклицает: «Ой! Не морочьте мне голову!» – и уходит.

Решено! Всех откликнувшихся благодарю!

Убрал «–clean» все заработало как нужно.

PS. Про попкорн прям по доброму зацепило. Все верно сказано.

PPS. Про «–clean» я конечно читал, но я полагал, что с этой опцией pg_restore удаляет объекты внутри базы, но никак не саму базу. Безусловно нужно было прежде проверить, потом задавать вопросы на форумах.

Спасибо большое за решение. Буду больше знать теперь.

PPS. Про «–clean» я конечно читал, но я полагал, что с этой опцией pg_restore удаляет объекты внутри базы, но никак не саму базу.

Именно так, например:

$ pg_dump -Fc -f src.dump src

$ pg_restore -l src.dump 
;
; Archive created at Fri Jan 17 17:59:50 2020
;     dbname: src
...

$ pg_restore -v --dbname dst --clean src.dump
pg_restore: подключение к базе данных для восстановления
pg_restore: удаляется COMMENT EXTENSION plpgsql
pg_restore: удаляется EXTENSION plpgsql
...

Что бы удалялась именно база целиком к --clean нужно добавить ключ --create:

$ pg_restore -v --dbname dst --clean --create src.dump
pg_restore: подключение к базе данных для восстановления
pg_restore: удаляется DATABASE src
pg_restore: создаётся DATABASE src
pg_restore: подключение к новой базе данных "src"
pg_restore: подключение к базе "src" с именем пользователя "postgres"
pg_restore: создаётся SCHEMA public
pg_restore: создаётся COMMENT SCHEMA public
pg_restore: создаётся EXTENSION plpgsql
...

Что интересно, тестировал на версии 9.4.2

pg_restore --dbname testdst --clean testsrc.bkp

базу testsrc не удаляет, а вот та же команда на 9.2.1 - удаляет.

Более того, как следует из

pg_restore: удаляется DATABASE src

pg_restore: создаётся DATABASE src

база должна удалиться и создаться, а в моем случае удалялась вовсе.

Судя по PostgreSQL 9.2.1-eter8ubuntu — у Вас не оригинальный postgres, а кем-то изменённый (что значит eter? 1С?), думаю что ни pg_dump ни pg_restore тут не при чём, а виноваты авторы этих изменений которые видимо сделали такое поведение в своём форке 9.2.1-eter8ubuntu. Оригинальный postgres с postgresql.org так себя не ведёт.