5分でわかるバックアップ失敗の原因と対策【データ消失を防ぐ5つのルール】

はじめに

「バックアップは毎日動いているはず...」そう思っていたのに、実はエラーで3ヶ月前から失敗していた――。

こんな経験、ありませんか?

私はインフラエンジニア10年目で、これまで監視オペレーター、運用・保守、設計・構築と幅広い業務を経験してきました。現在はハンズオンラボの運営メンバーとして、初心者エンジニアの育成に携わっています。

この記事では、バックアップ失敗の5大原因と、それを防ぐための実践的な対策を解説します。特に、インフラエンジニア1〜2年目の方や、バックアップ運用を任されたばかりの情シス担当の方に向けて、「3-2-1ルール」などのベストプラクティスと、バックアップ確認の基本手順をお伝えします。

5分で読めて、明日からすぐに使える内容になっているので、ぜひ最後までご覧ください!

【失敗原因1】バックアップスクリプトが「実は止まっていた」問題

具体的なエピソード

ある日、サーバのメンテナンスをしていたら、バックアップログを確認する機会がありました。何気なくログファイルを開いてみると...「3ヶ月前から失敗している」という衝撃の事実が判明。

原因はスクリプトのパス指定ミスでした。cronは動いているけれど、バックアップコマンドが実行されていなかったのです。しかも、誰も気づかない。エラーメールの設定もしていなかったため、完全に放置されていました。

なぜ困ったのか

バックアップが取れていないということは、データ消失のリスクが3ヶ月間も放置されていたということです。もしこの間にサーバ障害やランサムウェア被害が発生していたら...考えるだけでゾッとします。

初心者の頃は「cronに登録したから大丈夫」と思いがちですが、スクリプトが正常に動いているかの確認を怠ると、このような事態に陥ります。

どう解決したか/どう学んだか

対策ポイント:

バックアップログの定期確認を習慣化する(週1回は最低でもチェック)
エラー通知の設定を必ず行う(メール、Slack、監視ツール連携など)
cron実行後の標準出力・標準エラー出力をログに残す

# cronでの設定例(標準出力と標準エラー出力を両方ログに記録)
0 2 * * * /path/to/backup.sh >> /var/log/backup.log 2>&1

主なオプションの意味:

>> : 標準出力をファイルに追記(上書きではなく追記モード)
2>&1 : 標準エラー出力(2)を標準出力(1)にリダイレクトし、同じログファイルに記録

【失敗原因2】ディスク容量不足でバックアップが途中停止

具体的なエピソード

バックアップが「途中まで実行されているが、完了していない」という状況に遭遇しました。調べてみると、バックアップ先のディスク容量が不足していて、途中でプロセスが停止していたのです。

しかも、古いバックアップファイルが自動削除されずに溜まり続けており、気づいたときには数ヶ月分の不完全なバックアップファイルがディスクを圧迫していました。

なぜ困ったのか

途中まで実行されたバックアップファイルは、一見正常に見えることがあります。しかし、**リストア時に「データが途中で切れている」**ことに気づき、結局使えないというケースが多発します。

また、ディスク容量不足は連鎖的に他のシステムにも影響を与えるため、早期発見が重要です。

どう解決したか/どう学んだか

対策ポイント:

バックアップ前にディスク容量をチェックするスクリプトを組み込む
世代管理を実装し、古いバックアップを自動削除する仕組みを作る
監視ツールでディスク使用率を常時監視する(閾値80%でアラートなど)

# ディスク容量チェック例(バックアップ前に実行)
DISK_USAGE=$(df -h /backup | awk 'NR==2 {print $5}' | sed 's/%//')
if [ $DISK_USAGE -ge 80 ]; then
  echo "ERROR: Disk usage is ${DISK_USAGE}%. Backup aborted."
  exit 1
fi

主なコマンド/オプションの意味:

df -h : ディスク使用状況を人間が読みやすい形式で表示
- -h : Human-readable(KB, MB, GBで表示)
awk 'NR==2 {print $5}' : 2行目の5列目(使用率)を抽出
- NR==2 : 2行目を指定(1行目はヘッダー)
- $5 : 5番目のフィールド(使用率の列)
sed 's/%//' : %記号を削除して数値のみ取得
- s/文字列/置換後/ : 文字列置換コマンド

【失敗原因3】リストアテストをしていなかった

具体的なエピソード

「バックアップは毎日取っているから大丈夫」と安心していましたが、いざという時にリストアテストをしたら、バックアップデータが壊れていて復元できないという事態に...。

原因は、バックアップ中にサーバが高負荷状態になり、データの整合性が取れていなかったことでした。バックアップコマンド自体はエラーを吐いていなかったため、気づくのが遅れました。

なぜ困ったのか

バックアップがあっても、復元できなければ意味がありません。 リストアテストをしていないと、本番障害時に「実はバックアップが使えない」という最悪の事態を招きます。

ハンズオンラボでバックアップ実習を実施した際も、参加者の多くが「リストアテストの重要性」を実感していました。

どう解決したか/どう学んだか

対策ポイント:

月1回はリストアテストを実施する(テスト環境でOK)
バックアップファイルの整合性チェックを自動化する
リストア手順書を作成し、誰でも復元できる体制を整える

# tarバックアップの整合性チェック例
tar -tzf backup.tar.gz > /dev/null
if [ $? -eq 0 ]; then
  echo "Backup file is valid."
