この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
そう思っていたサーバーが障害で落ちた時、最後にバックアップが成功していたのは2週間前だったことがあります。
この記事では、バックアップを後回しにしてきた経験から、現役講師として3,100名以上を指導してきた中で伝え続けている「バックアップの本質的な考え方」をお伝えします。rsyncの使い方を調べる前に、まず「なぜ・いつ・何を」を整理してください。
この記事のポイント
・バックアップ失敗の主因は「設定がない」より「検証していない」こと
・「何をいつまでに戻せるか」（RPO/RTO）が設計のスタート地点
・現場では「3-2-1ルール」が最低ラインとして使われている
・rsync＋cron＋月次リストアテストの3点セットが運用の基本
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
「バックアップはある」と「復元できる」は別物
SE時代の2003年頃、私が担当していたファイルサーバーで障害が起きたことがあります。その時、上司から「バックアップはどうなっている」と聞かれ、「テープバックアップを毎日取っています」と答えました。
ところがいざ復元しようとしたところ、テープが読み込めない状態になっていました。バックアップのジョブは毎日実行されていたのですが、テープが物理的に劣化していて、実際には数ヶ月分のデータが正常に書き込まれていなかったのです。
後から確認すると、ジョブのログには毎日「成功」と記録されていました。しかし実際には：
・テープドライブのヘッドが汚れており、書き込みエラーが起きていた
・エラーはジョブのリターンコードではなく、テープデバイスのエラーログに記録されていた
・そのログを誰も定期的に確認していなかった
当時の上司の言葉は今でも忘れられません。
「バックアップがあるかどうかじゃなくて、復元できるかどうかが問題だ」
その時はよく分かりませんでした。でも今は分かります。バックアップはジョブが動いているだけでは意味がない。定期的にリストアのテストをしていなければ、「バックアップがある」という事実に何の保証もないのです。
バックアップを後回しにする人の「あるある」3パターン
正直に言えば、私も昔は後回しにしていました。SE時代（2001年～2006年）に複数のサーバーを担当していた頃、バックアップはどこか「いつかやる作業」として扱っていました。現役講師として3,100名以上を指導した中でも、同じパターンを繰り返し目にしています。1. 「動いているから今は必要ない」
最も多い後回しの理由です。サーバーが正常稼働している。ログにエラーがない。「今、設定する理由がない」という判断は、一見合理的に見えます。ところが障害は「順調に見えていた」ある日突然やってきます。HDDの故障、OS破損、誤操作によるファイル削除——いずれも事前の予兆がないことがほとんどです。バックアップは「今必要か」ではなく、「障害が起きた時に必要か」で判断するものです。
2. 「設定が複雑そうだから後で学んでから」
rsyncやcronを「ちゃんと勉強してからやろう」と先送りするケースです。実際には、最低限のバックアップなら10分もあれば設定できます。完璧な設計を求めるあまり何もしない状態が続くより、シンプルでも「今すぐ動くバックアップ」を持っているほうが何十倍も価値があります。3. 「どうせ壊れないだろう」
RAID構成やクラウドサービスを「二重化されているから大丈夫」と思い込み、バックアップを取っていないケースは現場でも珍しくありません。RAIDはディスク故障から守ってくれますが、誤操作でのファイル削除・ランサムウェアによる暗号化・設定ミスによるOS破損からは守れません。バックアップとRAIDは用途が全く異なります。この違いを理解しているかどうかが、現場での事故対応力に直結します。
バックアップ設計の前に整理すべき3つの問い
1. 何を守るか
バックアップ対象を「全部」にするのは現実的ではありません。容量・コスト・時間のいずれかが必ず制約になります。現場では「失ったら業務が止まるもの」を優先して対象に含めます。・DBデータ：顧客情報・トランザクションが含まれるものは最優先
・設定ファイル：/etc配下の変更履歴が消えると再構築コストが大きい
・アプリケーションコード：Gitがあれば優先度は下げられる
・OSそのもの：構成管理ツール（Ansibleなど）があれば省略できる場合もある
判断に迷ったら「このデータが消えた時、復元にどれくらいの時間と費用がかかるか」を考えてください。コストが高いものほどバックアップの優先度は高くなります。
2. どこまで遡れる必要があるか（RPO）
「何日前のデータまで戻す必要があるか」をRPO（Recovery Point Objective）と言います。例えば「昨日のデータまで戻れればいい」なら日次バックアップで十分です。「1時間前の状態に戻したい」なら、それに合った頻度とツールが必要になります。RPOを決めずにバックアップを設計すると、後から「そんな古いバックアップしかない」という状況が発生します。
目安として：
・顧客データ・ECサイト・決済系：RPO 1時間以内
・社内ファイルサーバー・コンテンツ管理：RPO 1日以内
・開発・ステージング環境：RPO 1週間以内（許容できる場合もある）
最初にビジネス的な要件を確認するのが、現場エンジニアの正しい動き方です。
3. どれくらいで復元できる必要があるか（RTO）
「障害発生から何時間以内にサービスを再開しなければならないか」をRTO（Recovery Time Objective）と言います。RTOが短いほど、復元手順を自動化・文書化する必要が出てきます。バックアップとセットで「復元手順書」を用意しておくことが、現場での標準的な運用です。
RTOが4時間なのに実際の復元作業が8時間かかるという設計ミスは、現場でも実際に起きています。「バックアップを取る」と「復元できる」は別物という意識を常に持ってください。
現場で使われている「3-2-1ルール」
バックアップの基本として業界でよく使われる考え方が「3-2-1ルール」です。| 数字 | 意味 | 具体例 |
|---|---|---|
| 3 | データのコピーを3つ持つ | 元データ＋バックアップ2箇所 |
| 2 | 2種類の異なるメディアに保存 | ローカルHDD＋クラウドストレージ |
| 1 | 1つはオフサイト（別の場所）に置く | AWSのS3・Google Drive等 |
LinuxサーバーでS3やGoogle Driveへ定期的にバックアップを送るには、rcloneというツールが便利です。設定自体は30分もあれば完了します。
# rcloneのインストール（RHEL系） $ sudo dnf install rclone # rcloneの初期設定（インタラクティブ形式でS3やGoogle Driveを登録） $ rclone config # 設定済みリモートへバックアップを転送する例（S3の場合） $ rclone copy /backup/etc-20260515.tar.gz s3:my-backup-bucket/server01/ # cronで毎日午前3時にS3へ転送する場合 # 0 3 * * * /usr/bin/rclone copy /backup/ s3:my-backup-bucket/server01/ >> /var/log/rclone-backup.log 2>&1
Linuxバックアップで実際に使うコマンドの考え方
1. rsync ——差分同期の基本
Linuxのバックアップで最初に覚えるべきコマンドがrsyncです。# ローカルディレクトリをリモートサーバーへ同期する基本形 rsync -avz /var/www/html/ user@192.168.1.100:/backup/html/ # --deleteオプションで「削除」も同期する rsync -avz --delete /var/www/html/ user@192.168.1.100:/backup/html/ # ドライラン（実際には何もしない確認モード） rsync -avz --delete --dry-run /var/www/html/ user@192.168.1.100:/backup/html/
rsyncで同期した後、転送件数を確認する習慣もつけておくと良いでしょう。
# rsyncの転送結果をstatsで確認する $ rsync -avz --stats /var/www/html/ user@192.168.1.100:/backup/html/ ... Number of files: 1,245 (reg: 1,198, dir: 47) Number of created files: 3 Number of deleted files: 0 Number of regular files transferred: 3 Total file size: 52.43M bytes Total transferred file size: 124.5K bytes
2. tar ——アーカイブして圧縮する
ファイル数が多い場合や、完全なスナップショットを取りたい場合はtarで固めるのが有効です。# /etc配下をgzip圧縮してアーカイブ（日付付きファイル名） tar -czf /backup/etc-$(date +%Y%m%d).tar.gz /etc/ # 確認（内容一覧を表示） tar -tzf /backup/etc-20260515.tar.gz | head -20
# 実行後のファイルサイズ確認 $ ls -lh /backup/etc-20260515.tar.gz -rw-r--r-- 1 root root 2.1M May 15 08:30 /backup/etc-20260515.tar.gz # 内容の一部 $ tar -tzf /backup/etc-20260515.tar.gz | head -5 etc/ etc/hosts etc/hostname etc/resolv.conf etc/fstab
3. cronで自動化する
バックアップは手動ではなく、crontabに登録して自動実行させるのが基本です。# crontabの編集 crontab -e # 毎日午前2時に/etc配下をバックアップ（例） 0 2 * * * tar -czf /backup/etc-$(date +\%Y\%m\%d).tar.gz /etc/ >> /var/log/backup.log 2>&1
バックアップ運用中にありがちなトラブルと対処法
バックアップを設定した後も、現場では定期的にトラブルが発生します。代表的なパターンと対処法をまとめます。1. cronジョブは動いているのにバックアップファイルが空
cronのジョブは正常終了しているのに、バックアップファイルのサイズが0バイトになっているケースがあります。# バックアップファイルのサイズを確認する $ ls -lh /backup/ -rw-r--r-- 1 root root 0 May 15 02:00 etc-20260515.tar.gz # 原因の特定：cronのログを確認する $ grep CRON /var/log/syslog | tail -20 # または $ journalctl -u cron --since "1 day ago" | tail -30
2. 世代管理を入れていないとディスクが枯渇する
世代管理を設定していないと、バックアップファイルが日々蓄積してディスクがフルになります。バックアップが止まった結果、最新の状態が失われるという本末転倒な事故につながります。#!/bin/bash # 7日分だけ保持するスクリプト例 BACKUP_DIR=/backup KEEP_DAYS=7 # バックアップを作成 tar -czf ${BACKUP_DIR}/etc-$(date +%Y%m%d).tar.gz /etc/ # 7日以上古いファイルを削除 find ${BACKUP_DIR} -name "etc-*.tar.gz" -mtime +${KEEP_DAYS} -delete # ディスク使用量を確認 df -h ${BACKUP_DIR}
3. リストアしたらファイルが壊れていた
要注意なのが、バックアップファイル自体が破損しているケースです。tarアーカイブは作成時に無音で完了しても、ファイルシステムのエラーや書き込み途中でのディスクフル等で壊れることがあります。定期的にアーカイブの整合性を確認する習慣をつけてください。
# tarアーカイブの整合性チェック（-tで内容一覧が取得できれば正常） $ tar -tzf /backup/etc-20260515.tar.gz > /dev/null && echo "OK" || echo "NG: アーカイブが破損しています" OK # 実際に展開してファイルを確認する（/tmpへ展開） $ mkdir -p /tmp/restore-test $ tar -xzf /backup/etc-20260515.tar.gz -C /tmp/restore-test/ $ ls /tmp/restore-test/etc/ | head -5 adjtime aliases apache2 bash.bashrc cron.d
バックアップを「作ること」ではなく「戻せること」で評価する
受講生から「バックアップのスクリプトを書きました」と報告を受けた時、私が必ず聞くことがあります。「それで、実際にリストアのテストはしましたか？」
多くの場合、答えは「まだです」です。
バックアップスクリプトを書いた達成感で満足してしまうのは、SE時代の自分も同じでした。でも実際の障害では、スクリプトが動いているかどうかではなく、「今すぐ復元できるか」だけが問われます。
月に一度、以下の確認を習慣にするだけで現場での信頼は変わります。
・バックアップのファイルサイズが前回と大きく変わっていないか（空ファイルになっていることがある）
・cronのログにエラーが出ていないか（/var/log/backup.logなど）
・テスト環境で実際に展開して、ファイルが取り出せるか
特に3つ目のリストアテストを「やったことがない」という受講生が非常に多いです。テストは本番環境ではなく、手元の検証環境やDockerコンテナで十分です。
まとめ
| やりたいこと | コマンド・手順 |
|---|---|
| ファイルをリモートへ差分同期 | rsync -avz /src/ user@host:/dst/ |
| ディレクトリをgzip圧縮してアーカイブ | tar -czf backup-$(date +%Y%m%d).tar.gz /target/ |
| アーカイブの中身を確認 | tar -tzf backup.tar.gz |
| 毎日自動実行する | crontabに登録してログ出力付きで実行 |
| クラウドへのオフサイトバックアップ | rcloneでS3・Google Driveへ定期転送 |
| バックアップの正常確認 | ファイルサイズ確認 ＋ cronログ確認 ＋ 月次リストアテスト |
「いざとなれば戻せる」という確信を持てる状態にしておくことが、現場での冷静さにも直結します。Linuxのバックアップ設計を基礎から体系的に学びたい方は、関連記事もぜひ参照してください。
・rsyncコマンドでファイルを同期・転送する方法｜--deleteの安全な使い方やリモートバックアップも
・tarコマンドで圧縮・解凍する方法｜オプション一覧と実践的な使い方
無料の「Linuxサーバー構築入門マニュアル（図解60ページ）」をプレゼントしています。
コマンド学習の先にある「サーバーをゼロから組み立てる力」を、初心者が迷わない順序で学べる一冊です。
無料マニュアルを受け取る ＞＞
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxコマンドの出力を読み違える人が現場でよくやる3つのミス｜20年以上の指導経験から伝える「確認」の本質
- 前のページへ：Linux学習用VPS比較2026｜ConoHa・Xserver・シン・さくら・KAGOYA・WebARENA徹底検証
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます