Melkij

Судя по всему вы делали дамп без --clean и пытаетесь восстановить в уже не пустую базу.

Сейчас разработчики пишут портал

Вот у разработчиков и спрашивайте, какую СУБД они лучше знают. И админов своих спросите, какую СУБД те лучше знают. DBA у вас явно нет, иначе вопрос бы так не стоял.

Сам headhunter использует postgresql. Но там и своя команда админов классная, и вдобавок опытная команда DBA моих нынешних коллег, специализирующихся именно на postgresql.

Я достаточно хорошо знаю обе СУБД с точки зрения разработчика, но не умею админить mysql, так что моё мнение будет предвзятым.
Если делаете коммерческий проект - то используйте ту СУБД, которую лучше знает ваша команда. Если разработчики попрятались за своими ORM'ами и носу не заглядывают в базу - то без разницы, в таких условиях любая СУБД будет работать одинаково плохо. Если же хоть кто-то в команде понимает, что надо делать с базой - доверьте выбор ему и поинтересуйтесь о причинах выбора.

Найдите, где datadir базы. Скорей всего /var/lib/postgresql/(версия базы)/main, но могла была быть перемещена, так же может стоять несколько кластеров базы и разные версии базы - в дебианах и убунтах это делается легко.

Далее установить на новой системе postgresql идентичной major версии и не ниже minor версии что была там. Какая была major версия - смотрите файлик PG_VERSION в datadir. minor версию ставьте последнюю актуальную.
Так понимаю, старая система в принципе не работает? Т.е. старая база выключена? Выключите и новую (пока пустую) базу. Проверьте, если не уверены, обе базы должна быть выключена.
Переименовываете datadir на новом сервере (вообще, можно удалить, но можно и ошибиться консолью и дропнуть не то =) )
Копируете каталог базы: rsync -a /olddatadir /newdatadir
Копируете и правите если надо конфиги из /etc/postgresql/версия_базы
Если каталог pg_tblspc/ в datadir не пуст - скопируйте и симлинки из него и все данные по этим симлинкам в аналогичные места на новой машине.
Если pg_xlog/ является симлинком - его необходимо скопировать. Можно оставить симлинком, можно содержимое перекопировать.
Пробуете запустить базу на новом месте. Смотрите в логи. Если на старом месте база не была повреждена (и ничего нужного скопировать не забыли) - то она запустится.

Для перечислений можно использовать родной enum

melkij=> create type gender as enum('M','W');
CREATE TYPE
melkij=> create table foo (f gender);
CREATE TABLE
melkij=> insert into foo values('M');
INSERT 0 1
melkij=> insert into foo values('F');
ОШИБКА:  неверное значение для перечисления gender: "F"
СТРОКА 1: insert into foo values('F');
                                 ^
melkij=> insert into foo values('');
ОШИБКА:  неверное значение для перечисления gender: ""
СТРОКА 1: insert into foo values('');

И явный check не нужен и добавлять значения проще, особенно если поле используется не в одном месте базы только.

Как добавляли, так и будет храниться и читаться.

postgres=# create schema garage;
CREATE SCHEMA
postgres=# CREATE TABLE garage.users
(
car_id text COLLATE pg_catalog."default"
)
WITH (
OIDS = FALSE
)
TABLESPACE pg_default;
CREATE TABLE
postgres=# insert into garage.users values ('1'), ($$'1'$$), (null);
INSERT 0 3
postgres=# select car_id, car_id is null from garage.users ;
 car_id | ?column? 
--------+----------
 1      | f
 '1'    | f
        | t

Зависит от:
0) какой промежуток времени вам допустимо потерять при восстановлении
1) сколько места вы можете выделить для хранения бекапов
2) какой запас времени вы хотите сохранять для возможности восстановить данные когда-то из более далёкого прошлого

Может, на мыло тоже отправлять на всякий случай?

Как через почту пропихнуть даже мелкие бекапы в десяток гигабайт?
Или вы про совсем крошечные базы спрашиваете?

Шифровать или нет - зависит от требований к безопасности и оценке риска в случае disaster recovery не восстановить ключ шифрования.

Для хорошего point in time recovery - pg_basebackup + pg_receivexlog (archive_command только если уверены, что можете её сделать нормально). Или что-то, работающее поверх них.
Отдельный случай pitr с хранением в амазоне - см. вполне внятный wal-e
Если pitr не обязателен, то pg_dump делать. Да, лучше архивировать, сжимаются дампы весьма неплохо.

Например, политика бекапа из практики: ежедневный pg_dumpall, хранятся за 1 число каждого месяца на протяжении года плюс 8 дней предыдущих ежедневных.

Что-то ещё - регулярно пробовать восстановить и запустить базу из бекапа.

Помимо log_statement = 'all' можно выставить настройку log_min_duration_statement в 0 - она тоже может логировать все запросы.

Если запросов через базу проходит много не только от необходимой программы, то и log_statement и log_min_duration_statement возможно выставить только для пользователя, от имени котрого программа выполняет запросы. Например,

alter user melkij set log_min_duration_statement = 0;