VPS の設定ファイルを Git と GitHub でバックアップする方法｜nginx・fail2ban・SSH 設定を一元管理

以前の記事で、Next.js ブログのソースコードを Git と GitHub でバックアップする方法を紹介しました。

今回はその姉妹記事として、VPS の設定ファイルを同じく Git と GitHub でバックアップする方法を紹介します。

ソースコードのバックアップはできていても、nginx や fail2ban、SSH の設定ファイルはその対象外です。
この記事では、どの設定ファイルをバックアップすべきかの考え方から、1コマンドで GitHub に同期できる仕組みの作り方まで、実際の手順を紹介します。

この記事でわかること：

• バックアップすべき VPS 設定ファイルの選び方と考え方
• ~/vps-config/ フォルダに設定ファイルをまとめる方法
• GitHub のプライベートリポジトリで安全に管理する手順
• 設定変更のたびに1コマンドで自動同期できるスクリプトの作り方

VPS 設定ファイルをバックアップしないと何が起きるか

VPS でブログを運営するためには、さまざまなソフトウェアの設定ファイルを自分でカスタマイズしています。

nginx のサイト設定、fail2ban のセキュリティ設定、SSH のアクセス制限、PHP のアップロード上限——これらは /etc/ 以下のさまざまな場所に分散して存在します。

そして、VPS が壊れて再インストールが必要になったとき、ソフトウェア本体は apt install で戻せますが、自分でカスタマイズした設定の内容は完全に消えてしまいます。

「どのポート番号に変更したか」「fail2ban にどんなルールを追加したか」「PHP のアップロード上限を何 MB に設定したか」——これらを一から思い出しながら再設定するのは、想像以上に時間がかかります。
設定が不完全なまま公開状態になれば、セキュリティ上のリスクも生じます。

ソースコードのバックアップと同様に、設定ファイルも Git と GitHub で管理しておくことで、万一のときに短時間で同じ環境を再現できます。

VPS に Ubuntu Server をインストールして、WordPress サイトや、Next.js サイトを構築していますが、Nginx や fail2ban、LogWatch などを使ってセキュリティの設定を行っているものを、まとめてバックアップ、変更履歴の管理をしたいと思っていました。
今回の記事では、スクリプトを使って、設定ファイルをまとめて Git と GitHub にバックアップできるようにしたことで、変更履歴を管理しながら、何かあれば元に戻せるようになったので、サーバー管理としても非常に便利になりました。

バックアップすべき VPS 設定ファイルの選び方

設定ファイルには大きく2種類あります。
この区別を理解することが、今回の作業の出発点です。

カスタムファイル：自分で作成・変更した設定ファイルです。VPS が壊れても apt install では戻らないため、バックアップが必要です。

デフォルトファイル：パッケージのインストール時に自動で配置される設定ファイルです。再インストールすれば同じ内容に戻るため、バックアップは不要です。

たとえば fail2ban をインストールすると /etc/fail2ban/filter.d/ に多くの .conf ファイルが自動配置されます。
これらはデフォルトファイルなので対象外です。
一方、自分で作成した nginx-wp.conf のようなカスタムフィルターは必ずバックアップが必要です。

この判断基準を持っているだけで、「何をバックアップすべきか」が整理されます。

今回バックアップする設定ファイルとフォルダ構成

以下の構成で ~/vps-config/ フォルダを作り、GitHub のプライベートリポジトリで管理します。

~/vps-config/
  ├── nginx/
  │     ├── nginx.conf
  │     └── example.com.conf
  ├── fail2ban/
  │     ├── jail.local
  │     └── filter.d/
  │           └── カスタムフィルター名.conf（環境によって異なります）
  ├── ssh/
  │     └── sshd_config
  ├── php/
  │     ├── php.ini
  │     └── www.conf
  ├── logwatch/
  │     └── logwatch.conf
  ├── ufw/
  │     └── rules.txt
  ├── pm2/
  │     └── README.md
  └── backup-config.sh

