WordPressのXserverへの移行

お名前.comのレンタルサーバーから、Xserverのレンタルサーバーへ移行した。WordPressの移行については、「WordPress簡単移行」で移行した。

https://www.xserver.ne.jp/manual/man_install_transfer_wp.php

便利で楽にできていいのだが、ただ、一つのサイトだけデータ移行のところで失敗して移行できなかった。

【原因】

プラグインの「Google Map WP」がDBでバイナリデータを使っていて、それが通常方法でdumpした場合には復元できないためエラーとなるよう。

【対応方法】

「WordPress簡単移行」を使いたい場合は、一旦、「Google Map WP」プラグインを削除してから移行して、その後、Xser ver側で再度、プラグインを入れるしかないか。

そうじゃなければ、自分で移行する。

https://www.xserver.ne.jp/manual/man_install_transfer_wordpress.php

その場合、DBバックアップ時には「–hex-blob」オプションを指定すること。

https://dev.mysql.com/doc/refman/5.6/ja/mysqldump.html#option_mysqldump_hex-blob

バックアップ設定

以下、バックアップの方針に基づいて、CentOSサーバー間で、バックアップ設定した手順。

0.環境

転送元サーバー:CentOS 8.2

  • ホスト名(例):www.xxservice.com
  • グローバルアドレス(例):222.222.222.222
  • プライベートネットワークアドレス(例):10.10.10.1
  • sshdポート(例):7777
  • バックアップを実行するユーザー(例):appuser

転送先サーバー1:CentOS 7.8

  • ホスト名(例):bak1.xxservice.com
  • プライベートネットワークアドレス(例):10.10.10.200
  • sshdポート(例):8888

転送先サーバー2:CentOS 7.8

  • ホスト名(例):bak2.xxservice.com
  • 転送元サーバーとは別拠点で、プライベトネットワーク未接続
  • sshdポート(例):9999

1.転送先サーバーの設定

バックアップ用ユーザー(例):backupuser

バックアップディレクトリ(例):/home/backupuser/xxservice/

1-1)sshd_configの修正

/etc/ssh/sshd_configの設定が以下となるようにする。

  • ホストベース認証を有効
  • ホストベース認証の既知ホストは、ユーザーディレクトリ下を許可
  • ユーザーディレクトリ下の.shostsを有効にする。
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
HostbasedAuthentication yes
# Change to yes if you don't trust ~/.ssh/known_hosts for HostbasedAuthentication 
IgnoreUserKnownHosts no 
# Don't read the user's ~/.rhosts and ~/.shosts files 
IgnoreRhosts no

後、プライベートネットワークでは逆引きできない。余計なログを出さないようにUseDNSがyesの場合は、noに変更する。

UseDNS no

設定変更後に、設定の読み込み。

$ systemctl reload sshd

1-2)rootユーザーへのスイッチ禁止

/etc/pam.d/suで、以下を設定し、rootユーザへのスイッチを禁止する。

auth required pam_wheel.so use_uid root_only

1-3)バックアップ用ユーザー作成

$ adduser backupuser

1-4)バックアップ用ディレクトリ作成

$ su - backupuser
[backupuser ~]$ mkdir xxservice

1-5)既知ホストの追加

バックアップユーザーで、転送元サーバーにssh接続を試みて、公開鍵を取得して既知ホストに登録する。

※転送先サーバー1の場合
[backupuser ~]$ ssh -p 7777 10.10.10.1

※転送先サーバー2の場合
[backupuser ~]$ ssh -p 7777 www.xxservice.com

既知ホストに追加するかと聞いてくるので、yesで登録すると、~/.ssh/known_hostsに登録される。

ポート番号が入った形で登録されるので、viコマンドで修正する。

※転送先サーバー2の場合、以下のように修正する

[www.xxservice.com]:7777,[222.222.222.222]:7777 (公開鍵) 
↓
www.xxservice.com,222.222.222.222 (公開鍵)

1-6).shostsの設定

viコマンドで、.shostsファイルを作成し、中身は以下とする。転送元サーバーのIPアドレスを設定する。

※転送先サーバー1の場合

10.10.10.1 appuser 

※転送先サーバー2の場合

222.222.222.222 appuser 

パーミッションを変更して、.shostsファイルを見えないようにする。

[backupuser ~]$ chmod 600 .shosts

2.転送元サーバーの設定

2-1)ssh_configの修正

従来はssh_configを直接修正していたが、CentOS 8.2 では、以下ディレクトリにファイル追加するのが作法みたい。

/etc/ssh/ssh_config.d/99-hostbase.confを、以下内容で作成する。

HostbasedAuthentication yes
EnableSSHKeysign yes

2-2)既知ホストの追加と接続確認

以下コマンドで接続し、既知ホストに追加するかと聞いてくるので、yesで登録する。

※転送先サーバー1への接続
[appuser ~]$ ssh -p 8888 -l backupuser 10.10.10.200

※転送先サーバー2
[appuser ~]$ ssh -p 9999 -l backupuser bak2.xxservice.com

問題なければ、無事にログインできる。

2-3)バックアップ処理の登録

以下のコマンドを作成して、実行権を付けて、cron実行する。

2-3-1)バックアップコマンド

do_backupという名前で以下ファイルを作成する。timeコマンドで実行時間を計測しながら、低優先度でバックアップを実行する。

引数は、バックアップサーバーのアドレス、ポート、バックアップファイルの接尾辞で、このコマンドは、バッチから引数を渡されて実行される。

