6

私が使用しているもののためにpostgresqlからのデータのバックアップ/復元に取り組んでいpg_dump.exeますpg_restore.exe。

バックアップファイルを復元するには、データベース内の実際のテーブルを削除する必要があります。これは、ダンプされたファイルで問題が発生した場合に「自殺の仕事」になる可能性があります。

ダンプされたファイルの整合性をチェックするには、最初のテストのように「7ztmydump.gz」を使用します。

しかし、このアーカイブは元のPGアーカイブであるため、PostgreSQLには、実際のテーブルを削除する前に取得できるこの「.gz」アーカイブをチェックするための手法が含まれていましたか？

もしそうなら、適切なチェックを行う方法は？

編集：これはダンプのための私の実際のコマンドです：

"C：\ Program Files（x86）\ PostgreSQL \ 9.1 \ bin \ pg_dump.exe" --host localhost --port 5432 --username "postgres" --no-password --verbose -F t --file "C ：\ Users \ User 1 \ Desktop \ mydatabase.gz "" mydatabase "

4

1 に答える 1

7

作成したPostgreSQLダンプの有効性と正確性を検証しようとしているようです。

主な誤解は、ダンプを作成したのと同じデータベースにダンプを復元する必要がないということです。同じクラスター上の別のデータベースに復元することも、余分なパラノイアの場合は別のクラスター（サーバー）上のデータベースに復元することもできます。ダンプがエラーなしで復元されたこと、およびデータが期待どおりであることを確認します。

さらにパラノイアが発生した場合は、PostgreSQLサーバーを停止し、データディレクトリ内のファイルをコピーします。そうすれば、ファイルレベルのバックアップもできます。PostgreSQLデータディレクトリのファイルレベルのコピーは、同じプラットフォーム上で同じオプションを使用して構築されたPostgreSQLの同じメジャー（8.1 / 8.2 / ...）バージョンでのみ読み取ることができることに注意してください-したがって、datadirが9.2.xからのものである場合Windows x64では、9.2.xがインストールされている別のWindowsx64ホストでのみ読み取ることができます。

元のデータベースが心配な場合は、おそらくバックアップがありません。これは重大な問題です。バックアップと復元に関するドキュメントの章に進んで緊急に読み、適切な自動バックアップスキームを導入する必要があります。バーマンを見てください。

質問編集後に更新：

-F t奇妙な選択です。プレーンSQLはダンプするか-F c、通常はより理にかなっています。

作成したファイルは.gz（gzip圧縮された）ファイルではありません。とにかく、それは.tarアーカイブであり、圧縮されていません。SQLファイルでいっぱいのディレクトリに抽出できます。

テストするには、を使用して、またはコマンドpg_restoreで作成された新しい空のデータベースに復元します。createdbCREATE DATABASE

于 2012-12-05T09:02:59.230 に答える