ssh/・php/・logwatch/ は筆者の環境でカスタム設定を行っているため対象に含めています。
ご自身の環境に合わせて追加・削除してください。
各ファイルの判断基準は STEP 2 で説明します。

STEP 1：VPS に vps-config フォルダを作る

VPS にログインして、以下のコマンドを実行します。

mkdir -p ~/vps-config/nginx \
         ~/vps-config/fail2ban/filter.d \
         ~/vps-config/ssh \
         ~/vps-config/php \
         ~/vps-config/logwatch \
         ~/vps-config/ufw \
         ~/vps-config/pm2

mkdir はフォルダを作成するコマンドです。
-p オプションをつけることで、途中のフォルダが存在しない場合でも、必要なフォルダをまとめて一度に作成できます。
また、すでにフォルダが存在していてもエラーになりません。
行末の \ は「このコマンドは次の行に続く」という意味で、見た目は複数行ですが1つのコマンドとして実行されます。

作成できたか確認します。

find ~/vps-config -type d

find はファイルやフォルダを検索するコマンドです。
-type d はフォルダのみを対象にするオプションです（d は directory の略）。
作成した各フォルダのパスが一覧表示されれば成功です。

STEP 2：設定ファイルを vps-config にコピーする

nginx の設定ファイルをバックアップする

nginx の本体設定ファイルとサイト設定ファイルをコピーします。

/etc/ 以下のファイルは管理者権限が必要なため、コマンドの先頭に sudo をつけて実行します。
sudo は「管理者として実行する」という意味です。
実行時にパスワードの入力を求められたら、VPS のログインパスワードを入力してください。

sudo cp /etc/nginx/nginx.conf ~/vps-config/nginx/
sudo cp /etc/nginx/sites-available/example.com.conf ~/vps-config/nginx/

cp はファイルをコピーするコマンドです。
cp コピー元 コピー先 の形式で使います。

example.com.conf の部分は、ご自身のサイト設定ファイルのファイル名に合わせてください。
/etc/nginx/sites-available/ の中を確認するには以下のコマンドを使います。

ls /etc/nginx/sites-available/

fail2ban の設定ファイルをバックアップする

fail2ban では、jail.local とカスタムフィルターをコピーします。

sudo cp /etc/fail2ban/jail.local ~/vps-config/fail2ban/

# 自分で作成したカスタムフィルターをコピーします（ファイル名は環境によって異なります）
sudo cp /etc/fail2ban/filter.d/カスタムフィルター名.conf ~/vps-config/fail2ban/filter.d/

筆者の環境では、WordPress 攻撃の検知用・レートリミット超過の検知用・ボットスキャンの検知用として3つのカスタムフィルターを作成しています。
ご自身の環境で作成したカスタムフィルターをすべてコピーしてください。

jail.local について補足します。

fail2ban をインストールすると jail.conf というファイルが自動配置されます。
このファイルを直接編集するのではなく、jail.local という別ファイルを自分で作成して設定を上書きするのが推奨される方法です。
このブログの fail2ban 設定記事でこのファイルを作成した方は、必ずバックアップ対象に含めてください。

filter.d/ の中にあるファイルのうち、自分で作成したカスタムフィルターだけをコピーします。
パッケージが自動配置したファイルは対象外です。
どれが自分で作成したものか不明な場合は、ファイルの中身を cat コマンドで確認してください。

cat /etc/fail2ban/filter.d/ファイル名.conf

自作のフィルターには、自分が書いた正規表現（failregex）が含まれているはずです。
一方、パッケージが自動配置したファイルの末尾には # Author: という署名行が含まれていることが多く、見分ける目安になります。

SSH・PHP・logwatch の設定ファイルをバックアップする

筆者の環境では以下の設定ファイルもカスタマイズしているため対象にしています。

