Yugien

A page that shows how to keep an AlmaLinux server safe and healthy by updating it regularly and avoiding common problems.

Update

AlmaLinuxのサーバーが安全に動き続けるよう、攻撃や不具合を防ぐためのアップデート手順と考え方をまとめたページ

AlmaLinuxでアップデート：怖がらず、こまめにやるのがサーバー管理の基本

サーバーを運用していると、必ず向き合うことになるのが「アップデート」です。

でも多くの初心者がこう思います。

結論から言うと、アップデートはサーバーの安全と安定のために絶対必要です。

むしろ、アップデートを止めてしまうことの方が危険です。

攻撃者は常に、世界中のサーバーの “弱い部分（脆弱性）” を探しています。

古いソフトや古いカーネルは、既に見つかっている弱点が放置されている状態。

そこを狙われれば、パスワードの漏洩、データ消失、乗っ取り、改ざんなど、最悪の未来が待っています。

つまりアップデートは、

という、サーバー運用の「最優先タスク」のひとつです。

Ubuntu と違って、AlmaLinuxは「dnf」でアップデートする

Linuxと一口に言っても、系統によって操作が違います。

Ubuntu や Debian では apt を使いますが、AlmaLinux は dnf（旧来はyum）を使います。

ここでは、怖くない、安全なアップデート方法だけを扱います。

基本のアップデート（初心者でもそのまま使える）

Git Bash

sudo dnf upgrade -y
sudo
管理者として実行
dnf
AlmaLinuxで使うパッケージ管理ツール
upgrade
パッケージをまとめて最新へ
-y
途中で「OK？」と聞かれても自動で YES を答えてくれる

この1行で、大多数のアップデートが完了します。

もし「内容を確認してから進めたい」という場合は、こちらでも大丈夫です。

Git Bash

sudo dnf check-update
sudo dnf upgrade

-y を付けないので、途中で更新内容をしっかり確認できます。

安全性は変わりません。落ち着いて進めればOKです。

不要になったパッケージを掃除したいとき

長く使っていると、依存関係で入ったパッケージが残り、ディスクを圧迫したり、管理が複雑になったりします。

Git Bash

sudo dnf autoremove -y

「消しても問題ないものだけ」が削除されるため、基本的に壊れる心配はありません。

※ただし、削除候補に不安がある場合は -y を付けず確認しましょう。

再起動が必要なとき

アップデートの中には、サーバーの“心臓部”であるカーネルの更新が含まれる場合があります。

そのときは再起動しないと変更が反映されません。

Git Bash

sudo reboot

再起動が必要かどうかは、「いま動いているカーネル」と「インストール済みの最新カーネル」が同じかで判断できます。

まず、いま動いているカーネル（＝起動中のカーネル）を確認します。

Git Bash

uname -r

次に、インストール済みカーネルの中で「いちばん新しいもの」を確認します。

Git Bash

rpm -q kernel --last | head

ここで出てくる先頭（いちばん上）のカーネルと、uname -r の結果が同じなら、いまのところ再起動は急がなくてOKです。

逆に、違っていたら「新しいカーネルは入ったけど、まだそれで起動していない状態」なので、都合のいいタイミングで再起動しましょう。

Git Bash

sudo reboot

※カーネルは起動時に読み込まれるため、更新しても再起動しない限り切り替わりません。

なぜアップデートが必要なのか？（ここを理解すると怖くなくなる）

多くの初心者は「アップデートしたら壊れるのでは？」という不安を抱えます。

実際、可能性ゼロではありませんが、アップデートしないほうが圧倒的に危険です。

理由は３つあります。

セキュリティの穴をふさぐ
攻撃者は、古いバージョンの弱点を知っています。
アップデートしていないサーバーは、鍵のかかっていない家のようなものです。
OSが古いと「サポートが終わる」
サポート終了後は修正パッチが来ません。
つまり、弱点が見つかっても放置されたまま。
古い環境ほど、トラブルが自己解決できない
エラーを検索しても情報が古い、環境が特殊、サポートも受けにくい。
結局、アップデートしておいた方が楽です。

逆に、アップデートで壊れることはある？

ごくまれにあります。

ただし、そのほとんどに共通しているのは

というケースです。

つまり、

このあたりを守っていれば、「アップデートが原因で壊れる確率」は限りなく低いです。

