この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
そんな冷や汗をかいた経験のあるLinuxエンジニアは、決して少なくないはずです。
設定ファイルを手で書き換える作業は、Linuxサーバー運用の基本です。しかし「変更前の状態」を記録せずに編集を始めると、トラブルが起きたときに元に戻す手段がなくなります。
この記事では、20年以上Linuxサーバーを運用してきた経験から、設定ファイルを「戻せなくなった」失敗と、そこから/etcをgitで管理する習慣に変えた経緯を解説します。
この記事のポイント
・設定ファイルの「戻せない」事故はバックアップの取り方に原因がある
・/etcをgit initで管理すると変更履歴が自動で残る
・sudoでの実行と所有者の統一がgit管理を崩さないコツ
・git diffは「何を変えたか」を言語化する最速の手段になる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜ設定ファイルは「戻せない」事故を起こすのか
Linuxサーバーの設定ファイルは、たいてい1つの目的につき数行を書き換えるだけで済みます。だからこそ「バックアップを取るほどでもない」という油断が生まれます。私が現場で見てきた「戻せなくなった」事故のほとんどは、次の3パターンのどれかに当てはまります。1つ目は、そもそもバックアップを取らずに直接編集してしまうケースです。2つ目は、バックアップは取ったものの、複数回の変更で「どのバックアップが最新の正しい状態か」が分からなくなるケースです。3つ目は、バックアップファイルの命名が「httpd.conf.bak」「httpd.conf.bak2」のように場当たり的で、後から見ても差分が読み取れないケースです。
私自身、SE時代（2001年～2006年）にこの3つ目のパターンで痛い目に遭いました。その経験が、今でも受講生に「変更前の状態を、必ず言語化できる形で残しなさい」と口を酸っぱくして言い続けている理由です。
SE時代に経験した「戻せなくなった」失敗
当時、私は客先常駐でApacheサーバーの保守を任されていました。ある日、特定のディレクトリへのアクセスを制限する設定変更を頼まれ、httpd.confを直接エディタで開いて編集しました。ポイント1：バックアップは取ったが、命名が場当たり的だった
一応「まずいと困るから」という理由でコピーは取りました。しかし当時の私は次のように、思いついた順にファイルをコピーしていただけでした。# cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.bak # vi /etc/httpd/conf/httpd.conf （Directoryディレクティブを編集） :wq # cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.bak2 # vi /etc/httpd/conf/httpd.conf （さらにAllow/Denyの記述を修正） :wq
ポイント2：サービス再起動後にアクセスできなくなった
設定を反映させるためにhttpdを再起動したところ、社内の複数の担当者から「該当ページにアクセスできなくなった」という連絡が立て続けに入りました。慌てて httpd.conf.bak2 を httpd.conf に戻して再起動しましたが、症状が変わりません。次に httpd.conf.bak を戻してみても、今度は別の設定まで巻き戻ってしまい、当初依頼されたアクセス制限そのものが消えてしまいました。結局、どのバックアップが「意図した変更を含みつつ、他は壊れていない状態」なのか特定できず、Directoryディレクティブの該当箇所をもう一度ゼロから確認して手作業で組み直す羽目になりました。復旧までに要した時間は、本来5分で終わるはずの作業に対して2時間以上でした。
ポイント3：「何を変えたか」を言葉にできていなかった
この一件で私が痛感したのは、ファイルのコピーを残すこと自体は正しい習慣だったということです。問題だったのは「いつ・何を目的に・具体的にどの行を変えたか」を言語化せずに、ただファイルの実体だけを複製していたことでした。バックアップは「保険」であって、「変更履歴」ではありません。この違いに気づくまでに、私は何度も同じような冷や汗をかくことになります。/etcをgitで管理する習慣に変えた経緯
セミナー講師として独立してから、自分の検証サーバーで設定変更を繰り返すうちに、SE時代と同じ「どれが最新か分からない」状態に何度も陥りました。そこで取り入れたのが、/etc全体をgitリポジトリとして管理する方法です。やっていることは単純で、/etcディレクトリでgitリポジトリを初期化し、設定を変更するたびにコミットするだけです。実際の手順は次のとおりです（RHEL 9.4 / Ubuntu 24.04 LTSで動作確認済み）。
# cd /etc # sudo git init Initialized empty Git repository in /etc/.git/ # sudo git config user.email "admin@example.local" # sudo git config user.name "root" # sudo git add -A # sudo git commit -m "initial snapshot of /etc" [master (root-commit) 8f2a1c3] initial snapshot of /etc 342 files changed, 15823 insertions(+)
・git init：/etc配下をリポジトリ化し、全ファイルの状態を追跡対象にする
・git add -A → git commit：変更のたびに「何を・なぜ」を一言でコミットメッセージに残す
・git log --oneline：過去の変更を時系列で一覧できる（bakファイルの命名に悩む必要がなくなる）
・git diff：直前のコミットとの差分だけをピンポイントで確認できる
gitで/etcを管理していても「動かない」ことはある・ハマりやすい3つの落とし穴
git管理を始めれば万事解決、というわけではありません。私自身、導入初期に何度かつまずきました。ここでは実際に遭遇した「動かない」「エラーになる」ケースと対処法を紹介します。【重要】sudoを使わずにgit操作をして所有者が崩れる
/etc配下のファイルは基本的にroot所有です。sudoを付け忘れてgit addやgit commitを実行すると、リポジトリの管理ユーザーとファイルの実所有者がずれてしまい、後から一般ユーザーでgit statusを実行した際に権限エラーが出ます。# git status fatal: detected dubious ownership in repository at '/etc' To add an exception for this directory, call: git config --global --add safe.directory /etc
差分が思ったように表示されない
設定ファイルによっては、編集ツールが保存時に改行コードや末尾の空行を変えてしまい、意図した変更以外の差分がノイズとして混ざることがあります。この場合は `git diff --ignore-space-change` を使うと、実質的な変更点だけを確認しやすくなります。コミットを忘れて「結局同じ問題」に戻る
git管理を導入しても、コミットする習慣自体を忘れてしまえば、SE時代の私と同じ状態に逆戻りします。私は`/etc`の変更作業を「編集→動作確認→コミット」までを1セットとし、コミットするまでは次の作業に移らないというルールを自分に課すことで、この習慣を定着させました。まとめ
設定ファイルを「戻せなくなる」事故は、バックアップを取らないことよりも、変更内容を言語化せずに複製だけを繰り返すことで起きます。/etcをgitで管理する習慣は、この言語化を半ば強制的に行わせてくれる仕組みです。| やりたいこと | コマンド |
|---|---|
| /etcをリポジトリ化する | sudo git init /etc |
| 変更前の状態を記録する | sudo git add -A と sudo git commit -m "メッセージ" |
| 過去の変更履歴を確認する | sudo git log --oneline /etc |
| 直前の変更点だけを確認する | sudo git diff HEAD~1 /etc |
| 所有者ずれの警告を防ぐ | git config --global --add safe.directory /etc |
設定変更の履歴管理と合わせて、作業記録を残す習慣に関する記事や、Linuxネットワーク設定の実践解説もあわせてご覧ください。
「変更履歴を残す」が当たり前になる実力を、体系的に身につけませんか？
設定ファイルの管理は、知識の土台があってこそ活きてきます。個別のコマンドを断片的に覚えるのではなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxのシンボリックリンクを「ただのショートカット」だと思っていた日の話｜ln -sの仕組みを本当に理解するまでにあった3つの誤解
- 前のページへ：深夜の障害対応を一人で抱え込んで長引かせた経験｜現役講師が語るエスカレーションの技術
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます