2026年5月28日

VPSのOSを再インストールする方法：消える範囲の確認・バックアップ・再設定と復元の手順

VPS・クラウド

VPS の OS 再インストールは、管理画面のボタン1つで始められる一方、ディスクの中身がすべて消える作業です。成功の分かれ目は、ボタンを押す前に「何が消えて何が残るか」を確かめ、復元できるバックアップを手元に置いておけるかどうかです。この記事では、再インストールの前に記録・退避しておくもの、実行時の選択、再インストール後の SSH の警告への対処、WordPress サイトの復元までを順に説明します。

再インストールで消えるもの・残るもの

多くの VPS サービスで、OS の再インストールは「同じ契約・同じサーバーのまま、ディスクを初期化して OS イメージを書き込み直す」操作です。細かな挙動はサービスごとに異なるので、利用中のサービスのマニュアルで次の点を確かめてください。

消えるもの: ディスク上のすべてのデータ。サイトのファイル、データベース、/etc の設定、cron、SSL 証明書、ユーザーとホームディレクトリ、SSH のホスト鍵。
多くの場合残るもの: 契約とプラン、IP アドレス、管理画面側で設定したファイアウォールや逆引きなどの設定。
サービスによって異なるもの: 追加ディスクやブロックストレージの扱い、スナップショットやバックアップオプションのデータが残るか、IP アドレスが変わるか。

IP アドレスが変わるサービスや、「再インストール」ではなく「サーバーの削除と再作成」になる操作では、DNS の書き換えが必要になります。DNS の TTL を前日までに短くしておくと、切り替え後に古い IP が参照され続ける時間を減らせます。

そもそも再インストールが最善かを考える

再インストールを選ぶ理由は、OS のメジャーバージョンを上げたい、設定が入り組んで分からなくなった、不正侵入の疑いがある、などでしょう。

稼働中のサイトがあるなら、新しい VPS をもう1台用意して構築し、DNS を切り替える 方法も検討してください。旧サーバーが残っているので、問題が起きてもすぐ戻せます。同じ VPS で再インストールすると、作業中はサイトが止まり、戻る先はバックアップだけになります。

不正侵入が疑われる場合は、再インストールは適した手段です。ただしバックアップしたファイルに改ざんが含まれている可能性があるので、WordPress のコアやプラグインは公式から入れ直し、wp-content/uploads に PHP ファイルが紛れていないかを確かめてから戻します。

手順1: 今の設定を記録する

再インストール後に同じ環境を作り直すため、今の状態を書き出します。

mkdir -p ~/reinstall-notes && cd ~/reinstall-notes

cat /etc/os-release > os.txt
apt-mark showmanual > packages-manual.txt     # 自分で入れたパッケージ
sudo crontab -l > crontab-root.txt 2>/dev/null
crontab -l > crontab-user.txt 2>/dev/null
sudo ufw status numbered > ufw.txt 2>/dev/null
ss -tlnp > listening-ports.txt
php -v > php.txt 2>/dev/null
sudo certbot certificates > certbot.txt 2>/dev/null

あわせて、Web サーバーと PHP、データベースの設定ディレクトリをまとめて保存します。

sudo tar czf ~/reinstall-notes/etc-backup.tar.gz \
  /etc/nginx /etc/apache2 /etc/php /etc/mysql /etc/letsencrypt \
  /etc/ssh/sshd_config.d /etc/cron.d 2>/dev/null

存在しないディレクトリは警告が出るだけで、残りは保存されます。/etc/letsencrypt を残しておくと証明書を再発行せずに戻せます。証明書の発行には回数の制限があるので、同じドメインで何度も発行し直さずに済むのは安心材料です。

手順2: サイトとデータベースを退避する

WordPress なら、データベースと wp-content、wp-config.php があれば復元できます。WP-CLI が使える場合は次のとおりです。

cd /var/www/example.com
wp db export ~/backup/db-$(date +%Y%m%d).sql
tar czf ~/backup/wp-content-$(date +%Y%m%d).tar.gz wp-content
cp wp-config.php ~/backup/

WP-CLI がなければ mysqldump --single-transaction でデータベースを書き出します。

退避したファイルは、VPS の外 に移します。同じ VPS の中に置いたままでは、再インストールで一緒に消えます。手元の PC へ取得するなら rsync が便利です。

# 手元の PC で実行
rsync -avz deploy@203.0.113.10:~/backup/ ./vps-backup/
rsync -avz deploy@203.0.113.10:~/reinstall-notes/ ./vps-notes/

取得したら、壊れていないかを確かめます。

