Re: The trap when using pg_dumpall

Поиск
Список
Период
Сортировка
От Rui DeSousa
Тема Re: The trap when using pg_dumpall
Дата
Msg-id 46651FE6-5D07-44CF-B7D2-3D807EED198F@crazybean.net
обсуждение исходный текст
Ответ на Re: The trap when using pg_dumpall  ("Dean Gibson (DB Administrator)" <postgresql@mailpen.com>)
Список pgsql-admin
> On Jul 4, 2021, at 2:04 AM, Dean Gibson (DB Administrator) <postgresql@mailpen.com> wrote:
>
> Well, I never store the

Well, as long as we’re stating I never’s — let me state mine; I never consider a logical backup (pg_dump) a proper
backup. They have their use cases and are a very useful tool; however, I would considered a production database without
aphysical backup as not being backed up.  Logical backups don’t allow for PITR recovery and are very slow in
comparison. I only use logical backups for migrations, etc.  - more as a tool rather than a backup strategy. 

A good practice would be to have a separate instance that can instantiate a point in time recovery.  This would allow
forthe reviewing/exporting required data needed to resolve a given issue. 


В списке pgsql-admin по дате отправления:

Предыдущее
От: pgdba pgdba
Дата:
Сообщение: Archive cleanup
Следующее
От: Avadhut Narayan Joshi
Дата:
Сообщение: RE: Substitute for table variable and data migration approach