やらかした時は戒めも込めて記録してネタにして昇華するのが一番いいので記録です。
昨年あたりに引っ越しをする際にタスク管理のためにRedmineを利用していました。
引越しにあたり何をいつまでにするのか、何が終わっていて何をする必要があるのか。
そういったことをまとめていました。
引越しが終わってもうすぐ1年くらいということで、Redmineを建てておく必要もなくなってきたのでDBのバックアップ等をとってサーバーを退役させようと思いました。
いつかまた引越しをする際にリストアして確認できればいいだろくらいの感じです。
ちなみにRedmineはdocker composeで管理しており以下が設定の抜粋(一部改変済み)です。
db:
image: postgres:14.2
container_name: postgres_redmine
volumes:
- ./postgres/data:/var/lib/postgres/data
- ./postgres/initdb:/docker-entrypoint-initdb.d
restart: always
environment:
POSTGRES_ROOT_PASSWORD: xxxxx
POSTGRES_DATABASE: xxxxx
POSTGRES_USER: xxxxx
POSTGRES_PASSWORD: xxxxx
TZ: Asia/Tokyo
実はここに大きな罠があったんですね。
バックアップに伴いちょっと設定を変えて、compose down && upをしてバックアップを実行しローカル環境でリストアすると何かおかしいです。
今まで使っていたユーザーがいないし、DBの中身を見てもusersに自身のレコードがないしissuesテーブルも空です。
バックアップミスったかな〜と軽い気持ちで本番のWebUIにアクセスするとログインができなくなっている。
嫌な予感がしたので本番機のDBに入るとusersに自身のレコードがないし、issuesも空。。。
DB吹っ飛ばしたーーーーーーーーーーーーーー！！！！！！！！！！！！！！！！！！
ああああああああああああああああああああああ！！！！！！！！
直前まで動作していたことや、バックアップはごく普通の pg_dump を叩いただけということで残すところは compose down && up しかないんですが、ボリュームマウントしてるんですよね。
ってことでボリュームのディレクトリを見に行くと。。。
postgres# ls -lh data/ total 0
完全に宇宙猫ですね。
ここで先ほどのymlファイルを思い出しましょう。
volumes: - ./postgres/data:/var/lib/postgres/data - ./postgres/initdb:/docker-entrypoint-initdb.d
/var/lib/postgres/data ？？？
/var/lib/postgresql/data では？？？？
あああああああああああああ！！！！！！！（2回目）
ホストのマウントディレクトリ名に引きずられて、マウント先のディレクトリ名を間違えていました。
感想
一応RedmineのWebUIでできるCSVエクスポートは事前にしておいたので、チケットの全てが消えたわけではないんですが、コメントで結構残してたところもあってその辺りが消えてしまいました。
コンテナでデータボリュームマウントした時は、本当に期待したディレクトリがマウントされているか確認しようと思いました。 また、このレベルなら事前にマウントディレクトリごとバックアップを事前に取ってもよかったかも。
yamlでこれを防げると一番いいんだけど、なんかあるんですかね？ 久々に取り返しのつかないオペレーションをしてしまい、若干放心気味なので今日のところは肉でも買って焼いて回復に努めます。