何よりも危険なのは、「怖いから放置する」ことです。

アップデートを自動化するという選択肢

実運用では、こまめに手動で実行してもいいですが、一定の規模になったら 自動アップデート という手段もあります。

ただし、自動更新は便利な一方で、

というリスクもあります。

そのため、

という条件なら便利です。

重要サービスの場合は「手動で様子を見ながら」が安心です。

アップデート後にやっておくと安心なチェック

必須ではありませんが、万が一のトラブルを早く見つけるために

Git Bash

# nginx を使っているなら（使ってないなら読み飛ばしOK）
sudo systemctl --no-pager --full status nginx

# ディスク（容量 / inode）
df -h
df -i

# メモリ
free -m

この4つで「サービスは生きているか」「ディスクは詰まっていないか（容量と inode）」「メモリは足りているか」を、数十秒で点検できます。

nginx の部分は、あなたのサーバーで動かしているサービス名に置き換えてください（例：sshd / php-fpm / mariadb など）

とくに「サービスが落ちていないか」「ディスクがいっぱいになっていないか」に加えて、inode（ファイル数の上限）が尽きていないかも、実務では頻出のチェックポイントです。

sudo systemctl --no-pager --full status nginx（サービスが生きているか）

まずは、アップデートで影響を受けやすいサービス（ここでは nginx）が、ちゃんと起動しているかを確認します。

期待される結果（表示）

表示例

Git Bash

● nginx.service - The nginx HTTP and reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: disabled)
    Drop-In: /etc/systemd/system/nginx.service.d
             └─php-fpm.conf
     Active: active (running) since Sun 2026-02-01 12:59:23 JST; 54s ago
    Process: 659 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
    Process: 667 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
    Process: 675 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
   Main PID: 686 (nginx)
      Tasks: 2 (limit: 2649)
     Memory: 488.0K (peak: 5.4M)
        CPU: 50ms
     CGroup: /system.slice/nginx.service
             ├─686 "nginx: master process /usr/sbin/nginx"
             └─687 "nginx: worker process"

結果（表示）の見方

Loaded:
enabled なら「OS起動時に自動で起動する」設定です。監視対象のサービスは、基本 enabled にしておくと事故が減ります。
Active:
active (running) が最重要です。ここが failed / inactive なら、その時点で「Webが落ちる」可能性があります。
Main PID: / Tasks:
プロセスが存在し、極端に増えていないかを見ます。ここでは Tasks: 2 なので正常に見えます。
Memory: / CPU:
「いま急増していないか」を見るための目安です。ここでは Memory: 488.0K と軽く、起動直後も落ち着いています。

注視する箇所

注意するポイント

df -h（ディスク容量が詰まっていないか）

df -h は「ディスクの空き容量」を人間が読みやすい単位（GBなど）で確認するコマンドです。

期待される結果（表示）

表示例

Git Bash

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           227M     0  227M   0% /dev/shm
tmpfs            91M  2.4M   89M   3% /run
/dev/vda2        25G  7.3G   17G  32% /
tmpfs            46M  4.0K   46M   1% /run/user/1000

結果（表示）の見方

Mounted on
どの場所の空き容量かを示します。最重要はサーバー全体の土台になる /（ルート）です。
Use%
使用率です。ここでは / が 32% なので余裕があります。
tmpfs / devtmpfs
メモリ上の一時領域です。通常は大きく埋まりませんが、ログを一時領域に吐く設計にしていると詰まることがあります（設計ミスの早期発見に役立ちます）。

注視する箇所

注意するポイント

df -i（inode 枯渇が起きていないか）

df -i は「ファイル数の上限（inode）」の使用状況を確認します。ディスク容量が空いていても、小さいファイルが大量に増えると inode が尽きて詰むことがあります。

期待される結果（表示）

表示例

Git Bash

Filesystem      Inodes  IUsed   IFree IUse% Mounted on
devtmpfs         53005    385   52620    1% /dev
tmpfs            58075      2   58073    1% /dev/shm
tmpfs           819200    592  818608    1% /run
/dev/vda2      1638400 175092 1463308   11% /
tmpfs            11615     24   11591    1% /run/user/1000

結果（表示）の見方

