バックアップについて

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

1.対象データ

データ1)DBデータ

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

データ2)アプリデータファイル

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

2.バックアップ先

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

転送先1)LAN内サーバー

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

転送先2)別拠点サーバー

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

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

1)1時間毎

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

2)日毎

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

4.バックアップ方法

データ1)DBデータ

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

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

データ2)アプリデータファイル

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

5.転送方法

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

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

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

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

データ1)DBデータ

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

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

データ2)アプリデータファイル

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

7.その他

1)ホストベース認証

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

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

2)タスクの優先度

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

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

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

 

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

CertbotによるSSL証明書の設定

CentOS 8.2 にLet’s encrypt でSSL証明書を設定した時のメモ。

検索すると、古いやり方が出てくる。最新のやり方は、Certbotの本家サイトに行くのがいい。

https://certbot.eff.org/lets-encrypt/centosrhel8-apache

OSとWebサーバーを選んで、後は指示通りにやるだけ。

一応、CentOS 8.2 で、Apache 2.4 でやった時の手順は以下(2020年9月3日時点)。

1.SSLサーバーの設定

mod_sslは既に入れてあり、SSLは有効化されている。

ただし、SSL証明書を取得したいドメインについては、バーチャルホストとして定義することが必要。

デフォルトの/etc/httpd/conf/httpd.confではなく、/etc/httpd/conf.d以下に、バーチャルホストを定義する。ここに定義した、XXXX.com.confに対して、後の手順4で、Certbotが、XXXX.com-le-ssl.confを作成して、XXXX.com.confについても、httpsリダイレクトに修正してくれる。

2.EPELライブラリの有効化

https://fedoraproject.org/wiki/EPEL#Quickstart

これも既にやってあったけど、一応、以下をやる。

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

後、一応、こちらも入れておいた方がいいい。

sudo dnf config-manager --set-enabled PowerTools

3.Certbotのインストール

sudo dnf install certbot python3-certbot-apache

4.証明書のインストール

HTTP用にバーチャルホストが定義してあれば、自動で証明書を取得して、定義ファイルも作ってくれる。

sudo certbot --apache

SSL化したいバーチャルホストを選択すれば、後は自動でやってくれる。ドメイン定義がちゃんとあっていることが前提なので、新サーバーに移行する場合の、新サーバー側で事前のSSL証明書取得についてはできない。

5.自動更新の設定

crontabに直接、定期的に更新するのを設定する。

echo "0 0,12 * * * root python3 -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew -q" | sudo tee -a /etc/crontab > /dev/null

6.確認

https://www.ssllabs.com/ssltest/

yum update失敗で、再起動できず

ConoHa VPSのCentOS7.6サーバーで、yumアップデートを掛けたが、その後サーバーが無反応となってしまった。管理パネルから再起動かけたところ、kernel panicで起動できなくなった。VPSのため、レスキューモードでどう起動するかわからず、探したら以下ページを発見した。

https://qiita.com/kiyocy24/items/5897d58bdd04f2e2a65c

ただし、上記ページでは再起動となっているが、再起動の場合はタイミングが取りづらく何回も失敗した。以下の手順が良いと思う。

  1. コントロールパネルから一旦、強制終了する
  2. コントルールパネルから、起動する
  3. コントロールパネルの「コンソール」ボタンが有効化されたら、すかさず押す
  4. コンソール画面で、キー入力

上記手順で、古いカーネルなり、レスキューモードなりを選んで起動して、復旧作業ができるようになった。

サーバーの移行手順

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

1.移行手順

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

1)新サーバーの環境構築

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

新サーバーの環境構築

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

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

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

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

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

2)新Webサーバー+現行DBの動作確認

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

新Webサーバー+現行DBの動作確認

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

3)DNSを変更してWebサーバー並行稼働(現行DB)

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

DNS設定を変更し、Webサーバー並行稼働(現行DB)

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

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

4)DBサーバーを移行し、新サーバーにて運用

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

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

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

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

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

2.レプリケーション機能を使う場合

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

2)と3)の間で、新DBをスレーブに設定することで、

3)Webサーバー並行稼働+現行DBサーバー(マスタ)+新DBサーバー(スレーブ)といった運用にする。

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

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

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

クラウド/VPS/レンタルサーバーの【コントロールパネル】セキュリティ対策

※これは古いです。最新版(2020年11月)はこちら

クラウド、VPSのセキュリティ対策について、サーバー自体のセキュリティ対策をちゃんとしても、コントロールパネルが乗っ取られたら元も子もない。

そこで、知っている範囲での各社の状況 (2019年2月21日時点)についてのメモ。

  IP制限 2段階認証 ログイン通知 操作ログ
お名前.com × × × ×
ConoHa × ×
エックスサーバー × × × ×
さくらインターネット ×

VPS:×

クラウド:〇

×
ニフクラ × ×

1. お名前.com

「お名前.com Navi」にログイン出来たら、後はすべて操作可能。ログインに関する制限、通知等の機能もない。

2.ConoHa

「アカウント設定」から「2段階認証」「ログイン通知メール」が可能。

https://support.conoha.jp/common/guide/account/?btn_id=c-2stepauthentication-sidebar_guide-account

3.エックスサーバー

「サーバーパネル」にログイン出来たら、後はすべて操作可能。ログインに関する制限、通知等の機能もない。

4. さくらインターネット

VPSとクラウドともに操作ログが閲覧できる。

(VPS)

https://help.sakura.ad.jp/hc/ja/articles/206245282-%E6%93%8D%E4%BD%9C%E5%B1%A5%E6%AD%B4%E3%82%92%E7%A2%BA%E8%AA%8D%E3%81%99%E3%82%8B

(クラウド)

https://manual.sakura.ad.jp/cloud/controlpanel/eventlog/eventlog.html

クラウドは2段階認証にも対応。

https://manual.sakura.ad.jp/cloud/controlpanel/settings/2-factor-auth.html

5. ニフクラ(旧名称:ニフティクラウド)

ログインのIPアドレス制限が、「アカウント管理」からアカウントを選択して、「IP許可設定追加」で可能。

https://cloud.nifty.com/service/ip_limit.htm

また、過去6カ月分のコントロールパネルの操作ログが参照できる。

https://cloud.nifty.com/help/log/

ログイン時の通知メールの機能はない。