Простите меня за невежественный вопрос, но я вижу, что postgres имеет свои журналы WAL, и есть разговоры об использовании снимков файловой системы, а WAL со снимками может быть или не может быть достаточным резервным копированием / восстановлением ... Я традиционно не администратор базы данных / admin (я разработчик), но достигла точки, в которой я хочу улучшить поддержку этих потребностей.
Вопрос: Можно ли настроить Postgres в системе размером 10 ГБ или 100 ГБ для не использовать специальное программное обеспечение для резервного копирования, а вместо этого просто использовать традиционное программное обеспечение для резервного копирования файловой системы (снимки файловой системы?) и есть ли разумный метод восстановления с использованием этого метода? (если размер имеет значение, хотелось бы знать)
Вариант использования 1: избегать особого подхода к резервному копированию при использовании Postgres и просто использовать обычную файловую систему. Без простоев или менее 5 секунд.
Вариант использования 2: при использовании с гибридным ECM, таким как Alfresco, где содержимое файловой системы (изображения) и метаданные (база данных) всегда должны копироваться и восстанавливаться одновременно. Без простоев или менее 5 секунд.
Пожалуйста, уточните, о чем я могу не спрашивать, например о хороших / плохих идеях или о вещах, на которые следует обращать внимание :-)
(обратите внимание, это для локальной установки в среде Linux, если для стратегии требуется определенная файловая система, это нормально).
TIA!
-D
Вопрос: Можно ли настроить Postgres в системе размером 10 или 100 ГБ, чтобы не использовать специальное программное обеспечение для резервного копирования, а вместо этого просто использовать традиционное программное обеспечение для резервного копирования файловой системы (снимки файловой системы?) И иметь разумный метод восстановления с использованием этого метода?
Да, если снимки файловой системы атомарные. Это очень важно. Вы должны иметь атомный снимок, вы не можете просто скопировать каталог данных напрямую. Обычный метод - сделать снимок с помощью SAN, диспетчера логических томов, файловой системы с возможностью создания снимков и т. Д. И смонтировать его по другому пути, а затем создать резервную копию. Итак, вы используете сценарий до и после резервного копирования.
Здесь «атомарный» используется в компьютерном значении неделимого, единственного момента времени, когда все находится либо до, либо после этого момента. В случае моментального снимка это означает момент времени, состояние хранилища в этот конкретный момент.
Насколько я понимаю, служба теневого копирования томов Microsoft (для Windows) является атомарной только на уровне файлов, поэтому вы не можете использовать системы резервного копирования, которые полагаются на нее для обеспечения согласованности.
Если вы на самом деле не используете моментальный снимок файловой системы, вы просто копируете данные в файловой системе в реальном времени, вы все равно можете это сделать, но вам придется предпринять дополнительные шаги. Согласно документации вы можете сообщить PostgreSQL, что выполняется резервное копирование, и он перейдет в режим без перезаписи, что сделает резервное копирование безопасным во время его работы. Однако для восстановления такой резервной копии вам потребуются файлы, которые записываются после вызова сценария пост-резервного копирования pg_stop_backup() бежит. Самый простой способ убедиться, что у вас есть эти файлы, - это убедиться, что WAL архивирование включен; в противном случае вам понадобится несколько дополнительных обработчиков сценариев в вашей системе резервного копирования, чтобы добавить их в резервную копию.
Вариант использования 1: избегать особого подхода к резервному копированию при использовании Postgres и просто использовать обычную файловую систему. Без простоев или менее 5 секунд.
Для этого просто используйте pg_dump или pg_basebackup. Не требуют простоя и просты.
Любая приличная система резервного копирования поддерживает перехватчики до и после резервного копирования, которые упрощают эту задачу.
Вариант использования 1: избегать особого подхода к резервному копированию при использовании Postgres и просто использовать обычную файловую систему. Без простоев или менее 5 секунд.
Для этого вам понадобятся атомарные снимки, и вам нужно будет убедиться, что изображения находятся в том же снимке, что и PostgreSQL.
В противном случае вы рискуете несогласованностью, когда файловая система и БД не совсем совпадают.