Как обеспечить отказоустойчивость БД Postgres?
как правильно обеспечить надежность и безотказность ее работы?
Использовать адекватное железо и не мешать базе работать шаловливыми ручками.доступен 24 часа 7 дней в неделю.бекап 
Объясните, пожалуйста, как это по вашему мнению между собой связано?
Бекапы необходимы, но как они связаны с высокой доступностью?в случае проблем с доступностью, перезапускать/запускать саму СУБД.
Простой вопрос: зачем?
Если база сложилась и даже не смогла подняться самостоятельно - значит проблема капительная и разбираться надо детально. Рестартом по кругу вы можете скорее сделать совсем плохо, чем что-либо починить.
При том обычно проблемы начинаются от того что разработчики выкатили новую версию приложения и та начинает делать что-то странное. Например, забыли сделать индекс на 50гб табличку и засунули запрос с поиском по ней на главную сайта. Рестартом базы это, разумеется, не исправляется. А делает только больнее.
Многолетней давности pg_postmaster_start_time() впечатлять не буду - мы периодически ставим минорные апдейты на свои базы. И вам тоже весьма рекомендую обновиться до 10.7 или лучше уже на следующих выходных сразу до 10.8.
А так, если не трогать - то годами будет работать. Мониторинг и алерты от него, разумеется, нужны. Какая-то автоматика при наступлении алерта - обычно приносит куда больше головной боли, чем помогает.какие операции, запросы или их комбинации нежелательны для БД и могут привести к проблемам. 
Большая часть инцидентов с недоступностью сервиса с точки зрения приложения  - про уровни блокировок. Кто-нибудь попробует сделать create index вместо create index concurrently и привет ожидание блокировки на всю запись в таблицу. Большинство форм alter table сюда же, но они и чтение заблокируют.
Никак.
Можно только приблизится.
Master-slave, к примеру, поможет не потерять данные PostgreSQL, но это не означает, что система корректно переключится на полноценную работу со slave при выходе из строя master. Принимать решение о переключении придется вручную.