EC2 - Как правильно создать резервную копию данных PostgreSQL?

Вот настройка: 1 маленький экземпляр EC2 Amazon Linux (с поддержкой EBS) с 3 дополнительными томами. Это и веб-сервер, и сервер базы данных. Один том для кода, один для каталога данных PostgreSQL (8.4) и один том для хранения файлов WAL из PostgreSQL.

(1) Том с файлами WAL также будет иметь базовую резервную копию каталога данных, которая копируется после выполнения pg_start_backup (). Затем он будет хранить непрерывный архивный вывод из PostgreSQL (файлы WAL). Чтобы сделать снимок этого тома, есть ли смысл выдавать синхронизацию и останавливать файловую систему (используя xfs_freeze, если это XFS, или dmsetup, если это EXT4)? Или я могу просто сделать живой снимок? Файлы WAL будут отправляться со скоростью один в минуту. Возможно ли, что моментальный снимок может быть инициирован во время копирования одного файла WAL, что приведет к повреждению данных?

(2) Том, содержащий действующий каталог данных PostgreSQL, также будет регулярно архивироваться (ежедневно). Прежде чем сделать снимок этого тома, я выпускаю pg_dump, и полученный файл SQL сохраняется в каталоге данных. Есть ли смысл принимать меры предосторожности для обеспечения согласованности фактических данных базы данных? Правильно ли предположить, что при создании живого снимка будут правильно (а) создавать резервные копии конфигурационных файлов (postgresql.conf, pg_hba.conf, pg_ident.conf) и (б) создавать резервные копии файла дампа SQL. Резервное копирование этих двух вещей, файла дампа sql и файлов конфигурации, было бы основным моментом создания снимка этого тома. БД не очень большая, поэтому я не против того факта, что файлы данных будут раздувать этот снимок. И в этом случае я могу просто сделать живой снимок - правильно?

(2a) Было бы лучше сохранить каталог данных на корневом томе и иметь сценарий резервного копирования, который копирует файл дампа sql, а также файлы конфигурации на другой том и снимает этот том после завершения копирования?

(3) Что касается тома с кодом, опять же, есть ли смысл синхронизировать и заморозить файловую систему? Или можно просто сделать живой снимок? Эти данные должны быть довольно «статичными».

(4) Это надежная схема резервного копирования? Резервное копирование корневого тома происходит не регулярно, так как я просто сохраню образ компьютера после его настройки и настройки.

Спасибо

Смотрите прекрасное руководство . Если мой совет каким-либо образом противоречит его советам, это правильно.

1. Синхронизация не является плохой идеей, если ваш инструмент копирования fsync () не записывает каждый WAL-файл и каталог, в котором находится, перед копированием следующего. Неполный последний WAL-файл не имеет большого значения; в худшем случае вы просто удалите его. Pg, как правило, захлебывается неполным WAL - хотя контрольной суммы не делается, так что вы можетебыть действительно неудачником и попытаться применить данные мусора, которые по чистой случайности выглядят как настоящие записи WAL. На вашем месте я бы синхронизировал том перед моментальным снимком, чтобы убедиться, что неписанные грязные буферы в ОЗУ попали в образ файловой системы на диске. Замораживание поможет избежать беспорядочных, но не фатальных частично написанных WAL, так что это не страшная идея, но и не жизненно важная. Важно иметь неповрежденную временную шкалу вплоть до момента восстановления. Лично я записываю свои WAL во временное имя файла и переименовываю их в их окончательное имя только после полного копирования; если вы делаете это, вам не нужно замораживаться.

2. Звучит правильно. Снимок в реальном времени - это то же самое, что тест на вставку в реальной системе с сквозным кэшированием. Ваша база данных должна нормально восстанавливаться при восстановлении из живого снимка, так же, как и после plug-pull. Я бы порекомендовал вам автоматизировать тестирование восстановлений по снимкам. (Примечание. Тест восстановления моментального снимка не является полной заменой тесту пулл-пул, поскольку он не учитывает возможное кэширование диска, raid-контроллера и т. Д.). Не только файлы конфигурации и дамп, но и сама база данных должны быть в порядке после вашего снимка. Попробуйте синхронизировать том перед моментальным снимком, чтобы убедиться, что все данные дампа и т. Д. Действительно попали на диск.
   
   2а. Может сэкономить место на диске. Маленькая разница в противном случае. Вы сможете хранить снимки намного дольше, не используя при этом всю живую базу данных.

3. Зачем даже снимать ваш объем кода? Обычная копия на уровне файлов вполне может подойти. Конечно, живой снимок должен быть.

4. Это не надежная схема резервного копирования. Сбой в одной критической области: тестирование и проверка не выполняются. Вы должны всегда проверять свои резервные копии на регулярной основе, чтобы убедиться, что вы действительно можете восстановить их.

   Лично я рекомендую вам использовать WAL-доставку или отправлять дампы базы данных на другой хост , предпочтительно не на Amazon EC2 или, по крайней мере, в другом регионе. Этот хост должен выполнять автоматические тесты восстановления, отправлять вам отчеты о результатах, а также должен проверяться вручную.

   Хотя ваши снимки (содержащие дампы) будут на S3 и будут там в безопасности, это не значит, что они будут доступны, когда они вам срочно понадобятся. Претензии Amazon на долговечность обнадеживают, но ваши данные все еще могут быть в безопасности и полностью недоступны для вас во время нерегулярного простоя службы S3.