タグ: 保守

各種サービスのアプリデータのバックアップについての基本方針。

1.対象データ

データ１）DBデータ

MariaDB、PostgreSQL、SQLServerなどのデータ。

データ２）アプリデータファイル

サービス固有のデータファイル。細かいファイルがどんどん増えていく。

2.バックアップ先

異なるタイミングで２拠点にバックアップする。

転送先１）LAN内サーバー

同一センター内でプライベートネットワーク内の別サーバー

転送先２）別拠点サーバー

別事業者の別地域のサーバー。例えば、実サーバーがConoHaの東京リージョンの場合、転送先２としては、ConoHa以外の事業者（ニフクラやさくらインターネット等）で、東京以外（大阪とか）のサーバーにする。

3.バックアップのタイミング

１）１時間毎

　DBデータ、アプリデータファイルをバックアップフォルダにバックアップして、転送先１）LAN内サーバーに転送する。

２）日毎

　DBデータ、アプリデータファイルをバックアップフォルダにバックアップして、転送先２）別拠点サーバーに転送する。。

4.バックアップ方法

データ１）DBデータ

データベースアプリのバックアップ方法によりバックアップファイルを作成し、必要あればgzip等で圧縮する。

今のところ、フルバックアップでも問題ないため、すべてフルバックアップとする。

データ２）アプリデータファイル

rsyncコマンドにて、バックアップフォルダに差分コピーする。過去ファイルが残っていても問題ないなら、deleteオプションはつけない。

5.転送方法

データ１）DBデータは、scpによるファイル転送。

データ２）アプリデータファイルについては、rsync over sshで転送。

※プライベートネットワーク内であれば、rsyncプロトコルでもいいかもしれないが、ここもssh経由とする。

6.バックアップのローテート

データ１）DBデータ

転送先１）LAN内サーバーについては、バックアップファイル、またはディレクトリに時間（date +%H）を付けることで、２４セット（２４時間）でローテートする。

転送先２）別拠点サーバーについては、日にち（date +%d)を付けることで、翌月の同日にローテートする。

データ２）アプリデータファイル

１セットとしてローテートしない。

7.その他

１）ホストベース認証

バックアップ先のサーバーに、バックアップ専用のユーザーを作成し、そのユーザーに対してホストベース認証を許可する。

suコマンドによるrootユーザーへのスイッチは禁止しておく。

２）タスクの優先度

バックアップ元（アプリ運用中のサーバー）のバックアップ処理については、以下コマンドで実行することで、優先度を下げること。

ionice -c 2 -n 7 nice -n 19 コマンド

バックアップ先のサーバーについては、バックアップ専用のため、優先度は気にしない。

 

実際の設定は、次の記事。

バックアップ設定

サーバーの老朽化あるいはVPS業者の乗換えなどにより、サーバーを移行する場合の手順についてのメモ。

１．移行手順

DBサーバー移行時だけ計画停止（メンテナンス）するという条件で、 以下の手順で移行する。

１）新サーバーの環境構築

現行サーバーからプログラム、データ等をコピーして、新サーバーで環境を構築する。

この時に、現行DBサーバーからデータをコピーして新DBサーバーに登録するまでの時間を覚えておくこと。この時間が、４）でのサービス停止時間（メンテナンス時間）を決めるのに必要となる。

テスト端末でhostsに以下の設定を追加することで、新サーバーの動作確認を行う。

(テスト端末のhosts設定)
 222.222.222.222  XXService.com　#新WebサーバーのIPアドレスを設定

Windows10でのhosts設定方法は以下。

Windows10でhosts設定

新Webサーバーと新DBサーバーで、問題なく動作することを確認する。OS等のバージョンを上げている場合は、その影響がないか念入りに動作確認を行う。

２）新Webサーバー＋現行DBの動作確認

新DBサーバーは一旦停止して、新Webサーバーから現行DBサーバーを見るようにする。現行DBサーバー側で、新Webサーバーからの接続を許可 （DB設定とファイアウォール）する 。

１）と同様に、新Webサーバーにアクセスして動作確認を行う。

３）DNSを変更してWebサーバー並行稼働（現行DB）

DNS設定を現行サーバーから新サーバーに変更することで、ユーザーが徐々に新Webサーバーにアクセスするようになる。

通常であれば１週間ほどでDNSキャッシュは全て更新されて、現行Webサーバーへの ユーザーからのアクセスは完全になくなる。この時間を短くしたい場合は、事前にDNS設定でTTL値を小さくしておく。

現行Webサーバーは、ユーザからのアクセスがなくなった時点でお役御免となる。

４）DBサーバーを移行し、新サーバーにて運用

事前に、計画停止についてユーザーへの告知（調整）をする。

計画停止時にDBサーバーの切り替え作業を行い、旧サーバーを停止する。

計画停止時の作業内容としては、ざっくり以下。

1. メンテナンス中として、DBアクセスを止める
2. DBバックアップを取得し、新DBサーバーに投入する
3. 旧サーバーを停止し、DBアクセス先を新DBサーバーに変更
4. サービス再開

２．レプリケーション機能を使う場合

データ量が多くてDB移行時の停止時間が長くなりすぎる場合あるいは長い停止時間が取れない場合には、レプリケーション機能を使う。

２）と３）の間で、新DBをスレーブに設定することで、

３）Webサーバー並行稼働＋現行DBサーバー(マスタ）＋新DBサーバー（スレーブ）といった運用にする。

４）DBサーバー切り替えは、以下作業となり、僅かな停止時間で実施できる。

• 新DBサーバーを、スレーブからマスタに昇格し
• DB接続先を新DBサーバーに切り替える