sudo cp /etc/ssh/sshd_config ~/vps-config/ssh/
sudo cp /etc/php/8.3/fpm/php.ini ~/vps-config/php/
sudo cp /etc/php/8.3/fpm/pool.d/www.conf ~/vps-config/php/
sudo cp /etc/logwatch/conf/logwatch.conf ~/vps-config/logwatch/

それぞれ以下のような変更を加えています。

• sshd_config：SSH のポート番号変更、パスワード認証の無効化などのセキュリティ設定
• php.ini：WordPress のメディアファイル用にアップロードサイズの上限を変更
• www.conf：PHP-FPM のワーカープロセス設定
• logwatch.conf：レポートのメール送信先、形式、対象期間などの設定

PHP のカスタム設定を確認する方法

WordPress を運営している場合、アップロードサイズをデフォルトから変更している可能性が高いです。
以下のコマンドで確認できます。

php -i | grep -E "upload_max|post_max|memory_limit"

デフォルト値は upload_max_filesize = 2M・post_max_size = 8M です。
これから変更されている場合はバックアップをお勧めします。

ご自身の環境でカスタマイズしていないものは、対象から除いて構いません。

UFW のファイアウォールルールをバックアップする

UFW は設定ファイルを直接コピーするのではなく、現在のルール一覧をコマンドで出力してテキストファイルとして保存します。

sudo ufw status numbered > ~/vps-config/ufw/rules.txt

ufw status numbered は UFW のファイアウォールルールを番号付きで表示するコマンドです。
> はコマンドの出力結果をファイルに書き込む記号（リダイレクト）です。

UFW のルールは内部的に複数のファイルに分散して保存されており、直接コピーしても復元に使えません。
そのため、現在の状態を読めるテキスト形式で保存しておきます。

VPS を再構築した場合の UFW の復元方法

rules.txt を開いて、表示されているルールを以下のようなコマンドで1行ずつ再実行します。

# 例：SSH ポートを許可する場合
sudo ufw allow 22/tcp

# 例：特定の IP アドレスを拒否する場合
sudo ufw deny from 192.0.2.1

# 設定が完了したら UFW を有効化する
sudo ufw enable

rules.txt に保存されたルール一覧を見ながら、必要なものを順に追加していきます。

PM2 の復元メモを作成する

PM2 の設定ファイルである ecosystem.config.js は ~/next-blog/ の中に置いており、ソースコードの Git リポジトリですでにバックアップされています。
そのため、ここでは重複して管理せず、VPS 再構築時の復元手順をメモとして記録するだけにします。

以下のコマンドを実行すると、メモファイルが作成されます。
cat > ファイル名 << 'EOF' から始まり EOF で終わる書き方は「ヒアドキュメント」と呼ばれ、EOF と EOF の間に書いた内容をそのままファイルに書き込むことができます。

cat > ~/vps-config/pm2/README.md << 'EOF'
# PM2 設定メモ

## 設定ファイルの場所

~/next-blog/ecosystem.config.js

## 初回起動・復元手順（VPS 再構築後など）

cd ~/next-blog
pm2 start ecosystem.config.js
pm2 save
pm2 startup

## 通常の操作コマンド

pm2 list                                        # 状態確認
pm2 restart ecosystem.config.js --update-env    # 再起動
pm2 stop next-blog                              # 停止
pm2 logs next-blog                              # ログ確認
EOF

すべてコピーできたか確認する

find ~/vps-config -type f

対象としたファイルがすべて表示されれば STEP 2 完了です。

STEP 3：GitHub にプライベートリポジトリを作成する

GitHub にログインし、以下の設定で新しいリポジトリを作成します。

項目	設定値
Repository name	vps-config
Visibility	Private（必須）
Add README	オフ
Add .gitignore	None

Visibility は必ず Private にしてください。

sshd_config には SSH のポート番号や認証設定、jail.local には fail2ban のしきい値など、セキュリティ上の設定内容が含まれています。
Public リポジトリにすると、攻撃者に VPS の防御の詳細が丸見えになります。
これだけは絶対に守ってほしい点です。