【do_backup】

#!/bin/sh
#
alias dotime='time ionice -c 2 -n 7 nice -n 19'

# param
if [ $# -ne 3 ]; then
  echo "param error!!"
  exit 1
fi
BACKUP_SERVER=$1
BACKUP_SERVER_PORT=$2
BACKUP_SUFFIX=$3

# file setting
BIN_DIR=(コマンドの配置ディレクトリ)
BACKUP_DIR=(バックアップファイルを置くディレクトリ)
BACKUP_LOG="$BACKUP_DIR/bak_$BACKUP_SUFFIX.log"

BACK_FILE_DB="$BACKUP_DIR/dbbak_$BACKUP_SUFFIX"

APP_DIR=(アプリケーションデータのディレクトリ)
BACK_APP_DIR="$BACKUP_DIR/appdata/"

TRNS_DB_DIR="/home/backupuser/xxservice/"
TRNS_APP_DIR="/home/backupuser/xxservice/appdata/"

#--------------------------------------------------
# Start
echo "---- START : `date`"  > $BACKUP_LOG

####################
# DB
echo "---- DB S : `date`"  >> $BACKUP_LOG
(dotime $BIN_DIR/do_db_backup $BACK_FILE_DB &>> $BACKUP_LOG) &>> $BACKUP_LOG

echo "---- DB GZIP S : `date`"  >> $BACKUP_LOG
(dotime gzip -f $BACK_FILE_DB &>> $BACKUP_LOG) &>> $BACKUP_LOG

####################
# APP
echo "---- APP S : `date`"  >> $BACKUP_LOG
(dotime rsync -auv --rsync-path="ionice -c 2 -n 7 nice -n 19 rsync" \
  $APP_DIR $BACK_APP_DIR &>> $BACKUP_LOG) &>> $BACKUP_LOG

####################
# Transfer

# transfer DB backup
echo "---- TRN DB S : `date`"  >> $BACKUP_LOG
(dotime scp -P $BACKUP_SERVER_PORT $BACK_FILE_DB.gz ubackup@$BACKUP_SERVER:$TRNS_DB_DIR \
  &>> $BACKUP_LOG) &>> $BACKUP_LOG

# transfer APP backup
echo "---- TRN APP S : `date`"  >> $BACKUP_LOG
(dotime rsync -auvz -e "ssh -p $BACKUP_SERVER_PORT" $BACK_APP_DIR \
  ubackup@$BACKUP_SERVER:$TRNS_APP_DIR  &>> $BACKUP_LOG) &>> $BACKUP_LOG

# End
echo "---- END : `date`"  >> $BACKUP_LOG

最初のrsyncで、–rsync-path=”ionice -c 2 -n 7 nice -n 19 rsync”オプションを付けているのは、受信側も同じアプリサーバーのため優先度を下げている。転送時には付けていないのは、転送先サーバーはバックアップ専用のため、優先度を気にしなくていいため。

2-3-2)DBバックアップコマンド

do_db_backupという名前で以下ファイルを作成する。3-1)バックアップコマンドから呼ばれるコマンドで、DBに応じたコマンドを作成する。

【do_db_backup】

※MariaDBの例

#!/bin/sh
#
#  $1: backup file name
#

mysqldump --user=(DBユーザー) --password=(DBパスワード) --single-transaction (データベース名) > $1

※PostgreSQLの例

#!/bin/sh
#
#  $1: backup file name
#

pg_dump -Fc -b (データベース名)> $1

2-3-3)実行コマンド

バッチで実行するための、以下の2つのファイルを作成する。

【BACKUP_HOURLY】

#!/bin/sh
#

BACKUP_SERVER=10.10.10.200
BACKUP_SERVER_PORT=8888
BACKUP_SUFFIX=h`date +%H`

(コマンドの配置ディレクトリ)/do_backup \
  $BACKUP_SERVER $BACKUP_SERVER_PORT $BACKUP_SUFFIX

【BACKUP_DAILY】

#!/bin/sh
#

BACKUP_SERVER=bak2.xxservice.com
BACKUP_SERVER_PORT=9999
BACKUP_SUFFIX=d`date +%d`

(コマンドの配置ディレクトリ)/do_backup \
  $BACKUP_SERVER $BACKUP_SERVER_PORT $BACKUP_SUFFIX

2-4)cron設定

“crontab -e”で、実行コマンドをスケジューリングする。

毎時42分と、毎日3時13分にバックアップする設定の例。

# m h dom mon dow command
42 * * * * (コマンドの配置ディレクトリ)/BACKUP_HOURLY
13 3 * * * (コマンドの配置ディレクトリ)/BACKUP_DAILY

バックアップについて

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

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 コマンド

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

 

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

サーバーの移行手順

サーバーの老朽化あるいは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サーバーに切り替える

IPアドレス制限かけるもの

固定IPでのアクセスルートを確保した場合、以下に関してIPアドレス制限をかける。今後、また固定IPの変更、追加もあると思うので個人用メモ。

  • WordPressの管理ページ
  • 運営サイトの管理ページ
  • 管理者向けシステム
  • IP制限に対応しているネット銀行
  • IP制限に対応しているコントロールパネル
  • OneDrive for Business
  • SoftEther VPN Server

SSHに関しては、固定IP用サーバーの障害時に困るので、IPアドレス制限はかけずに鍵認証にて対応。将来、固定IP用サーバーを別業者でもう一つ確保して、IPアドレス制限もかけるようにするか。