Postgresデータベースを使用するDjangoアプリケーションがあります。データが失われないようにするため、および実動サーバーからデータをコピーするために、dbをバックアップおよび復元できる必要がありますテスト中に開発サーバーに。
これを行うには、いくつかの異なる方法があるようです。
データベースと直接対話するだけです。したがって、Postgresの場合、pg_dumpall
およびpsql
。
Djangoに付属のsqlclear
/sqlall
コマンドを使用します。
Djangoに付属のdumpdata
/loaddata
コマンドを使用します。そのため、バックアップするデータベースから新しいフィクスチャを作成し、復元するデータベースにロードします。
Django Django-dbbackup のようなプラグインを使用します。
私はこれらのさまざまなテクニックの長所/短所を本当に理解していません。
頭に浮かぶ:オプション1はデータベース固有であり、オプション3は初期データの設定により適しているようです。しかし、オプション4がオプション2に比べてどのような利点があるかはまだわかりません。
通常のバックアップでは、おそらく最も効率的であるため、PostgreSQLのネイティブツールを使用してオプション1を選択します。
オプション2は主にテーブルの作成と初期データのロードに関係しているため、バックアップには適していません。
オプション3はバックアップに使用でき、データがSQL以外の形式、つまりDjangoが理解できるJSONでダンプされるため、別のデータベースプラットフォームに移行する必要がある場合に特に役立ちます。
オプション4プラグインはdb独自のバックアップツールを使用しているように見えますが(オプション1)、Amazon S3またはDropboxのクラウドストレージにバックアップをプッシュするのに役立つ
オプション1〜3の問題は、メディアファイル( FileField
を介してアップロードされたもの)が含まれないバックアップで。メディアファイルを含むディレクトリを個別にバックアップすることができます。ただし、DjangoはFileField
によって参照されなくなったファイルを削除しないため、必然的にバックアップ内のファイルは不要になります。そこ。
そのため、オプション#4を使用します。特に、 Django-archive をお勧めします*。その機能の一部は次のとおりです。
すべての重要なモデルの内容をダンプします(デフォルトではContentType
、Permission
、およびSession
はmanage.py migrate
によって取り込まれるため除外されます)、追加のモデルを選択できます除外します。
FileField
およびImageField
フィールドによって参照されるメディアファイルが含まれます。 onlyデータベース内の行によって参照されるファイルが含まれていることに注意してください。削除された行によって残されたファイルは無視されます。
データベースのバックアップとメディアファイルの両方を含む単一のアーカイブを作成します。
アーカイブを保存する場所、ファイル名の形式、およびアーカイブタイプ(gz
およびbz2
)をカスタマイズするためのオプションを提供します。
インストールは、Django_archive
をINSTALLED_APPS
に追加し、必要に応じてsettings.py
でオプションを設定するだけです。インストールしたら、次のコマンドを実行して、データベース全体(メディアファイルを含む)のアーカイブをすぐに作成できます。
./manage.py archive
*免責事項:私はパッケージの著者です