「Add README」をオフにする理由は、次の STEP で VPS 側から git init → git push する手順を使うためです。
GitHub 側に初期コミットがあると、履歴の不一致でエラーが発生します。

リポジトリを作成すると接続手順が表示されます。
画面上部の SSH タブをクリックして、以下のような形式のコマンドが表示されている状態にしてください。

git remote add origin git@github.com:ユーザー名/vps-config.git

この行をコピーしておきます。

STEP 4：Git で初期化して GitHub に初回 push する

ここからは Git のコマンドを使います。
Git の基本的な仕組みや GitHub との SSH 接続設定については、以下の記事で詳しく解説しています。
Git を初めて使う方は先にご確認ください。

【ブログカード挿入（【Next.jsブログ構築】VPS の Next.js ブログを Git と GitHub でバックアップ・バージョン管理する方法）】

VPS で以下のコマンドを順番に実行します。

① リポジトリの初期化

cd ~/vps-config && git init

git init はカレントディレクトリを Git リポジトリとして初期化するコマンドです。
実行すると .git/ という隠しフォルダが作成され、このフォルダの中に変更履歴が記録されていきます。

② デフォルトブランチを main に設定

git branch -M main

ブランチ名を main に設定します。
Git の古いバージョンではデフォルトが master になるため、GitHub の標準に合わせて変更しておきます。
-M は強制的にブランチ名を変更するオプションです。

③ GitHub リポジトリを接続

git remote add origin git@github.com:ユーザー名/vps-config.git

先ほど GitHub でコピーしたコマンドをそのまま貼り付けて実行します。
git remote add は GitHub 上のリポジトリへの接続先を登録するコマンドです。
origin はリモートリポジトリの名前（別名）で、慣習的に origin を使います。

接続を確認します。

git remote -v

origin の fetch・push に GitHub の URL が表示されれば成功です。

④ 初回コミットと push

git add .
git commit -m "初回コミット：VPS設定ファイルのバックアップ"
git push -u origin main

• git add .：カレントディレクトリ以下のすべてのファイルをステージング（コミット準備）します。. はカレントディレクトリを意味します
• git commit -m "メッセージ"：ステージングした変更を履歴として記録します
• git push -u origin main：GitHub に送信します。-u をつけることで、次回以降は git push だけで同じ場所に push できるようになります

ターミナルに、「branch ‘main’ set up to track ‘origin/main’」のようなメッセージが表示されれば成功です。

GitHub のリポジトリページを開いてフォルダが表示されていることを確認してください。
画面左上に Private バッジが表示されていることも合わせて確認します。

GitHub の vps-config リポジトリ画面。Private バッジとフォルダ一覧が表示されています。

STEP 5：設定変更のたびに自動同期するバックアップスクリプトを作る

設定ファイルを変更したときに、1コマンドで最新状態を GitHub に同期できるスクリプトを作成します。

以下のコマンドを実行してください。
cat > ~/vps-config/backup-config.sh << 'EOF' から最後の EOF までがスクリプトの内容です。

スクリプトを自分の環境に合わせて修正してください。
バックアップ対象としないカテゴリの sudo cp 行は削除します。
example.com.conf の部分は必ずご自身のサイト設定ファイル名に、カスタムフィルター名の部分もご自身の環境のファイル名に変更してください。

cat > ~/vps-config/backup-config.sh << 'EOF'
#!/bin/bash
set -e

echo "=== 設定ファイルをコピーします ==="
sudo cp /etc/nginx/nginx.conf ~/vps-config/nginx/
sudo cp /etc/nginx/sites-available/example.com.conf ~/vps-config/nginx/
sudo cp /etc/fail2ban/jail.local ~/vps-config/fail2ban/
# 自分で作成したカスタムフィルターをコピーします（ファイル名は環境によって異なります）
sudo cp /etc/fail2ban/filter.d/カスタムフィルター名.conf ~/vps-config/fail2ban/filter.d/
sudo cp /etc/ssh/sshd_config ~/vps-config/ssh/
sudo cp /etc/php/8.3/fpm/php.ini ~/vps-config/php/
sudo cp /etc/php/8.3/fpm/pool.d/www.conf ~/vps-config/php/
sudo cp /etc/logwatch/conf/logwatch.conf ~/vps-config/logwatch/
sudo ufw status numbered > ~/vps-config/ufw/rules.txt

