Djangoのデータベーステーブルのバックアップ&リストア方法のメモ

はじめに

こんにちは。しょうです。
今まで、RHEL8+docker-compose+Django+PostgreSQL環境に
おけるWebサービス構築学習を通じて、以下のメモを残しています。

1個目のメモは
AWS EC2インスタンス-RHEL8上に開発環境の基礎となる
dockerとdocker-composeのインストール手順について書いています

2個目のメモは
1個目のメモで基礎を作った上に、DjangoとPostgreSQL環境のセットアップ
手順について書いています。

3個目となる今回のメモは
Djangoで使用するデータベーステーブルのバックアップとリストアの
手順について書いていこうと思います。

メモ

今回の環境でDjangoでWebサービス開発の勉強をしている時、
コンテナを削除するとデータベーステーブルに保存しているデータも
併せて削除されてしまう事象を確認しました。
（admin管理画面に入るためのユーザも消えてしましました。）
DjangoにWebブラウザでアクセスすると以下のエラーが確認出来ました。

dockerコンテナ上でしかデータを管理していない状態で
コンテナを削除してしまうと、消えてしまうのは当たり前なのですが、
開発途中なのでコンテナを稼働させたり削除させた理を頻繁に行う。
そのたびにデータが消えてしまう。
また、毎回毎回消えてしまうのは実運用の事を考えても
普通によろしくない(笑)

dockerベースでバックアップ的なことが出来ればよかったのですが、
Djangoの技術でバックアップリストアを簡単に行うことが出来ることが
分かったので、とりあえずこの手順で暫く開発を行っていこうと思う。

試験用に以下のデータを用意した。

Djangoのコンテナにアクセスし、次のコマンドを実行することで全アプリの
全データベーステーブルをjson形式で出力することが出来る。
>以降は任意のファイル名でOK
これでバックアップが取れるんだから便利だよな～

root@ddf1ad55ee2a:/code# python manage.py dumpdata > 20210607dump.json  
root@ddf1ad55ee2a:/code# ls  
20210607dump.json  blogpost     docker-compose.yml  requirements.txt  
Dockerfile         blogproject  manage.py

先程作成したjsonファイルがホストOSにも存在していることを確認する。

[root@ip-10-0-1-4 test_env]# ls  
20210607dump.json  blogproject         Dockerfile  requirements.txt  
blogpost           docker-compose.yml  manage.py

試験の為にdockerコンテナを削除する。

[root@ip-10-0-1-4 test_env]# docker stop $(docker ps) 
[root@ip-10-0-1-4 test_env]# docker rm $(docker ps -a) 
[root@ip-10-0-1-4 test_env]# docker ps -a  
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

そして再度docker-composeを実行してコンテナを稼働させる。
WebブラウザでDjangoにアクセスし、データが消えていることが分かる。

この状態でDjangoコンテナにアクセス。
manage.py migrateを実行し、リストアする用のデータベーステーブルを
用意する。
※この辺りはPostgreSQLのリストアのイメージに近いイメージ。

root@32c6107d7138:/code# python manage.py migrate  
Operations to perform:  
 Apply all migrations: admin, auth, blogpost, contenttypes, sessions  
Running migrations:  
 Applying contenttypes.0001_initial... OK  
 Applying auth.0001_initial... OK  
 Applying admin.0001_initial... OK  
 Applying admin.0002_logentry_remove_auto_add... OK  
 Applying admin.0003_logentry_add_action_flag_choices... OK  
 Applying contenttypes.0002_remove_content_type_name... OK  
 Applying auth.0002_alter_permission_name_max_length... OK  
 Applying auth.0003_alter_user_email_max_length... OK  
 Applying auth.0004_alter_user_username_opts... OK  
 Applying auth.0005_alter_user_last_login_null... OK  
 Applying auth.0006_require_contenttypes_0002... OK  
 Applying auth.0007_alter_validators_add_error_messages... OK  
 Applying auth.0008_alter_user_username_max_length... OK  
 Applying auth.0009_alter_user_last_name_max_length... OK  
 Applying auth.0010_alter_group_name_max_length... OK  
 Applying auth.0011_update_proxy_permissions... OK  
 Applying blogpost.0001_initial... OK  
 Applying blogpost.0002_blogmodel... OK  
 Applying sessions.0001_initial... OK  

その後同コンテナ内でmanage.py loaddataコマンドを実行してデータベーステーブルにデータをリストアする

root@32c6107d7138:/code# python manage.py loaddata 20210607dump.json   
Installed 44 object(s) from 1 fixture(s)  
root@32c6107d7138:/code#

admin管理画面にログイン出来、かつデータが復活していることを
確認する。少しずつではあるがベースの環境に依存しにくい
開発環境が出来ている気がする・・・！