QKD BackUpper というものを作りました
GitHub : qkotsudo : qkd-backupper
バックアップサーバに置いて設定して実行することで、
ssh 経由で rsync と mysqldump を実行し、
コンテンツデータやDBの日次バックアップをしてくれる子です。
もともと自分用なので、細かい処理が足りてなかったりするため、
これを使って何か起きても自己責任でお願いしますが、
まぁ大した量じゃないのでざっと読めば、はいはいなるほどね、てなると思う。
使い方
インストール
ただのスクリプト郡なので、git clone するだけです。
rsync 時の UID/GID を考えて root での実行を想定した作りですが、
別に一般ユーザでも普通に動きます。
以下、 root でホームディレクトリ上に設定する場合のガイダンスです。
[root@server ~] git clone https://github.com/qkotsudo/qkd-backupper.git
ssh キーペア作成
パスワードなしで ssh するため、専用のキーペアを作ります。
通信できればいいので、暗号強度や方式はなんでもOK。
例として普通にRSA鍵を作る場合はこんなかんじ。
実行時に怒られるので chmod も忘れずに。
[root@server ~] ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): ※キーペア名をFullPathで入力:例)/root/qkd-backupper/key/backupper
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/qkd-backupper/key/backupper.
Your public key has been saved in /root/qkd-backupper/key/backupper.pub.
The key fingerprint is:
SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXX root@server
The key's randomart image is:
+---[RSA 2048]----+
( 略 )
+----[SHA256]-----+
[root@server ~] chmod 600 qkd-backupper/key/backupper*
バックアップ対象に公開鍵を置く
/root/qkd-backupper/key/backupper.pub の中身を、
バックアップ対象の /root/.ssh/authorized_keys に追記します。
新規作成の場合は、キーペア生成時と同じく chmod を忘れずに。
プロファイルを書く
profile ディレクトリにいる sample.profile.php を複製&編集します。
具体的な設定内容は sample.profile.php 上にコメントで書いてあるのでここでは割愛。
実行する
[root@server ~] php /root/qkd-backupper/backup.php
基本的にはこれだけです。
あとは cron に仕込んだりすればOK。
-d をつけるとデバッグモードに突入し、
内部的に実行されるであろうコマンドを出力して終了します。
あと -p プロファイル名 をつけて実行すると、特定のプロファイルのみ処理可能です。
注意点
DBのスナップショットは YYYYMMDD.gz というファイル名で生まれます。
mysqldump の出力を gzip にパイプしつつ標準入力で受け取っているので。
その関係で、伸長すると YYYYMMDD という拡張子がないSQLファイルになります。
以下は読み物なので飛ばしてもOK
作った経緯
もともと、汎用的なバックアップツールは導入していなくて、
自前のスクリプトを cron 実行してたわけだが、
フリーランス化に伴い、バックアップ対象もクライアントごとの複数環境に分散してしまい、
ひとつのバックアップサーバで運用するわけにはいかない。
加えて、以前は自社フレームワークのディレクトリ構造を前提とした処理内容だったので、
いろんなフレームワーク環境を統合管理する必要も出てきた。
Bacula や Amanda も検討したものの、実際にインストール&設定してみると、
ちょっと俺の求める使いやすさとは違うんだよな〜という点があったので、
せっかくだしスクリプト書き直して公開するか、と思った次第。
バックアップに求めているもの
どんな環境でもだいたい動くこと
専用のエージェントをインストールしたり、特定のポートを開けたりするのが
客先のセキュリティポリシー的に難しい環境もあったりするので、
ssh 上ですべてまかないたいところ。
コンテンツ類は rsync で十分
扱っている案件の多くがそこまでシビアではないので、
日次で最新状態を保持すれば十分ということと、
稀にある「インスタンスが死んだ！」という状況でもすばやく復旧できるよう、
本番環境と同じディレクトリ構造で保管しておけば、
何かあったときも scp 一発でOK、というのが好ましい。
MySQL は dump を世代管理したい
不測の障害が発生しても1ミリ秒もダウンしたらダメ、というサービスは意外と少ない。
なぜなら、そんな要求レベルなら最初からレプリケーションなりクラスタ組むべきだし、
そうなると当然インフラのランニングコストがもりもり加算されていくわけで、
リアルな数字を見積ると多くのクライアントが「費用対効果優先で」という結論を下す。
そんな場合でもインスタンスが死んだのでデータ全部失いました、はさすがに・・・なので、
じゃあ日次でバックアップとっておきましょう、というのが肌感的にほとんどだったりする。
また、たまにあるのが、
エンドユーザサポートの上で「先月の状態と比較したい」といった要望が発生しても、
mysqldump の結果をただ残しておけば、別環境への展開もはやい。
んなことすんなや、という声が聞こえてきそうだが、
エンドユーザがマイページ上で月額課金を更新するようなサービスで、
しかもシステム自体は俺が作ったんじゃなく過去に知らない会社が作ったモノ、
さらにその中でデータを追いかけられるような仕込みが皆無、
みたいなケースが、受注案件を多く扱う現場では意外と存在してるので、
ある意味生きる知恵みたいなもんなんです。
ツールのアップデートや設定変更は楽したい
バックアップ対象が多くなってくると、その中で細かい設定が分散してると
何か変更したくなったときに大変だしよくわからんくなって漏れが起きやすかったりするし。
まぁモノグサなので完全に自分のための。
連続的にバックアップ処理したい
以前使っていた自前スクリプトでは、サーバではなく対象側にツールを設置していたので、
cron の実行時間をずらすことでサーバの負荷が上がりすぎないようにしていた。
が、これも数が増えてくると考えるのすら面倒になってくるので楽したい。
おわりに
繰り返しになるけど、
あくまで自分用として作ったものが基準なので、
なんも考えずに使うとセキュリティ的に穴を開けることになりかねないため、
このせいでなにかトラブっても一切責任負えませんので、あしからず。