gzip -t vps-backup/*.tar.gz && echo OK
tar tzf vps-backup/wp-content-*.tar.gz | head
head -n 5 vps-backup/db-*.sql

ここまでで、「ボタンを押してもサイトを戻せる」状態になりました。サービスにスナップショット機能があるなら、念のため再インストール直前に取得しておくと、記録漏れに気づいたときに戻れます。

手順3: 再インストールを実行する

管理画面の名称や手順はサービスごとに違いますが、たいていはサーバーの詳細画面に「OS 再インストール」に相当する項目があります。実行時に選ぶのは主に次の3つです。

OS イメージ: 特別な理由がなければ、サポート期間の長い LTS 版を選びます。Ubuntu なら、サポート中の LTS（2026年10月現在）である 24.04 や 26.04 などです。アプリケーション入りのイメージ（WordPress 入りなど）を選ぶと、構成がサービス独自になる点に注意してください。
認証方法: SSH 公開鍵を登録できるならそれを選びます。パスワードを設定する方式なら、長くランダムなものにして、初期設定が終わったらパスワード認証を止めます。
確認: データが消える旨の確認が出ます。サーバー名や IP を見て、対象を取り違えていないかをここで確かめます。複数の VPS を契約している場合、取り違えはいちばん痛い失敗です。

実行中は電源が切れ、数分から十数分ほどで新しい OS が起動します。

手順4: 「ホスト鍵が変わった」警告に対処する

再インストール後に SSH で接続すると、次のような警告が出て接続が拒否されます。

@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @

再インストールでサーバーのホスト鍵が作り直されたためで、想定どおりの動きです。手元の known_hosts から古い記録を消します。

ssh-keygen -R 203.0.113.10
ssh-keygen -R vps.example.com

本来この警告は、なりすましの可能性を知らせるものです。気になる場合は、管理画面のコンソールから入って ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub を実行し、初回接続時に表示されるフィンガープリントと一致するかを確かめてから接続します。

手順5: 初期設定をやり直す

新しい OS は、作成直後のサーバーと同じ状態です。次の順で進めます。

パッケージの更新（sudo apt update && sudo apt upgrade）
作業用ユーザーの作成と SSH 鍵の登録
root ログインとパスワード認証の停止
ファイアウォールの設定（SSH を先に許可してから有効化）
タイムゾーン、スワップ、自動セキュリティ更新

SSH の設定を変えるときは、今の接続を閉じずに別の端末から入れることを確かめてから閉じます。入れなくなっても、管理画面のコンソールから戻せることを最初に確認しておくと安心です。

手順6: WordPress を戻す

Web サーバー、PHP、データベースを入れたら、手順1で記録した設定を見ながら同じ構成にします。PHP の拡張モジュールは packages-manual.txt を見ると漏れに気づけます。

# データベースとユーザーを作成したあと
cd /var/www/example.com
wp core download --locale=ja
tar xzf ~/backup/wp-content-*.tar.gz
cp ~/backup/wp-config.php .
wp db import ~/backup/db-*.sql
sudo chown -R www-data:www-data /var/www/example.com

wp-config.php のデータベース名・ユーザー・パスワードは、新しく作ったものと合わせます。OS のバージョンを上げた場合は PHP のバージョンも変わっていることが多いので、プラグインやテーマが対応しているかを確かめてください。

確認は、次の順に進めると原因を絞りやすくなります。

wp option get siteurl が正しい URL を返すか（データベースに接続できているか）
トップページと投稿ページ、管理画面が開くか
パーマリンクが 404 にならないか（Nginx の設定や Apache の mod_rewrite を確認）
画像のアップロードができるか（ファイルの所有者と権限）
HTTPS で開けるか、証明書の自動更新が動くか（sudo certbot renew --dry-run）
cron で動かしていた処理を戻したか（crontab-*.txt を見ながら）

すべて確かめたら、退避したバックアップはすぐ消さず、しばらく残しておきます。数日たってから戻し忘れに気づくことがあるためです。

まとめ

再インストールでディスクの中身はすべて消える。IP や追加ディスクの扱いはサービスのマニュアルで確かめる。
稼働中のサイトなら、新しい VPS で構築して DNS を切り替える方法のほうが戻しやすい。
パッケージ一覧・cron・/etc の設定・証明書を記録し、サイトとデータベースは VPS の外へ退避して中身を確かめる。
実行時は対象のサーバーを取り違えていないかを確認する。
ホスト鍵の警告は ssh-keygen -R で古い記録を消して対処する。
復元後はデータベース接続・パーマリンク・権限・HTTPS・cron の順に確かめる。