else
  echo "ERROR: Backup file is corrupted!"
  exit 1
fi

主なコマンド/オプションの意味:

tar -tzf backup.tar.gz : tar.gzファイルの内容を一覧表示(実際に展開はしない)
- -t : アーカイブの内容を一覧表示(test/list)
- -z : gzip圧縮されたファイルを扱う
- -f : ファイル名を指定
> /dev/null : 出力を破棄(画面に表示しない)
$? : 直前のコマンドの終了ステータス(0=成功、1以上=エラー)

【失敗原因4】3-2-1ルールを知らず、同じサーバに保存していた

具体的なエピソード

バックアップをサーバの別ディレクトリに保存していたのですが、サーバ自体が故障したら意味がない...ということに、後から気づきました。

さらに、3-2-1ルール(データを3コピー、2種類のメディア、1つはオフサイト)を知らなかったため、バックアップ戦略自体が脆弱でした。

なぜ困ったのか

同じサーバ内にバックアップを保存していると、以下のリスクがあります:

サーバ障害時にバックアップも一緒に消失
ランサムウェア感染時にバックアップも暗号化される
物理的な災害(火災、水害など)で全データが失われる

どう解決したか/どう学んだか

対策ポイント:

3-2-1ルールを徹底する
- 3コピー: 本番データ + バックアップ2つ
- 2種類のメディア: 例)HDD + クラウドストレージ
- 1つはオフサイト: 別拠点やクラウドに保存
AWS Backup、Azure Backup、rsyncなどを活用してクラウドバックアップを実施
定期的にバックアップ先の接続確認を行う

# rsyncで別サーバへバックアップする例
rsync -avz --delete /var/data/ backup-server:/backup/data/

主なコマンド/オプションの意味:

rsync : 高速なファイル同期・バックアップツール
- -a : アーカイブモード(パーミッション、タイムスタンプなどを保持)
- -v : 詳細表示(Verbose)
- -z : 転送時にデータを圧縮(ネットワーク帯域節約)
- --delete : 転送元にないファイルを転送先から削除(完全同期)

【失敗原因5】世代管理をしておらず、古いバックアップが上書きされていた

具体的なエピソード

毎日バックアップを取っていたのですが、同じファイル名で上書き保存していたため、過去のバックアップが残っていませんでした。

ある日、データベースの不具合に気づいたのが1週間後だったため、「1週間前のバックアップから復元したい」と思っても、最新のバックアップ(不具合を含む)しか残っていなかったのです。

なぜ困ったのか

世代管理がないと、以下の問題が発生します:

過去の特定時点への復元ができない
データ破損やランサムウェア感染に気づくのが遅れると、正常なバックアップが残っていない
誤削除に気づいたときには、バックアップも上書きされている

どう解決したか/どう学んだか

対策ポイント:

日付や時刻をファイル名に含める
世代数を設定し、古いバックアップを自動削除する
フルバックアップと差分バックアップを組み合わせる

# 日付付きバックアップファイル名の例
DATE=$(date +%Y%m%d_%H%M%S)
tar -czf /backup/data_backup_${DATE}.tar.gz /var/data/

# 7日以上前のバックアップを削除
find /backup/ -name "data_backup_*.tar.gz" -mtime +7 -delete

主なコマンド/オプションの意味:

date +%Y%m%d_%H%M%S : 現在日時を取得(例: 20260221_143025)
- %Y : 年(4桁)
- %m : 月(2桁)
- %d : 日(2桁)
- %H : 時(24時間形式)
- %M : 分
- %S : 秒
tar -czf : tar.gz形式で圧縮アーカイブを作成
- -c : 新しいアーカイブを作成(Create)
- -z : gzip圧縮
- -f : ファイル名を指定
find /backup/ -name "data_backup_*.tar.gz" -mtime +7 -delete : 古いファイルを検索して削除
- -name "パターン" : ファイル名でフィルタ
- -mtime +7 : 7日より前に更新されたファイル(Modified time)
- -delete : 該当ファイルを削除

まとめ

バックアップ失敗の9割は、今回紹介した5つのチェックポイントで防ぐことができます。

5つのチェックポイント再掲:

✅ バックアップログの定期確認とエラー通知設定
✅ ディスク容量の監視と世代管理の実装
✅ 月1回のリストアテスト実施
✅ 3-2-1ルールの徹底(複数コピー、異なるメディア、オフサイト保管)
✅ 日付付きファイル名での世代管理

「バックアップを取っている」ことと、「バックアップが使える状態にある」ことは、まったく別物です。

特に、リストアテストをしなければバックアップの意味がないという点は、声を大にして伝えたいです。ハンズオンラボでのバックアップ実習でも、参加者の多くが「リストアの重要性」を実感し、意識が大きく変わりました。

バックアップは地味な作業ですが、データ消失のリスクから会社やプロジェクトを守る最後の砦です。ぜひ今日から、紹介した5つのルールを実践してみてください!

一緒に学びませんか?

私たちハンズオンラボでは、バックアップ運用の不安を解消し、実践的なスキルを身につけるための
もくもく会、実践型ハンズオンを定期開催しています。

✅ 完全ハンズオン形式で実際のバックアップ環境を操作できる
✅ 現役インフラエンジニアが伴走し、現場の知見を共有
✅ 初心者大歓迎で、バックアップの基礎から学べる環境

興味がある方は、ぜひ一度遊びに来てください!

📍 connpassページ: https://zeki-chan-lab.connpass.com/