Inodes
そのファイルシステムが持つ inode の総数（ファイルを作れる最大枠）です。
IUsed / IFree
使っている inode と、残りの inode です。ここでは / が IUsed 175092、残り IFree 1463308 で十分余裕があります。
IUse%
inode の使用率です。ここでは / が 11% なので安全圏です。

注視する箇所

注意するポイント

free -m（メモリとスワップが枯れていないか）

free -m は、メモリ（RAM）とスワップ（Swap）の使用状況をMB単位で確認します。

期待される結果（表示）

表示例

Git Bash

              total        used        free      shared  buff/cache   available
Mem:            453         201          14           7         256         252
Swap:          2047           4        2043

結果（表示）の見方

available
実質的に「いま追加で使えるメモリ」です。ここでは 252MB あります。小さなVPSではこの値が「急に減る」ことが事故のサインになります。
buff/cache
Linuxが高速化のために使うキャッシュ領域です。ここが大きいのは普通で、必要なら自動で空きます。
Swap
メモリが足りないときの退避先です。ここでは 4MB しか使っておらず、健全に見えます。

注視する箇所

注意するポイント

運用メモ（迷ったときの判断軸）

手動でアップデートする頻度は？

結論から先に言うと、「最低でも月に1回」

そして、できれば 「1〜2週間に1回」 が理想です。

理由は3つあります。

セキュリティ更新は予告なく来るから
攻撃者は、脆弱性が見つかったソフトを優先して狙います。
古い状態で放置すると、知らないうちに危険な扉が開いたままになることがあります。
アップデート量が少ないほど安全・簡単
3ヶ月放置したアップデートと、1週間分のアップデートではリスクが全く違います。
小出しで更新していくほど、トラブルが起きにくく、作業もすぐ終わります。
エラーが出ても原因が特定しやすい
例えば1年分のアップデートを一気に適用すると、「どの更新が悪かったのか？」が分かりません。
短いスパンなら、原因の切り分けが圧倒的に楽です。

つまり、初心者におすすめの運用はこうなります。

忙しい人
月に1回チェック＆更新
少し余裕がある人
1〜2週間に1回
セキュリティを強めたい人
毎週チェック

実際、サーバー会社・企業でも「定期的に更新する運用」が一般的です。

アップデート前にバックアップは必要？

結論：
100％安全を求めるなら、バックアップは取るべきです。

ただし、多くの初心者はこう思います。

現実的な運用としては、次の考え方が安心で現実的です。

【最低限】この場合はバックアップ必須

もしサービスが止まったら困る場合、何としてもバックアップを取るべきです。

【安心ライン】一般的な運用

このレベルなら、バックアップしてから更新することをおすすめします。

アップデートで壊れる確率は低いですが、「万が一」のときに心のダメージが全く違います。

【たまにある誤解】

「アップデートしたら壊れたから、だからバックアップした方がいい」

…ではありません。

正しくは、

壊れたときに元に戻せるから、安心してアップデートできる

です。

アップデートは敵ではありません。

バックアップがあれば怖くない味方になります。

そもそも何をバックアップすればいい？

初心者はここが分からずつまずくので、明確にします。

最低限必要なのは、

これだけでも「元の状態に戻せる」確率がかなり上がります。

余裕が出てきたら

という手段もあります。

「バックアップなしでアップデート」って危険？

実は、一般的なアプリや軽い更新だけならアップデートが原因でサーバーが壊れることはほとんどありません。

しかし、

こんな時は壊れやすいです。

だからこそ

更新するほうが安全なんです。

バックアップを取る方法

アップデート前に「元に戻せる状態」を作っておけば、怖いことはありません。

ここでは、初心者でも安全にできる方法を優先して紹介します。

（基本）設定ファイルのバックアップ

設定ファイルは、壊れた時に最も復旧が大変な部分です。

そこで、変更前に必ずコピーを残します。

例：ssh設定ファイルのバックアップ

Git Bash

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

例：nginx の設定をバックアップ

Git Bash

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

ポイント

Git Bash

sudo cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf

（安全）Webサイトやアプリのバックアップ

Git Bash

sudo cp -r /var/www /var/www_backup

Git Bash

sudo tar czvf backup_$(date +%F).tar.gz /var/www

（※ backup_2025-11-05.tar.gz のように日付で保存されます）

