前提
キノスラテストサーバーのSSD容量を増築する作業の方法を記載します。
ここでは二つのサーバーが説明に出てくるため、
以下の通り言い換えています。
元々存在しているキノスラテストサーバー:
サーバーA
新規で作成したミラーサーバー:
サーバーB
■タスク内容
サーバーAのSSD容量を100GBから200GBに増やす。
■使用サービス
さくらのVPS
■OS
CentOs7
■Apache
2.4.6
■/var/www/配下に設置するディレクトリ
cynosura.jp
キノスラテストサーバーが壊れた原因
当時、サーバーが壊れた原因について、明確に把握できておりません。
以下に心当たりのある原因を書き出しますので、
作業時の参考にしてください。
原因1.
ディスクを管理するレコード(partition table scan)について、
MBRからGPTへの移行（パーティションテーブルの フォーマットの変更）ができていなかった。
ディスク拡張前に、レスキューモードで起動し、レコードの移行しておく必要があるかも。
パーティションテーブル
⇒一般にハードディスクのパーティションがどのエリアにあるかなどの管理情報が含まれた情報を指します。
[マニュアル]
Partition table scan :
MBR: protective
BSD: not present
APM: not present
GPT: present
[サーバーA]
Partition table scan :
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
【参考URL】（未確認）
https://server-setting.info/centos/mbr-gpt.html
原因2.
新規でパーティションを作成して割り当てようとしていた。
さくらの公式サイトでは、「新しいパーティションを作成して割り当てる」ための公式マニュアルしかない。
実際にやりたかった作業は、「既存のパーティションを拡張する」こと。
【参考URL】（未確認）
https://onoredekaiketsu.com/extend-partition-after-increasing-storage-capacity-with-sakura-vps/
■Apacheのバージョン
サーバーAにインストールしていたApacheが原因の可能性もある。
（バージョン未確認のため、不確実）
■インストールしたパッケージ
マニュアル通り、gdiskというパッケージをインストールしたが、
サーバーAと互換性があったのか不明。
双方のパーティション状況を確認すると、以下の点が気になる。
[マニュアル]
Partition table scan :
MBR: protective
BSD: not present
APM: not present
GPT: present
[サーバーA]
Partition table scan :
MBR: MBR only
BSD: not present
APM: not present
GPT: not present■ディスク拡張時のディスク状況
作業マニュアルとサーバーAで、ディスク状況に差異があった。
（「partition table scan」 や 「Name」など）
SSD容量増築編
当時の本来の目的です。
サーバーAの容量がいっぱいになってしまったため、
100GB⇒200GBに増築することが作業内容でした。
バックアップを作成
サーバーAのFTP領域のデータをすべてコピーするため、新規でサーバーを借ります。
※既にバックアップ用のサーバーやSSDがあればこちらの作業は不要です。
①バックアップ用のサーバーを借りる
②FTP領域のデータのバックアップをとる
③SQLデータのバックアップをとる
バックアップ用のサーバーを借りる
バックアップファイルの容量を下回らないよう、
SSD容量に注意し、サーバーを借りてください。
FTP領域のデータのバックアップをとる
ルート配下のデータをすべてバックアップとして控えてください。
（サーバー設定編で/var/www/html/配下より上の階層のデータを使用します。）
【参考URL】（未確認）
https://qiita.com/sayama0402/items/c5c2795968ced798150a
SQLデータのバックアップをとる
ワードプレスのデータ(SQL)をバックアップとして控えてください。
サーバーが壊れた際に、復旧可能になります。
【参考URL】（未確認）
https://helpcenter.gmocloud.com/iclusta/s/article/ch-4268
SSDの容量を増築する
スケールアップ⇒ディスク拡張 の手順で作業します。
スケールアップ = SSD容量を増築する作業
ディスク拡張 = 増築したSSD容量を認識させる作業
①スケールアップ
②ディスク拡張
スケールアップ
※スケールアップを行うためには、サーバーを停止させる必要があります。
一時的にサーバーが停止する旨をメンバーと、必要に応じてクライアントに連絡。
サーバー停止時間の目安: 24h（作業当時は、0.1h-0.5hで完了しました。）
１．コンパネ内の契約情報から、スケールアップを選択
２．プランを選択
ディスク拡張
※本作業が原因で、サーバーが壊れてしまう可能性があります。
作業する際には、必ずFTP領域ファイルとSQLのバックアップを取得してください。
■作業前の確認事項
・操作コマンドの確認
・環境の確認（パーティションの名前や属性など）
【参照URL】（OSのバージョンは合わせてください）
https://manual.sakura.ad.jp/vps/server/disk-expansion/centos7.html?highlight=%E3%83%87%E3%82%A3%E3%82%B9%E3%82%AF%E6%8B%A1%E5%BC%B5
上記ページの作業が問題なく完了できれば、増築作業は完了です。
作業中にサーバーに接続できなくなった場合は、
「サーバー修復編」→「サーバー復旧編」の順に参照してください。
■当時の状況
①さくらvps内の「VNCコンソール」からサーバーにログイン
②パッケージのインストール
# yum -y install gdisk
③パーティションのソート
# sgdisk -s /dev/vda
④パーティションの作成
# gdisk /dev/vda
⑤OSの再起動
# reboot
⑤の作業後、サーバーに接続できなくなった。
サーバー修復編
何らかの操作で、サーバーに接続できなくなった場合、本章を参照し、
サーバーの修復を試みてください。
（修復できる保証はありません。）
原因の調査と修復コマンド
原因に心当たりがない場合、まずはさくらVPSに問い合わせしてみてください。
■当時の状況
①原因が分からず、さくらVPSに問い合わせたところ、
「fsck」コマンドを案内された。
②レスキューモードにてサーバーを立ち上げ、
マウントしたディレクトリに対して「fsck」コマンドで修復を試みる。
# fsck /mnt/sysimage/dev/vda3
③修復できなかったため、サーバーの復旧を行う。（次章）
【参考URL】
https://atmarkit.itmedia.co.jp/ait/articles/1803/15/news040.html
サーバー復旧編
サーバーの修復が出来なかった場合、
本章を参考に、OS・Apache再インストールと設定変更をしてください。
OSとApacheの再インストール前の確認
①使用しているサービスの確認
②ワードプレスが復旧できるか確認
③OS再インストール時のチェック項目確認
使用しているサービスの確認
OSとApacheの再インストールに伴い、使用しているサービスも全て削除されてしまいます。
削除前に使用しているサービスを確認し、再インストール後に復旧できるようにします。
■開いているポートから確認（全てのポートが閉じていたら確認はできない）# fsck /mnt/sysimage/dev/vda3
例: SMTPで開ける使用されるポート（25 / 587 / 465 / 2525）
■使用サービスから確認# systemctl list-units -type service
http://yokensaka.com/centos/?p=359
https://dekiruengineer.com/engineer/linux_sytemctl_service_enable_disable/
上記の様な一覧が載っているサイトに含まれていれば、
特有のサービスではないと考えられます。
出力例:
ワードプレスが復旧できるか確認
サーバーBが存在してる場合、
所有しているFTP領域のデータだけでワードプレスが復旧できるか確認してください。
（この時点では既にmariaDBなどに接続できないため。）
尚、通常であれば、移行元のphpmyadmin上でSQLデータを「.sql」ファイルとしてエクスポートし、
移行先のphpmyadmin上でインポートします。
【参考URL】（未確認）
https://qiita.com/___uhu/items/74168be48c05638c7ac5
OS再インストール時のチェック項目確認
当時、参考サイトは見当たりませんでした。
上記以外に確認が必要な項目がないか一度調査してください。
検索方法
「centos7 再インストール方法」
「centos7 再インストール 手順」
「centos7 再インストール 注意点」
「centos7 再インストール 準備」
「centos7 再インストール 作業前」など
OSの再インストールと初期設定
①OSの再インストール
②OSインストール後の初期設定
OSの再インストール
OSの再インストールを行ってください。
【参照URL】
https://manual.sakura.ad.jp/vps/os-reinstall/reinstall.html
OSインストール後の初期設定
OSインストール後の初期設定を行ってください。
【参照URL】
■さくらVPSのマニュアル
https://knowledge.sakura.ad.jp/8218/
■Conohaのマニュアル（さくらVPSのマニュアルだけでは、情報が足りないため）
https://support.conoha.jp/vps/school/wordpress/?btn_id=vps_vps-school-wordpress
データの移行
①データ移行用のディレクトリ作成
②データを移行
データ移行用のディレクトリ作成
初期の状態では、/var/www/html に各コンテンツを格納しますが、
サブドメインの設定を行う都合上、下記ディレクトリを作成してください。
/var/www/cynosura.jp
データを移行
2-1（バックアップを作成）で取得したバックアップファイルを/var/www/cynosura.jp に移行してください。
例:
/var/www/cynosura.jp/aibatest
/var/www/cynosura.jp/hc-gold
サーバー設定編
cynosura.jpディレクトリの所有者を変更
SSHでディレクトリを作成した場合の所有者は、ログインしているアカウントに基づきます。
（rootアカウントで作成すると、所有権とグループはrootになる）
このままでは、他のアカウントで編集などが行えないため、
ディレクトリの所有者・グループをapacheに変更してください。
[ 所有者・グループともにApacheに変更 ]# chown -R apache:apache /var/www/cynosura.jp
cynosura.jpディレクトリとその配下のディレクトリ・ファイルのパーミッション変更
4-3（データの移行）で作成したディレクトリとディレクトリ配下のディレクトリ・ファイルは、
パーミッションを変更しないと操作が行えないため、パーミッションの変更をしてください。
①パーミッション変更（cynosura.jpディレクトリ）
②パーミッション変更（ディレクトリ）
③パーミッション変更（ファイル）
パーミッション変更（cynosura.jpディレクトリ）
[ cynosura.jpディレクトリのパーミッションを775に変更 ]# chmod 775 /var/www/cynosura.jp
パーミッション変更（ディレクトリ）
[ cynosura.jpディレクトリに移動 ]# cd /var/www/cynosura.jp
[ 現在のディレクトリ以下のディレクトリのみを 775 に変更 ]# find . -type d -print | xargs chmod 775
パーミッション変更（ファイル）
[ cynosura.jpディレクトリに移動 ]# cd /var/www/cynosura.jp
[ 現在のディレクトリ以下のファイルのみを 664 に変更 ]# find . -type f -print | xargs chmod 664
SSH経由で作成したディレクトリ・ファイルの初期パーミッションを変更
5-2（cynosura.jpディレクトリとその配下のディレクトリ・ファイルのパーミッション変更）の設定だけでは、
SSH経由で新規作成したディレクトリ・ファイルのパーミッションが変わらないため、
別途設定を変更してください。
[ sshディレクトリに移動 ]# cd /etc/ssh
[ 編集ファイルのコピーを作成 ]# cp -pi sshd_config sshd_config.bk_yymmdd
[ ファイルを編集 ]# vi sshd_config
以下の通り、ソースを書き換えてください。
Subsystem sftp /usr/libexec/openssh/sftp-server
↓
Subsystem sftp /usr/libexec/openssh/sftp-server -u 002
ユーザーの作成と所属グループの変更
各メンバーのFTP用ユーザーを作成します。
（それぞれがユーザーを持つことで、更新者を把握することができる。）
また、ユーザーを作成しただけでは、
パーミッションの関係上、FTPソフトでのファイル操作を行えません。
そのため、ユーザーの所属グループを変更してください。
①アカウントの作成
②所属グループの変更
アカウントの作成
[ ユーザーを追加 ]# adduser ユーザー名
[ パスワードを設定 ]# passwd パスワードを登録したいユーザー名
所属グループの変更
FTPソフトでファイル操作を行えるようにするため、
ユーザーの所属グループをApacheに変更してください。
※必ずプライマリグループを変更してください。
（セカンダリグループでは、グループの権限が反映されない。）
[ ユーザーの所属グループ確認 ]# groups ユーザー名
初期設定のプライマリグループは、
ユーザー名がそのまま入っている。
[ ユーザーのプライマリグループを変更 ]# usermod -g apache ユーザー名
ディレクトリ名がそのままサブドメインになるように設定
サーバーAは、ディレクトリ名をそのままサブドメインとして反映されるよう設定しています。
本章では、その設定方法を記載いたします。
例:
/var/www/cynosura.jp/aibatest/
http://aibatest.cynosura.jp/
/var/www/cynosura.jp/hc_gold/
http://hc_gold.cynosura.jp/
①追加設定ファイルのアップロード
②大元の設定ファイルを調整
③サブドメイン用ディレクトリ作成時の注意点
追加設定ファイルのアップロード
[ログ保管用ディレクトリを作成 ]# cd /var/log/httpd/# mkdir cynosura.jp
[ 追加設定ファイルをアップロード ]# cd /etc/httpd/conf.d/
下記フォルダ内のファイルをそのままアップロード
Q:\80.coding\テストサーバー復旧関連\サブドメイン設定に必要なファイル\etc\httpd\conf.d
大元の設定ファイルを調整
[ 大元の設定ファイルを調整 ]# cd /etc/httpd/conf/# cp httpd.conf_bk_yymmdd# vi httpd.conf
下記ファイルが現在使用しているファイル
Q:\80.coding\テストサーバー復旧関連\サブドメイン設定に必要なファイル\etc\httpd\conf\httpd.conf
※まるっとコピペすると、バージョンの違いによっては、エラーになるかもしれません。
下記フォルダに変更前と変更後のファイルをそれぞれ格納しているので、
必要箇所だけ、変更してください。
Q:\80.coding\テストサーバー復旧関連\サブドメイン設定に必要なファイル\etc\httpd\conf\マニュアル作成当時の変更内容
サブドメイン用ディレクトリ作成時の注意点
サブドメイン用ディレクトリ名にアンダースコア「_」が入っていると400エラーが出力されるため、
ハイフン「-」などに置き換える。
※サブドメイン用ディレクトリから下の階層については、アンダースコアを使用してもよい。
エラーが出力される例:
/var/www/cynosura.jp/hc_gold/
エラーが出力されない例:
/var/www/cynosura.jp/hc-gold/
/var/www/cynosura.jp/hc-gold/public_html/test_test/
【参考URL】
https://qiita.com/Anderiens/items/581b323256c93cae029e
ユーザー単位で、ルートディレクトリ（接続可能ディレクトリ）を変更
初期設定では、外注さんなど含め全ユーザーが、
サーバー内の全データを閲覧できてしまうため、
本対応で接続可能なディレクトリを制限する。
【参考URL】
・ソフト（vsftpd）のインストール
https://qiita.com/mugi-tea/items/b6ee5d9127409667bc7c
・設定ファイルの解説
https://qiita.com/ShinyaOkazawa/items/7647726ca05fc5b4f37a
https://cpoint-lab.co.jp/article/202008/16782/
・起動関連のコマンド一覧
https://qiita.com/BlueSilverCat/items/79e32ab74bcc7491ecfc
vsftpdのインストール
①vsftpdのインストール確認# yum list vsftpd
②vsftpdのインストール# yum install vsftpd
③vsftpdの状態確認# systemctl status vsftpd
④サービス開始# systemctl start vsftpd
⑤サービス自動起動（自動起動中は、vsftpdの再起動ができないため、一度自動起動を解除する必要がある。）# systemctl enable vsftpd
vsftpdの設定変更
①設定ファイルを開く# vi /etc/vsftpd/vsftpd.conf
②ルートディレクトリ設定を有効にする（コメントアウトをとる）#chroot_local_user=YES
#chroot_list_enable=YES
↓chroot_local_user=YES
chroot_list_enable=YES
③許可リストの参照先を有効 / 追記する
・有効#chroot_list_file=/etc/vsftpd/chroot_list
↓chroot_list_file=/etc/vsftpd/chroot_list
・追記user_config_dir=/etc/vsftpd/user_config_dir
④chroot先に書き込み権限があっても正常に動作させる
chrootした先に書き込み権限があるとエラーになるため、
以下を追記
allow_writeable_chroot=YES
⑤ftp接続時の、新規作成 ファイル / ディレクトリ のパーミッションを変更
（ssh接続時のumask設定よりこちらが優先される）local_umask=022
↓local_umask=002
⑥上記③で追記した、許可リストの参照先であるファイルとディレクトリを作成する# touch chroot_list# mkdir user_config_dir
[②③④設定変更前キャプチャ]
[②③④設定変更後キャプチャ]
各ユーザーを制限ごとに振り分ける
下記URLを参照してください。http://cnsrwiki.cynosura.jp/%e3%82%ad%e3%83%8e%e3%82%b9%e3%83%a9%e3%83%86%e3%82%b9%e3%83%88%e3%82%b5%e3%83%bc%e3%83%90%e3%83%bc%e6%96%b0%e8%a6%8f%e3%83%a6%e3%83%bc%e3%82%b6%e3%83%bc%e3%81%ae%e8%bf%bd%e5%8a%a0%e6%96%b9%e6%b3%95/
22番ポートの閉鎖（別のポート番号に変更）
上記、「ユーザー単位で、ルートディレクトリ（接続可能ディレクトリ）を変更」の設定は、
21番ポートで接続時限定の設定になります。
22番ポートでは、設定前と同様、
自由に接続ができてしまうため、
接続できないように閉じます。
ポート番号の選定
設定するポート番号が、既に使用しているポート番号と
バッティングしないように、予め確認する。
※0番～1023番はよく使われるポート番号として様々なサービスに使われているため、使用を避ける。
[参考URL]
https://www.braveryk7.com/change-22-port/
ポート番号を何番にするか決めておく
# lsof -i:[任意のポート番号]
上記コマンドを入力し、何も表示されなければ、
使用されていない（使用して良い。）
ファイアウォールの設定変更
ファイアウォールを有効にしている場合は、
ポート変更前に許可するポートを追加します。
[参考URL]
https://www.braveryk7.com/vps-firewall/
SSHのポート変更
①ポートの追加# firewall-cmd --zone=public --add-port=[任意のポート番号]/tcp --permanent# firewall-cmd --reload
②確認# firewall-cmd --zone=public --list-all
sshd_configの設定変更
[参考URL]
https://www.braveryk7.com/change-22-port/
①sshd_configの編集# vi /etc/ssh/sshd_config#Port 22
↓Port [任意のポート番号]
②設定の反映# systemctl restart sshd.service
クローラーにサイトをクロールさせないための設定
初期設定のままでは、各ブラウザのクローラーがクロールしてしまいます。
クロールされてしまうと、本番のデータとテスト環境のデータが重複コンテンツ扱いになり、
SEOスコアに悪影響を及ぼしかねません。
①ファイルのアップロード
②設定ファイルへの記述追加
ファイルのアップロード
下記ファイルを同ディレクトリにアップロードしてください。
Q:\80.coding\テストサーバー復旧関連\クロールさせないための設定に必要なファイル
設定ファイルへの記述追加
5-5（ディレクトリ名がそのままサブドメインになるように設定）にて、
既にアップロード済みです。
下記フォルダ内のファイルをそのまま格納
Q:\80.coding\テストサーバー復旧関連\サブドメイン設定に必要なファイル\etc\httpd\conf.d
↓該当の記述
RewriteRule /var/www/cynosura.jp/(.*)/public_html/robots.txt /cynosura_common_alias/robots.txt [QSA,L]
Alias /cynosura_common_alias /var/www/common/cynosura.jp
設定は以上で終了です。
おつかれさまでした。
当時の作業メモ
上記の作業で設定変更自体は完了していますが、
何かに躓いた際、役に立つかもしれないので、
当時の作業メモを記載します。
レスキューモード関連
初期状態のOSを使ってサーバーを起動するモードです。
SSHやFTPでサーバーに接続できなくなった場合、
こちらのモードで起動を試みてください。
【参照URL】（パブリックISOインストールからの起動を実施する)
https://manual.sakura.ad.jp/vps/troubleshoot/rescue_boot.html
※サーバーが起動しない原因がOS側にある場合に、
こちらのモードで起動することが可能です。
※マウントしたファイルは、起動しないサーバーのファイルとイコールになります。
（ファイルを上書きすると、起動しないサーバーのファイルが上書きされる。）
システムファイルを上書きする際などは、バックアップを取るなどして、修復可能な環境で作業してください。
※SSHでの接続 / レスキューモードでの起動 ともにできなくなった場合は、
OSの再インストールをするしかありません。
マウントしたファイルをSSH接続で別サーバーへコピー
取得したいデータが起動しないサーバー内に存在する場合、
SSHやFTPでデータの取得が出来ません。
レスキューモードでデータをマウントすることができれば、
SSHで別サーバーへコピーすることができます。
①レスキューモードで起動
②ネットワークの設定
③データの移行
レスキューモードで起動
6-1（レスキューモード関連）の
【参照URL】箇所を参照。
ネットワークの設定
レスキューモードの起動ではネットワーク設定、
またルーティングテーブルが未設定の状態で、外部への通信ができないため、
設定が必要です。
【参照URL】（ネットワークの設定)
https://qiita.com/mamoroom/items/1b84316c4fe93f75fe23
１．ネットワーク設定確認（未設定なことを確認）# ping 8.8.8.8# route -v# ifconfig
２．設定追加
※あくまで記述例です。アドレスやゲートウェイの数値などは、
設定するサーバーに合わせてください。# ifconfig eth0 133.242.177.167 netmask 255.255.254.0# route add default gw 133.242.176.1
３．ネットワーク設定確認
# route -v# ifconfig# ping 8.8.8.8
※ping を確認すると表示が止まらなくなるため、[CTRL]+Cで停止させる
【参照URL】
https://naokirin.hatenablog.com/entry/20101220/1292839505
データの移行
ネットワーク接続が完了したら、データを移行します。
【参照URL】
https://www.server-memo.net/tips/rsync/rsync.html#rsync_ssh
※移行データの容量が大きいと、クラッシュする可能性がある。（レスキューモードで起動できなくなる）
コマンドにオプションを付与して、メモリ使用量を減らす。
【参照URL】(実際の挙動は未確認)
https://pyopyopyo.hatenablog.com/entry/2019/02/18/090000
オプション付与前のコマンド例# rsync -azv -e ssh /mnt/sysimage/var/www/html/backup_230106/sysimage/etc/httpd/conf.d/vhost.conf toshiki-aiba@160.16.102.84:/var/wwww/html/aibatest/
fsckコマンド関連
fsckコマンドが効かなかった場合、
下記対応が参考になるかもしれません。（実際の挙動は未確認）
①ファイルシステムのチェック
# e2fsck -p /dev/vda3
おそらく「The superblock could not be read～」が出力される
http://systemdev.comsys-blog.com/2011/05/05/linux-turbolinux-%E3%81%A7%E3%83%91%E3%83%BC%E3%83%86%E3%82%A3%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%8C%E7%A0%B4%E5%A3%8A%E3%81%95%E3%82%8C%E3%81%9F%E3%82%89%E3%81%A9%E3%81%86%E5%BE%A9%E6%97%A7%E3%81%99/
②ブロックサイズ（Block size）とスーパーブロックのバックアップが保存されている場所（Superblock backups）を調べる。
# mkfs.ext3 -n /dev/vda3
③fsck.ext3コマンドでファイルシステムのチェックを行う。その際に、-bオプションでスーパーブロックバックアップの場所、-Bオプションでブロックサイズを指定
# fsck.ext3 -b 32768 -B 4096 /dev/vda3
※「32768」と「4096」は環境に合わせる
https://atmarkit.itmedia.co.jp/flinux/rensai/linuxtips/728fixpartition.html
おそらく「Bad magic number in super-bloc～」が出力される
④-Sオプション付きでmke2fsコマンドを実行して、スーパーブロックを再作成
# mke2fs -S /dev/vda3
