A page that shows how to keep an AlmaLinux server safe and healthy by updating it regularly and avoiding common problems.
AlmaLinuxのサーバーが安全に動き続けるよう、攻撃や不具合を防ぐためのアップデート手順と考え方をまとめたページ
サーバーを運用していると、必ず向き合うことになるのが「アップデート」です。
でも多くの初心者がこう思います。
結論から言うと、アップデートはサーバーの安全と安定のために絶対必要です。
むしろ、アップデートを止めてしまうことの方が危険です。
攻撃者は常に、世界中のサーバーの “弱い部分（脆弱性）” を探しています。
古いソフトや古いカーネルは、既に見つかっている弱点が放置されている状態。
そこを狙われれば、パスワードの漏洩、データ消失、乗っ取り、改ざんなど、最悪の未来が待っています。
つまりアップデートは、
という、サーバー運用の「最優先タスク」のひとつです。
Linuxと一口に言っても、系統によって操作が違います。
Ubuntu や Debian では apt を使いますが、AlmaLinux は dnf（旧来はyum）を使います。
ここでは、怖くない、安全なアップデート方法だけを扱います。
Git Bash
sudo dnf upgrade -ysudodnfupgrade-yこの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
sudo needs-restarting -r「再起動が必要」と表示されたら reboot を実施しましょう。
多くの初心者は「アップデートしたら壊れるのでは？」という不安を抱えます。
実際、可能性ゼロではありませんが、アップデートしないほうが圧倒的に危険です。
理由は３つあります。
ごくまれにあります。
ただし、そのほとんどに共通しているのは
というケースです。
つまり、
check-update で内容を確認するこのあたりを守っていれば、「アップデートが原因で壊れる確率」は限りなく低いです。
何よりも危険なのは、「怖いから放置する」ことです。
実運用では、こまめに手動で実行してもいいですが、一定の規模になったら 自動アップデート という手段もあります。
ただし、自動更新は便利な一方で、
というリスクもあります。
そのため、
という条件なら便利です。
重要サービスの場合は「手動で様子を見ながら」が安心です。
必須ではありませんが、万が一のトラブルを早く見つけるために
Git Bash
systemctl status
sudo dnf list installed
df -h
free -mなどで、動作確認やリソースをチェックしておくと安心です。
とくに「サービスが落ちていないか」「ディスクがいっぱいになっていないか」はよく見られるポイントです。
結論から先に言うと、「最低でも月に1回」
そして、できれば 「1〜2週間に1回」 が理想です。
理由は3つあります。
つまり、初心者におすすめの運用はこうなります。
実際、サーバー会社・企業でも「定期的に更新する運用」が一般的です。
結論：
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ポイント
.bak や .old など分かる名前にしておくGit Bash
sudo cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.confGit Bash
sudo cp -r /var/www /var/www_backup-r はフォルダを丸ごとコピー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運営会社が提供している「スナップショット機能」がある場合、丸ごと元に戻せる 最強のバックアップです。
可能なら最優先で使う価値があります。
「アップデートでサーバーが壊れたらどうするの？」
初心者が一番怖いのはここですが、対処方法はちゃんとあります。
例： 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※慎重に検討してください。
重要なサービス運用中なら手動がおすすめ。
アップデートで起きがちなエラーを事前に知っておけば、焦りません。
メッセージ例：
Git Bash
Existing lock /var/run/dnf.pid原因：別のアップデートが裏で走っている
対処：
Git Bash
sudo killall dnf
sudo dnf clean all
sudo dnf upgradeGit Bash
sudo dnf distro-sync環境を正しいバージョンに揃えます。
ネットワークやDNSの問題が多いです。
Git Bash
ping 8.8.8.8
ping google.comIPが通るが名前が通らない → DNSエラー
対処：
Git Bash
sudo nano /etc/resolv.conf中に
Git Bash
nameserver 8.8.8.8を追記して保存
起動時のGRUBメニューで古いカーネルを選択できます。
どうしても起動しない場合は、スナップショットやバックアップから復元が確実です。
アップデートを怖がる必要はありません。
備えておけば、サーバー運用で最大の安心を得られます。