echo "=== GitHub に push します ==="
cd ~/vps-config
git add .
git diff --cached --quiet && echo "変更なし。push をスキップします。" && exit 0
git commit -m "設定ファイルを更新：$(date '+%Y-%m-%d')"
git push

echo "=== バックアップ完了です ==="
EOF

実行権限を付与します。

chmod +x ~/vps-config/backup-config.sh

chmod +x はファイルに実行権限を付与するコマンドです。
+x は「実行可能にする」という意味で、これをしないと Permission denied エラーになります。

動作確認として実行してみます。

~/vps-config/backup-config.sh

「=== バックアップ完了です ===」と表示されれば成功です。

スクリプト自体も ~/vps-config/ の中に置いているため、この実行によってスクリプトも GitHub にバックアップされます。

スクリプト内の重要な処理の解説

set -e について

set -e

スクリプト内のいずれかのコマンドがエラーになった場合、そこで即座に処理を停止します。
これがないと、途中でエラーが起きても処理が続いてしまい、意図しない状態になる可能性があります。

変更がない場合はコミットをスキップする処理

git diff --cached --quiet && echo "変更なし。push をスキップします。" && exit 0

ステージングした内容に変更がない場合（設定ファイルの内容が前回と同じ場合）は、コミットせずにスクリプトを終了します。
変更がないのにコミットすると、意味のない履歴が積み重なってしまうためです。

git diff --cached はステージング済みの変更を確認するコマンドです。
--quiet は出力を表示せず、変更の有無だけを終了コードで返します。
&& は「前のコマンドが成功した場合のみ次を実行する」という意味です。

コミットメッセージに日付を自動で入れる処理

git commit -m "設定ファイルを更新：$(date '+%Y-%m-%d')"

$(date '+%Y-%m-%d') は実行時の日付（例：2026-05-16）に自動的に置き換えられます。
毎回手動でメッセージを入力する手間がなくなり、「いつ変更を保存したか」がひと目でわかります。

今後の運用：設定変更のたびに1コマンドで同期する

nginx の設定を変更した、fail2ban に新しいルールを追加した——そのたびに以下の1コマンドを実行するだけです。

~/vps-config/backup-config.sh

ファイルのコピー、ステージング、コミット、GitHub への push まですべて自動で完了します。
変更がなければ「変更なし」として終了するため、こまめに実行しても問題ありません。

設定ファイルを変更するときに、nginx などをリロードすることがあると思います。
リロードやリスタートとセットで、このスクリプトを実行するのを習慣にするのが良いと思います。

まとめ：VPS 設定ファイルの Git バックアップで安心できる環境を作る

今回の作業のポイントを整理します。

バックアップ対象の選び方が今回の核心です。
すべてのファイルを管理しようとすると煩雑になります。
「自分が変更を加えたカスタムファイルだけを対象にする」という考え方を持つだけで、シンプルに管理できます。

リポジトリは必ず Private にしてください。
SSH 設定や fail2ban のルールなど、セキュリティ上の情報が含まれているため、Public にするのは絶対に避けてください。

この仕組みができると、「VPS の設定ファイルを変えたらスクリプトを実行する」という習慣だけで、GitHub に最新の設定が常に保存された状態を維持できます。

ソースコードのバックアップと合わせて、VPS 全体の設定が GitHub で管理された状態になれば、万一のときも落ち着いて復元作業に取り組めます。

関連記事：Next.js ブログのソースコードを Git でバックアップする方法はこちらです。