MongoDBに格納されているデータのバックアップをsshで別のPCに転送する方法。

By | 2020年6月6日

はじめに

オンプレミスなサーバにFedoraをインストールし(なんか「ナウなヤングにバカうけでヘモグロビン」みたいな書き方ですが…)、さらにそこにGROWIをインストールして運用している件についてはちょっと前の記事で書きました。

GROWIのデータはMongoDB上のデータベースに格納されるため、半期に一度のFedoraのアップグレードの際には、緊急事態に備えてそのMongoDBのデータもバックアップを取得せねばなりません。

そのバックアップが一筋縄ではいかなかったので、メモっておくことにしました。

スポンサーリンク

MongoDBのバックアップ

以下、GROWIのデータはMongoDBにおいては”growi”という名前のデータベースに格納されていると仮定し、さらにそのデータベースのすべてのコレクションの取得を試みることにします。

ローカルにダンプする方法

MongoDB上のサーバをローカルにダンプするには、以下のコマンドを実行します。

$ mongodump −−port 27017 −−db growi −−out mongodump

 
すると、上記コマンドの実行時のカレントディレクトリに”mongodump”という名前のディレクトリが作成され、さらにその直下に”growi”という名前のディレクトリが作成され、その下にコレクションが格納されます。

なお、”−−out”オプションを指定しない場合には、コマンドの実行時のカレントディレクトリに”dump”という名前のディレクトリが作成され、さらにその直下に”growi”という名前のディレクトリが作成され、その下にコレクションが格納されます。

ここまでの方法でデータのダンプはできて、データの中身を確認することができるようになります。しかし、このダンプされたデータをバックアップに利用するためには別のPC等に転送する必要がありそうです。また、Fedoraのアップグレード時にはMongoDBだけではなく、MariaDBのデータベースもバックアップの取得の対象になりますので、ダンプファイルを1個にまとめることができるMariaDBと同様に、

  1. データのダンプを1個のファイルにまとめることができて、
  2. それが別のPC等に転送できる。

ことがMongoDBのバックアップ時にもできないか検討することにします。

ダンプしたデータをリモートに転送し、ついでにgzipで圧縮する方法

mongodumpのコマンドラインオプションには”−−archive”オプションがあって、このオプションに対してに出力先を指定しないことにより、ダンプした結果をまとめて、かつ標準出力に出力することができます。

また、”−−gzip”オプションを追加すると、ダンプした結果をgzipで圧縮できます。

これらと前節のmongodumpのコマンドをsshでリモートのPC等から実行すれば前節の最後に示した条件を満たすことができそうです。


スポンサーリンク

ひと通り役者が出そろったところで、リモートのPCより以下のコマンドを実行してみます(なお、ホスト名などの部分は一部編集しています)。

[panda@svo mongodump]$ ssh -l panda pandanote.info “mongodump −−port 27017 −−db growi −−archive −−gzip” > toranomonhills_20200606.mongodump.gz
Enter passphrase for key ‘/home/panda/.ssh/id_ed25519’:
2020-06-06T09:28:51.143+0900 writing growi.revisions to archive on stdout
(中略)
2020-06-06T09:28:51.274+0900 done dumping growi.tags (0 documents)
[panda@svo mongodump]$ ls -l toranomonhills_20200606.mongodump.gz
-rw-rw-r−−. 1 panda panda 24071 6月 6 09:31 toranomonhills_20200606.mongodump.gz

 
とりあえず、ダンプしたデータをリモートへの転送はできているようです。😀

取得したバックアップデータのリストアの確認

ここで、前節でダンプしたデータが復旧のために使用できるかどうかを確認します。

実は、ダンプしたデータの転送先のPCにもMongoDBがインストールされています(以下、本節では単に「MongoDBサーバ」と書きます。)ので、このMongoDBに対して以下の手順でリストアしてみます。

  1. mongoコマンド実行後、MongoDBサーバ上にgrowiテーブルがないことを確認します。
    [panda@svo mongodump]$ mongo
    > show dbs
    admin 0.000GB
    config 0.000GB
    local 0.000GB

     

  2. 以下のコマンドを実行し、前節で取得したバックアップデータをリストアします。mongorestoreのコマンドラインオプションはmongodumpとほぼ同様ではありますが、gzipで圧縮されたダンプファイルをリストアするためにはそのダンプファイルを”−−archive”オプションとともに指定せねばならないところに、軽めの曲者感を感じます。
    [panda@svo mongodump]$ mongorestore –gzip –archive=toranomonhills_20200606.mongodump.gz
    2020-06-06T09:50:08.229+0900 preparing collections to restore from
    (中略)
    2020-06-06T09:50:09.462+0900 274 document(s) restored successfully. 0 document(s) failed to restore.

     

  3. データベースがリストアされ、バックアップ元と同じデータが取得できることを確認します。”use growi”以降の出力結果については省略しますが、バックアップ元と記事数等を示すと思われる項目や、バックアップ元で格納したと思しきデータが取得できることが確認できればヨシ!!として良いと思います(※個人の意見です)。
    [panda@svo mongodump]$ mongo
    > show dbs
    admin 0.000GB
    config 0.000GB
    growi 0.001GB
    local 0.000GB
    > use growi
    > db.getCollection(‘pages’).stats()
    > db[‘revisions’].find()

     

スポンサーリンク

まとめ

バックアップを取得するだけでも作業としては面倒なところ、さらにそのデータが復旧できるかどうか確認するとなると、その面倒さ加減は想像を絶するものがあります(※個人の感想です)。

しかし、この作業を怠ってしまうと、「実際には使えないデータのバックアップを取得する」という無意味な作業のために時間を使っていると評価されてしまうことになります。

よって、復旧できるところまでしっかり作業をすることと、その作業ができるだけ面倒なものにならないようにデータを(更新する見込みがないから等の理由如何にかかわらず)外出しにせずに例外なくデータベースに格納する等してバックアップ及び復旧の作業の手間ができるだけかからないように設計しておくことが必要です。

この記事は以上です。