（重要）データベースのバックアップ

Webサイトやアプリの心臓部がデータベースです。

MySQL / MariaDB のバックアップ例：

Git Bash

mysqldump -u root -p --all-databases > db_backup_$(date +%F).sql

特定のDBだけなら：

Git Bash

mysqldump -u root -p database_name > dbname_$(date +%F).sql

復元はこうです：

Git Bash

mysql -u root -p < db_backup_2025-11-05.sql

（最強）VPS全体のスナップショット

運営会社が提供している「スナップショット機能」がある場合、丸ごと元に戻せる 最強のバックアップです。

可能なら最優先で使う価値があります。

アップデートに失敗したときの復旧方法

「アップデートでサーバーが壊れたらどうするの？」

初心者が一番怖いのはここですが、対処方法はちゃんとあります。

（よくあるケース）設定が壊れた

例： nginx 更新後に起動しない

Git Bash

sudo systemctl status nginx

設定にエラーがある場合は

Git Bash

sudo nginx -t

と表示され、原因のファイルを教えてくれます。

エラー内容を直すか、バックアップに戻します。

Git Bash

sudo cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf
sudo systemctl restart nginx

（依存関係の問題）パッケージが壊れた

アップデート中にエラーが出た場合：

Git Bash

sudo dnf --refresh upgrade

または

Git Bash

sudo dnf distro-sync

これで依存関係が整うことがあります。

（最強）スナップショットから戻す

もし起動すらできないレベルで壊れた場合
→ VPS管理画面からスナップショット復元

これが最も安全で、確実です。

「アップデートは怖くない」と言い切れる理由がここです。

自動更新の設定方法

「忙しくて毎回手動でやるのは無理」

という場合に役立ちます。

ただし注意点：

そのため、小規模サイトや個人利用で特に有効です。

自動更新をインストール

Git Bash

sudo dnf install dnf-automatic -y

設定ファイルを開く：

Git Bash

sudo nano /etc/dnf/automatic.conf

以下の設定がおすすめ：

Git Bash

apply_updates = yes
emit_via = commandline

サービスを有効化：

Git Bash

sudo systemctl enable --now dnf-automatic.timer

これで定期的に自動アップデートが実行されます。

自動再起動まで行いたい場合

自動再起動はリスクもあるため、

方法例（cronなどで再起動を仕込む）：

Git Bash

sudo crontab -e

深夜4時に再起動する場合：

Git Bash

0 4 * * * /usr/sbin/reboot

※慎重に検討してください。

重要なサービス運用中なら手動がおすすめ。

よくあるエラーと対処方法

アップデートで起きがちなエラーを事前に知っておけば、焦りません。

「Locked」エラー（別のdnfが動いている）

メッセージ例：

Git Bash

Existing lock /var/run/dnf.pid

原因：別のアップデートが裏で走っている

対処：

Git Bash

# まず、別の dnf が動いてないか見る
ps aux | grep -E "dnf|yum" | grep -v grep

# 動いていたら、基本は「終わるまで待つ」のが安全
# どうしても止めたいときだけ、表示された PID を指定して止める（ここは慎重に）
sudo kill <PID>

まずは“裏でアップデートが動いてないか”を確認しましょう。動いていたら、基本は終わるまで待つのが安全です。どうしても止める必要があるときだけ、PID を指定して止めます。

依存関係のエラー

Git Bash

sudo dnf distro-sync

環境を正しいバージョンに揃えます。

Cannot find repos / レポジトリエラー

ネットワークやDNSの問題が多いです。

Git Bash

ping 8.8.8.8
ping google.com

IPが通るが名前が通らない → DNSエラー

対処：

Git Bash

sudo nano /etc/resolv.conf

中に

Git Bash

nameserver 8.8.8.8

を追記して保存。

※/etc/resolv.conf は環境によっては自動管理されていて、あとで元に戻ることがあります。戻る場合は NetworkManager 側の設定が必要になります。

カーネル更新後、古いカーネルに戻したい

起動時のGRUBメニューで古いカーネルを選択できます。

どうしても起動しない場合は、スナップショットやバックアップから復元が確実です。

まとめ：アップデートは怖くない、むしろ守りの要

アップデートを怖がる必要はありません。

備えておけば、サーバー運用で最大の安心を得られます。