Я запускаю свой сервер БД в облаке Amazon, и у меня есть файлы базы данных на отдельном томе EBS. Когда дело доходит до операций резервного копирования / восстановления, я обнаружил, что бесконечно проще просто сделать резервную копию на уровне файловой системы, чем дамп sql, потому что я могу создавать резервные копии и восстанавливать из них почти мгновенно.
Есть ли какие-либо проблемы, которые я могу упустить, если буду использовать только резервные копии на уровне файловой системы?
Запуск PostgreSQL 9.1 (обновление до 9.3 позже в этом году) в Ubuntu 12.04
Есть ли какие-либо проблемы, которые я могу упустить, если буду использовать только резервные копии на уровне файловой системы?
Да, но не те, о которых вы думаете. До тех пор, пока вы делаете безопасное копирование на уровне файловой системы, риск будет заключаться в использовании физических резервных копий.
При написании этого я заметил, что главу о резервном копировании на уровне файловой системы необходимо обновить, чтобы указать пользователям на pg_basebackup и pg_start_backup(). Хотя технически они являются частью потоковой репликации и PITR, эти инструменты являются всего лишь способами создания безопасных, согласованных копий на уровне файловой системы, и на них следует ссылаться в этой части документации.
За документация по резервному копированию на уровне файловой системы PostgreSQL и создание базовой резервной копии Делать копию на уровне файловой системы вполне безопасно, если вы следуете приведенным там правилам, а именно выполняете одно из следующих действий:
Остановка сервера перед резервным копированием и оставление его выключенным до завершения резервного копирования;
С помощью pg_basebackup;
С помощью pg_start_backup() и pg_stop_backup() и скопируйте файлы, созданные pg_stop_backup(); или
Использование моментального снимка атомарной файловой системы и копирование из моментального снимка, и в этом случае в него ничего нельзя будет записывать, потому что это моментальный снимок.
Вы также можете использовать pg_basebackup -X stream, что я предпочитаю. Он использует протокол репликации для копирования на уровне файловой системы, заботясь о pg_start_backup() и т. д. для вас.
Основным преимуществом физических резервных копий является то, что их можно использовать в качестве основы для Восстановление на момент времени.
Случай со снимками безопасен, потому что он похож на крах. Запись не ведется, и состояние базы данных фиксируется в определенный момент времени. Журналы упреждающей записи содержат все данные зафиксированных транзакций, поэтому все, что еще не сброшено в кучу, воспроизводится из WAL во время восстановления при первом запуске БД. Это похоже на запуск после аварии. Вам нужно только pg_start_backup() и друзья, если вы копируете каталог действующей базы данных, в который все еще ведется запись, пока вы его копируете; снимок позволяет этого избежать.
Обратите внимание, что полагаться на снимки безопасно, только если снимок действительно атомарный, то есть фиксирует состояние файловой системы в один момент времени. Это также безопасно только в том случае, если задействован ровно один том / файловая система - вы не можете использовать два снимка двух отдельных файловых систем для создания резервной копии, они не будут сделаны в один и тот же момент времени. Если вы используете табличные пространства, резервные копии моментальных снимков небезопасны по этой причине, но pg_basebackup или pg_start_backup(), rsync, pg_stop_backup() все еще безопасно.
Это означает, что если файловая система вашей базы данных представляет собой (скажем) четыре тома EBS в md рейдовый массив, или у вас есть один для pg_xlog и один для остальной части базы данных, вы не можете использовать моментальные снимки EBS для создания согласованной резервной копии. Если все - один том EBS, снимок EBS безопасен.
Вы также можете остановить PostgreSQL перед запуском резервного копирования и запустить его после. Если вы один из счастливчиков, которые могут позволить себе время простоя резервного копирования, что ж, это круто. Лично я все равно предпочитаю горячее резервное копирование.
Настоящая проблема, о которой следует беспокоиться, заключается в том, что когда вы делаете физическую резервную копию, вы копируете структуру базы данных непроверенной и непроверенной. Если есть необнаруженное повреждение, у вас вполне могут быть резервные копии, которые намного менее полезны, чем вы думали. Лично я бы тоже использовал логические дампы.
Полезным компромиссом может быть запуск резервной копии на уровне файловой системы после того, как вы сделали копию, а затем выполните pg_dump из резервной копии на уровне файловой системы. Это обеспечивает его читаемость и дает вам логическую копию. Если ваш логический дамп не работает, ваша автоматизация должна отправлять вам электронное письмо и кричать о помощи, потому что это предполагает, что ваша физическая копия также может быть повреждена.
Кстати, я написал кучу о том, как избежать проблем с потерей / повреждением данных в моем старом блоге некоторое время назад - см. Как избежать повреждения базы данных PostgreSQL.
Вы можете сделать резервную копию файловой системы, которая будет надежной, если вы полностью выключите Postgres, ЗАТЕМ сделайте резервную копию, пока Postgres выключен. Когда резервное копирование будет завершено, запустите Postgres.
Если Postgres работает во время резервного копирования, все ставки отключены.
Лучше всего сделать это в дополнение к правильной резервной копии базы данных "в Postgres".