データベースのバックアップ手順の見直し

今回は、前日実施したデータベースのバックアップに関することを書きたいと思います。

ディスク使用量の警告

イートスマートでは管理しているすべてのサーバをZabbixで監視しています。 ある日、イートスマートのデータベースとして利用しているサーバの、ディスク使用量に関する警告が届きました。

www.eatsmart.jp

以下のような内容です。

Problem started at 05:23:59 on 2020.05.28
Problem name: Free disk space is less than 10% on volume /
Host: database

この時間帯は、PostgreSQLのCOPYコマンドを利用して日毎バックアップを実施しています。 このバックアップはスナップショットとして活用しており、必要に応じて過去のデータを参照したり、そこから書き戻すために利用しています。

日毎バックアップの手順

この日毎バックアップは、以下の手順で実施しています。

1. COPYコマンドでバックアップ対象のテーブルからファイルを作成
2. tarコマンドで1で作成したファイルをtar.gzへ固めアーカイブを作成
3. 1で作成したファイルを削除

この手順の問題点として、1と2の間で一時的にファイルとアーカイブが存在するため、ディスクの使用量が多くなることが挙げられます。 このため、Zabbixからディスクの使用量の警告が届くようになりました。

対処方法

対処方法としていくつか検討しましたが、今回は手順を見直すことでディスクの使用量を減らすことにしました。 バックアップの手順を以下のように変更しました。

1. COPYコマンドでバックアップ対象のテーブルのうち1つのテーブルからファイルを作成
2. 1で作成したファイルをgzipへ圧縮
3. すべてのバックアップ対象のテーブルの処理が終わったら4へ、終わっていなければ1へ戻る
4. tarコマンドで2で作成したファイルをtarへ固めアーカイブを作成
5. 1で作成したファイルを削除

ディスクの使用量を減らすため、ファイルを都度gzipで圧縮しています。 こうすることで、ディスクの使用量を1/4程度に減らすことが出来ました。 注意することとして、アーカイブの形式がtar.gzからtarに変わったことで、テーブルの内容を参照する手順が変わったことがあります。

まとめ

これでZabbiから警告が届かなくなりました。 今回はバックアップの手順の見直しで対処しましたが、バックアップに関して議論をするきっかけになりました。

• そもそもいまのバックアップ内容で問題ないのか？（スキーマのバックアップが必要ではないか？）
• COPYコマンドではなく、pg_backupのほうが良いのではないか？
• バックアップを実施するサーバとしてマスタが適切か？（スレーブで良いのではないか？）

などです。 以前から仕組み化されており、問題がある訳ではなく内容に疑問を持つこともありませんでした。 今回の作業を通して、システム部メンバーの考え方を聞く良いきっかけになりました。