Я создал сценарий для выполнения физического резервного копирования базы данных Postgresql 9.0.8, следуя рецепту «Автономное горячее физическое резервное копирование базы данных» в Поваренной книге администрирования PostgreSQL 9 (Riggs / Krosing), но я адаптировал его для Windows Server 2008 R2 .
Для шага №4 рецепта, который использует rsync для копирования всех файлов данных (за исключением каталога pg_xlog), я использую robocopy.exe (поскольку rsync - это утилита * nix, а я использую Windows). Проблема в том, что часто один из файлов не может быть скопирован, и в результате появляется сообщение «Доступ запрещен». Копирование файла вручную не удается с сообщением «Доступ запрещен» длинный после сбоя сценария резервного копирования - так что это не какая-то периодически возникающая проблема, которую можно повторить. Файл можно скопировать только после перезапуска процесса PostgreSQL. Это всегда другой файл. Последней ночью это был% PGDATADIR% \ 5432 \ base \ 24609 \ 38122.
Я хотел бы услышать, испытали ли вы это и что вы сделали, чтобы это исправить. Я считаю:
Хорошо, обо всем по порядку - отложите поваренную книгу. Вместо этого иди читай раздел руководства Postgres о резервном копировании. Прочтите всю главу - это не так уж и долго.
(Вы, вероятно, заметите некоторое сходство между этой книгой и книгой - большинство книг Postgres - это просто усовершенствованные версии руководства, но вы всегда должны работать с руководством в качестве основного справочника.).
Вся терминология, которую я буду использовать ниже, взята из руководства (так что, если вы думали, что можете пропустить задание для чтения, вы не сможете - если вы это сделаете, вы, вероятно, будете ужасно сбиты с толку).
Теперь о вашей реальной проблеме - решение Unix часто не переносится напрямую в Windows, и это один из тех случаев: система A * nix с радостью захватит файл, которым управляют - Windows выдает ошибку, которую вы видите.
Как вы с этим справитесь, зависит от того, какое резервное копирование вы делаете.
Если вы делаете "резервное копирование на уровне файловой системы" ты должен выключите сервер. Точка, конец обсуждения, других вариантов нет. База данных должна быть полностью отключена, чтобы этот тип резервного копирования был надежным (а если получаемая вами резервная копия ненадежна, в чем смысл?).
Если вы делаете базовая резервная копия как часть настройки Моментальное восстановление & log-shipping у вас есть два варианта:
Затем вы действуете в соответствии с остальной документацией для восстановления на определенный момент времени / доставки журналов, создавая подчиненный сервер.
Если вы хотите скопировать сервер базы данных на диск, просто остановите подчиненное устройство, создайте резервную копию и перезапустите его - мир продолжает включать ваш главный сервер, а подчиненный сервер наверстает упущенное при перезапуске.
Вы также можете использовать базовую резервную копию плюс свернутые журналы транзакций, которые вы обычно отправляете ведомому устройству в качестве надежной резервной копии базы данных. Казалось бы, это самое близкое к тому, что вы пытаетесь достичь в своем вопросе, но я бы порекомендовал ведомую резервную копию, которую я описал вместо этого - больше преимуществ (у вас есть горячий резерв) и меньше работы для главного сервера (нет дополнительная контрольная точка для отката журнала транзакций резервной копии).
Если ничего из вышеперечисленного вам не нравится, вы в значительной степени застряли в использовании SQL-дампы.
Есть и недостатки: Postgres должен блокировать каждую таблицу по мере ее сброса (что означает, что запись в вашу базу данных будет заблокирована), а дампы SQL работают медленнее, чем другие варианты.
Если ваша база данных имеет реальный размер, я бы не советовал этот метод.