【Linuxの基礎知識】バックアップとリストア！スナップショット活用も紹介！

データはシステム運用において最も重要な資産の一つです。適切なバックアップとリストアの戦略がなければ、障害発生時に業務が停止し、大きな損失を招く可能性があります。

本記事では、Linux環境でのバックアップとリストアのベストプラクティスを詳しく解説し、特にスナップショットを活用した効率的なデータ保護についても紹介します。

バックアップとリストアの基本概念

システムを安定的に運用するためには、データの保護が不可欠です。予期せぬ障害や人的ミスによるデータ損失を防ぐため、適切なバックアップとリストアの仕組みを理解しておく必要があります。

本章では、バックアップの目的とリストアの要件について詳しく解説します。

バックアップの目的と重要性

バックアップとは、システムのデータや設定をコピーし、障害発生時に復旧できるようにする仕組みです。

適切なバックアップ戦略を実施することで、データ消失のリスクを最小限に抑えることができます。

用語の定義

バックアップや復旧の手順を正確に理解するためには、用語の解釈に揺らぎがあると誤解が生じやすくなります。

そこで、この記事内では「バックアップ」「リストア」「リカバリ」「アーカイブ」という用語の意味をあらかじめ定義しておき、どの操作がどの工程を指すのかを統一して扱うようにします。

No.	用語	説明
1.	バックアップ	システム領域やデータを全部または部分的に保管領域へ保存する
2.	リストア	取得しておいたバックアップから、データ領域とシステム領域を復旧する
3.	リカバリ	データをリストアした後、さらに更新データの再適用を行うことで復旧する
4.	アーカイブ	バックアップデータを一まとめにして保管する

データ損失のリスク

• ハードウェア障害（HDDの故障、SSDの劣化など）
• ソフトウェアのバグやウイルス感染
• 人的ミスによるデータ削除
• サイバー攻撃（ランサムウェアなど）
• 自然災害（地震、火災、洪水など）

システム障害や人的ミスの影響

システム障害や誤操作によりデータを失うと、以下のような影響を受けます。

• 業務の停止や遅延
• 顧客データの喪失による信頼低下
• 法的問題（個人情報漏洩のリスク）
• システム復旧にかかるコストと時間の増大

バックアップが必要な主なケース

バックアップが必要になる具体的な状況を以下に示します。

ケース	具体例
ハードウェア故障	サーバーのHDDが故障し、データが読み取れなくなった
誤操作	管理者が重要なファイルを誤って削除した
システムアップデート	ソフトウェアアップデート後にデータベースが破損した
サイバー攻撃	ランサムウェアに感染し、データが暗号化された

バックアップイメージ（サンプル例）

バックアップの流れを具体的にイメージできるように、以下にサンプル例の図を用意しました。実際の運用イメージをつかむ参考にしてください。

No.	処理	補足
①	0:00に正ボリュームを副ボリューム（1次保管領域）へバックアップ	-
②	3:00に①のバックアップ以降の更新データを1次保管領域へバックアップ	-
③	11:00に正ボリュームへ障害発生	-
④	1次保管領域の副ボリュームから正ボリュームへリストア	バックアップ取得時点まで復旧
⑤	3:00にバックアップした更新データを正ボリュームへリカバリ	3:00の状態まで復旧
⑥	現行領域の更新データ（バックアップ未取得分）のリカバリ	障害発生直前まで復旧

リストアの目的と要件

リストアとは、バックアップデータを使用してシステムやデータを元の状態に復元する作業のことです。

適切なリストアが行えなければ、せっかくバックアップを取っていても復旧が困難になります。

バックアップとリストアの違い

バックアップとリストアの主な違いを以下の表にまとめます。

項目	バックアップ	リストア
目的	データを保護し、復旧可能にする	バックアップデータを使って復元する
実施タイミング	定期的に行う（例: 毎日/毎週）	障害発生時やデータ損失時
必要なリソース	ストレージ（HDD、クラウドなど）	バックアップデータと復元環境
実行手順	データをコピーして保存	保存したデータを元の場所に戻す

迅速な復旧のための要件

データを迅速に復旧するためには、以下のポイントを押さえておく必要があります。

• 適切なバックアップ頻度:
  業務に応じてバックアップ間隔を設定する（例: データベースは1日1回、サーバー設定は週1回）
• リストア手順の明確化:
  復旧手順を事前にドキュメント化し、手順書を用意する
• リストアのテスト:
  定期的に復旧テストを実施し、正常にデータが戻せるか確認する
• リカバリータイムの短縮:
  重要データを素早くリストアできるように設計する（例: RAID構成、スナップショット活用）

データの一貫性と整合性の確保

リストア後のデータが正常に動作するためには、一貫性と整合性を確保することが重要です。

• トランザクションの整合性:
  データベースなどのシステムでは、バックアップ時にトランザクションが中断しないようにする
• チェックサムの活用:
  バックアップデータの整合性を確認するためにチェックサムを使用
• 多重バックアップ:
  同じデータを複数の方法でバックアップし、復元時のデータ破損リスクを低減

バックアップとリストアは、適切な計画と実践が求められる重要なプロセスです。

リストア・リカバリと保管領域（サンプル例）

バックアップ取得後のリストア・リカバリ時に、どのデータがどの保管領域から復旧されるのかを整理した表です。

運用時のイメージを掴む参考にしてください。

No.	中分類	小分類	バックアップ 対象サーバ	1次保管領域	2次保管領域
1	① ソフトウェア	①-1 システム領域		リストア
2		①-2 設定・構成ファイル		リストア
3		①-3 LOGデータ		リストア	リストア
4	② データベース	②-1 DBデータ		リストア
5		②-2 DBトランザクションLOG	リカバリ	リカバリ
6	③ アプリケーション出力ファイル	③-1 インターフェースデータ		リストア	リストア
7		③-2 LOGデータ		リストア	リストア
8	④ アプリケーション環境	④-1 実行モジュール		リストア
9		④-2 アプリケーションソース		リストア
10	⑤ 監査	⑤-1 監査ファイル		リストア	リストア
11	⑥ 長期保存ファイル	⑤-2 法定対応データ（長期保管）		リストア

一般的なバックアップ対象を挙げていますが、この他にも対象がある場合は、システムの特性や重要度に応じて適宜判断し、整理しておくことが大切です。

次の章では、具体的なバックアップ方法やリストア手順について詳しく解説します。

バックアップの種類と特徴

バックアップには複数の方式があり、それぞれメリット・デメリットや適用シーンが異なります。

適切なバックアップ方式を選択することで、データ保護とストレージ効率を両立させることができます。

また、バックアップデータの保存先やスケジュールを適切に設計することで、リストア時のリスクを軽減できます。

本章では、バックアップの方式、保存先、スケジュールについて詳しく解説します。

バックアップの取得単位（対象）

バックアップは「どの範囲で取得するか」という対象によって分類できます。

システム全体、特定のディスク状態、データベース、特定ファイル群など、目的や運用方針に合わせて適切な単位でバックアップを設計することが重要です。

分類	概要
システムバックアップ	OS・設定・アプリケーションを含むシステム全体をバックアップし、障害発生時に環境ごと復旧可能にする方式
スナップショット	特定時点のディスクやボリュームの状態を高速に保存する方式で、障害発生時に迅速に巻き戻し可能
データベースバックアップ	データベースの整合性を保ちつつ、データを安全にバックアップ・リカバリできる方式
ファイルバックアップ	特定のディレクトリやファイル単位でバックアップを行い、必要なデータだけを選択的に復元できる方式

バックアップの取得単位が決まれば、障害発生時のリストア方式も自ずと決まります。

どの単位でバックアップを取るかが、復旧時の具体的な手順と復旧速度を左右するポイントになります。

バックアップの取得方法（世代管理）

バックアップの方式には、大きく分けて「フルバックアップ」「差分バックアップ」「増分バックアップ」の3種類があります。

データの重要度やシステムの要件に応じて、最適な方式を選択することが重要です。

フルバックアップ

フルバックアップは、システムやデータの全体をバックアップする方式です。

すべてのデータをバックアップするため、復旧時に完全な状態へ戻すことができます。

メリット・デメリット

メリット	デメリット
復元が簡単で迅速に復旧可能	ストレージ容量を大量に消費する
データの整合性を維持しやすい	バックアップの処理時間が長い

適用ケース

• システムの初回バックアップ
• 頻繁にデータ変更が行われないサーバー
• 重要なデータを完全に保護する必要がある場合

差分バックアップ

差分バックアップは、直近のフルバックアップ以降に変更されたデータのみをバックアップする方式です。

フルバックアップと差分バックアップを組み合わせることで、ストレージ使用量を削減できます。

メリット・デメリット

メリット	デメリット
フルバックアップよりも容量を節約できる	復元時にフルバックアップと差分バックアップの両方が必要
バックアップ時間が短縮される	バックアップデータが蓄積するとサイズが大きくなりがち

具体的な運用方法

• 週1回のフルバックアップ + 毎日の差分バックアップ
• バックアップサーバーやクラウドストレージを活用
• 一定期間経過後に不要な差分バックアップを削除

増分バックアップ

増分バックアップは、直近のバックアップ（フルまたは増分）以降に変更されたデータのみをバックアップする方式です。

データ量を最小限に抑えられるため、バックアップ時間を短縮できます。

メリット・デメリット

メリット	デメリット
ストレージ使用量が最小限	復旧時に複数のバックアップデータが必要
バックアップ処理が高速	リストア手順が複雑になりやすい

差分バックアップとの違い

増分バックアップと差分バックアップの違いを以下に示します。

バックアップ方式	保存対象	復旧時の必要データ
差分バックアップ	フルバックアップ以降のすべての変更データ	フルバックアップ + 最新の差分バックアップ
増分バックアップ	直近のバックアップ以降の変更データのみ	フルバックアップ + すべての増分バックアップ

バックアップの保存先と選択肢

バックアップは対象データの特性に合わせて「ローカル領域」「1次保管領域」「2次保管領域」に分けて設計するのが一般的です。

また、バックアップデータの保存先デバイスには、主に以下の3つの選択肢があります。

それぞれの特徴を理解し、用途に応じて適切な保存先を選択しましょう。

• ローカルストレージ（HDD、SSD）：
  アクセス速度が速く、コストも低いが、ハードウェア故障のリスクがある。
• リモートストレージ（NAS、クラウド）：
  ネットワーク経由でのバックアップが可能で、データの安全性が向上する。
• テープバックアップ（長期保存向け）：
  低コストで大量のデータを長期間保存できるが、リストアに時間がかかる。

1次保管領域のバックアップ対象一覧（サンプル例）

システムに障害が発生した場合に備え、システムや重要なデータをできる限り早く復旧させることを目的とした領域です。

運用時のイメージを掴む参考にしてください。

No.	中分類	小分類	システム バックアップ	スナップ ショット	データベース バックアップ	ファイル バックアップ
1	① ソフトウェア	①-1 システム領域	⚫️
2		①-2 設定・構成ファイル	⚫️
3		①-3 LOGデータ				⚫️
4	② データベース	②-1 DBデータ		⚫️※1	⚫️※1
5		②-2 DBトランザクションLOG		⚫️※1	⚫️※1
6	③ アプリケーション出力ファイル	③-1 インターフェースデータ				⚫️
7		③-2 LOGデータ				⚫️
8	④ アプリケーション環境	④-1 実行モジュール				⚫️
9		④-2 アプリケーションソース				⚫️
10	⑤ 監査	⑤-1 監査ファイル				⚫️
11	⑥ 長期保存ファイル	⑤-2 法定対応データ（長期保管）				⚫️

2次保管領域のバックアップ対象一覧（サンプル例）

使用頻度が低いデータや、法令や規定で一定期間、保存を義務付けられたデータを保存・保管をことを目的とした領域です。

運用時のイメージを掴む参考にしてください。

No.	中分類	小分類	システム バックアップ	スナップ ショット	データベース バックアップ	ファイル バックアップ
1	① ソフトウェア	①-1 システム領域				⚫️
4	② データベース	②-1 DBデータ				⚫️
5		②-2 DBトランザクションLOG				⚫️
6	③ アプリケーション出力ファイル	③-1 インターフェースデータ				⚫️
7		③-2 LOGデータ				⚫️
10	⑤ 監査	⑤-1 監査ファイル				⚫️
11	⑥ 長期保存ファイル	⑤-2 法定対応データ（長期保管）				⚫️

バックアップスケジュールの設計

バックアップは一度設定したら終わりではなく、定期的に実施することが重要です。

以下のようなスケジュールを組むことで、最適なバックアップ体制を整えることができます。

• デイリーバックアップ：重要データを毎日バックアップし、迅速な復旧を可能にする。
• ウィークリーバックアップ：システム全体のバックアップを週に1回取得し、安定した復旧体制を確保する。
• マンスリーバックアップ：長期保存が必要なデータを月1回バックアップし、履歴を保持する。

適切なバックアップ方式とスケジュールを組み合わせることで、データの安全性を高めることができます。

次章では、具体的なバックアップ手法について解説します。

スナップショットによる高速バックアップ

バックアップの中でも「スナップショット」は、データのコピーを瞬時に作成できる手法として注目されています。

特に仮想環境や大規模システムでの利用が進んでおり、通常のバックアップよりも短時間で保存と復元が可能です。

本章では、スナップショットの基本概念やLinuxでの管理方法、復元手順について詳しく解説します。

スナップショットの基本概念

スナップショットとは、特定の時点でのデータの状態を記録し、バックアップとして利用できる技術です。

通常のバックアップと異なり、データ全体をコピーするのではなく、変更部分のみを管理するため、バックアップ時間を短縮できます。

スナップショットとは何か？

• ディスクやボリュームの状態を特定の時点で保存する機能
• 増分データのみを保存するため、ストレージの消費を抑えられる
• 復元時にはスナップショットを適用することで元の状態に戻せる

バックアップとの違い

項目	スナップショット	通常のバックアップ
保存方式	変更分のみを記録	全データをコピー
処理速度	高速（数秒〜数分）	データ量によって遅延
ストレージ消費	比較的少ない	大量の容量を必要
復元の手間	即時適用可能	リストア作業が必要

一般的な用途とメリット・デメリット

用途

• システム更新前の状態保存
• データベースの整合性確保
• 仮想マシンの即時復元

メリット・デメリット

メリット	デメリット
高速なバックアップ・リストアが可能	長期保存には不向き
ストレージの使用量が削減できる	ディスク障害には弱い（元データが破損すると無効）

スナップショットの実行イメージ

番号	処理内容	概要
①	スナップショット取得	バックアップ対象サーバの `/dev/sda2` 上の `lv_sys01` に対し、同じVG内にスナップショット `lv_snap01` を作成。ブロックアドレス管理情報のみ保持。
②	1次保管領域バックアップ	スナップショット `lv_snap01` の内容を外部ディスク（1次保管領域）の `lv_data02` へコピーし、実体データのバックアップを確保する。
③	2次保管領域バックアップ	1次保管領域のバックアップデータ `lv_data02` をバックアップサーバの `lv_data03` へコピーし、さらにRAID構成の外部ストレージへ保管することで多重保護を行う。

スナップショット運用の注意点

スナップショットは便利な機能ですが、ブロックのアドレス情報を保全しているだけで実体をコピーしているわけではありません。

元ディスクが破損すればスナップショットごと失われるため、スナップショットだけをバックアップ代わりにする運用は非常に危険です。

なお、スナップショットの作成（lv_snap 作成）自体は数秒で完了しますが、その後スナップショットから実データをバックアップ先へコピーする処理は時間がかかるため、スナップショット取得後にダラダラとバックアップ処理が開始されることになります。

この特性を理解した上で、スナップショットはあくまでバックアップ開始時点の整合性確保に使用し、実体のバックアップを別途確実に取得することが重要です。

スナップショットの最大の利点は、バックアップ対象の業務停止時間をスナップショット作成時のわずか数秒だけに抑えられることです。

その後のバックアップ処理はスナップショットから行うため、業務を止めずに安全にバックアップを取得できます。 

Linuxでのスナップショット管理

Linuxでは、さまざまなファイルシステムやストレージ管理ツールを利用してスナップショットを作成できます。

代表的なものに「LVM」「ZFS」「Btrfs」があり、それぞれの特性に応じて選択することが重要です。

LVMスナップショット

LVM（Logical Volume Manager）は、論理ボリュームのスナップショットを作成できます。

LVMのスナップショットを活用することで、システムのバックアップを高速に取得できます。

lvcreate -L 5G -s -n snap_lv /dev/vg0/original_lv

ZFSスナップショット

ZFSは、データの整合性が保証された高度なファイルシステムで、スナップショット機能が標準搭載されています。

zfs snapshot pool/dataset@snap1

Btrfsスナップショット

Btrfs（B-Tree File System）は、COW（Copy-On-Write）方式を採用し、高速なスナップショット機能を提供します。

btrfs subvolume snapshot /mnt/data /mnt/snapshot

スナップショットの復元

スナップショットを利用すれば、障害発生時に即座にデータを復元できます。

各ファイルシステムの復元手順を確認しておきましょう。

LVMスナップショットの復元

LVMのスナップショットを元の状態にマージして復元する場合、以下のコマンドを使用します。

lvconvert --merge /dev/vg0/snap_lv

ZFSスナップショットの復元

ZFSでは、取得したスナップショットを使って以前の状態にロールバックできます。

zfs rollback pool/dataset@snap1

Btrfsスナップショットの復元

Btrfsでは、スナップショットを適用してデータを元の状態に戻します。

btrfs subvolume delete /mnt/data
btrfs subvolume snapshot /mnt/snapshot /mnt/data

スナップショットを活用することで、バックアップとリストアを高速化し、障害時の復旧作業を迅速に行うことが可能です。

ただし、スナップショットはバックアップの補助的な役割として利用し、別途フルバックアップを併用することが推奨されます。

Linuxでのバックアップツールの選定

Linux環境でのバックアップにはさまざまなツールが存在し、それぞれの用途に応じて最適なものを選択することが重要です。

バックアップツールは大きく分けて「システムバックアップ」「データベースバックアップ」「クラウドバックアップ」の3つに分類できます。

本章では、代表的なツールを紹介し、その特徴や用途を詳しく解説します。

システムバックアップ向けツール

システム全体のバックアップを取る場合、ディレクトリ単位のコピーやアーカイブ作成が一般的です。

ここでは、Linuxでよく使用される3つのツール「rsync」「tar」「dd」を紹介します。

rsync

rsync は、ディレクトリやファイルをコピーする際に、差分のみを転送することで効率的にバックアップを行うツールです。

• ネットワーク経由でのバックアップが可能（SSHを使用）
• 増分バックアップに対応し、データの変更部分のみをコピー
• シンボリックリンクやパーミッション情報を保持

rsync -av /home/user/data /backup/

tar

tar は、複数のファイルを1つのアーカイブファイルにまとめるためのツールです。

圧縮オプションを付けることで、データサイズを削減できます。

• ディレクトリごとにアーカイブを作成可能
• gzip や bzip2 を利用して圧縮可能
• バックアップファイルを簡単に移動・転送できる

tar -cvzf /backup/data.tar.gz /home/user/data

dd

dd は、ディスクの内容をそのままコピーできるため、ディスクイメージの作成に適しています。

• ディスク全体やパーティション単位でバックアップ可能
• ブロック単位でのコピーを行うため、低レベルなバックアップが可能
• クローンディスクの作成にも利用可能

dd if=/dev/sda of=/backup/disk.img bs=4M

データベースのバックアップ

データベースのバックアップは、システムの重要なデータを守るために不可欠です。

特に、MySQLやPostgreSQLなどのデータベースを運用している場合は、専用のバックアップツールを使用する必要があります。

mysqldump

mysqldump は、MySQLデータベースのバックアップをテキスト形式（SQLスクリプト）で取得するツールです。

• データベース全体または特定のテーブル単位でバックアップ可能
• リストア時にSQLスクリプトを適用するだけで簡単に復旧できる
• 増分バックアップには非対応

mysqldump -u root -p mydb > backup.sql

pg_dump

pg_dump は、PostgreSQLデータベースのバックアップを作成するツールです。

MySQLのmysqldumpと同様に、SQLスクリプト形式でデータをエクスポートできます。

• データベース全体または特定のテーブルのみをバックアップ可能
• テキスト形式またはバイナリ形式でバックアップを取得できる
• オプションを使用することで、より柔軟なバックアップが可能

pg_dump -U postgres -d mydb -F c -f backup.pgdump

xtrabackup

xtrabackup は、Percona社が提供するMySQL互換のバックアップツールで、増分バックアップやオンラインバックアップが可能です。

• データベースを停止せずにバックアップを取得可能
• 増分バックアップができ、バックアップ時間を短縮できる
• InnoDBのデータに最適化されている

xtrabackup --backup --target-dir=/backup/

クラウドバックアップツール

クラウドストレージを利用したバックアップを行うことで、ローカルのストレージ障害に備えることができます。

Linux環境でよく使用されるクラウドバックアップツールを紹介します。

rclone

rclone は、Google Drive、AWS S3、Dropbox などのクラウドストレージと連携できるツールです。

• さまざまなクラウドストレージと接続可能
• ファイルの同期やバックアップが簡単に実施できる
• スケジュール設定を組み合わせることで自動化が可能

rclone copy /backup remote:backup

Duplicity

Duplicity は、暗号化対応のバックアップツールで、リモートサーバーへデータを安全に送信できます。

• SSH、FTP、S3などの複数のプロトコルをサポート
• 増分バックアップが可能で、効率的にデータを保存できる
• GnuPGを使用した暗号化が可能

duplicity /backup scp://user@server.com/backup

Bacula

Bacula は、企業向けの高機能なバックアップツールで、複数のサーバーやクライアントを管理できます。

• 大規模システム向けのバックアップ・リストアソリューション
• ジョブスケジューリングが可能で、自動バックアップを設定できる
• 多様なストレージ（ローカル・リモート・テープ）に対応

Linuxのバックアップツールは用途に応じて使い分けることが重要です。

次の章では、具体的なバックアップ手順について詳しく解説します。

実践！Linuxでのバックアップ/リストア方法

Linuxでは、さまざまな方法でバックアップを実施できます。

バックアップの目的や環境に応じて、適切な手法を選択することが重要です。

本章では、Linuxの代表的なバックアップ方法である「rsync」「tar」「dd」を使用したバックアップ手順を紹介します。

tarを使ったアーカイブバックアップ

tar は、複数のファイルやディレクトリを1つのアーカイブファイルにまとめるためのツールです。

圧縮を組み合わせることで、ストレージの節約が可能になります。

tarの特徴

• バックアップデータを1つのファイルとして管理可能
• gzipやbzip2による圧縮に対応
• シンプルなコマンドでバックアップとリストアが可能

tarの基本的な使い方

以下のコマンドを実行すると、 /home/user/data の内容を圧縮したバックアップファイル /backup/data.tar.gz に保存できます。

tar -cvzf /backup/data.tar.gz /home/user/data

オプションの説明

オプション	説明
-c	アーカイブを作成
-v	詳細情報を表示
-z	gzip圧縮を適用
-f	出力先のファイル名を指定

tarを使ったリストア

tar は、バックアップ時に作成したアーカイブを展開することで、簡単にデータを復元できます。

圧縮オプションを適用した場合も、適切なコマンドを使用すれば元の状態に戻せます。

tarリストアの特徴

• シンプルなコマンドでバックアップデータを復元可能
• 圧縮されたアーカイブも展開可能（gzip、bzip2対応）
• ディレクトリ構造を保持したまま復旧できる

基本的なリストア手順

以下のコマンドを実行すると、 /backup/data.tar.gz の内容をルートディレクトリ（ /）に復元できます。

tar -xvzf /backup/data.tar.gz -C /

オプションの説明

オプション	説明
-x	アーカイブを展開する
-v	処理の詳細を表示
-z	gzip圧縮を解凍
-f	復元するファイルを指定
-C /	指定したディレクトリに展開

rsyncを使ったバックアップ

rsync は、ファイルやディレクトリを効率的に同期・バックアップできるツールです。

差分のみを転送するため、ネットワーク越しのバックアップにも適しています。

rsyncの特徴

• 増分バックアップが可能（変更されたファイルのみコピー）
• ローカルおよびリモートへのバックアップに対応
• ファイルのパーミッションやシンボリックリンクを保持可能

rsyncの基本的な使い方

以下のコマンドを実行すると、 /home/user/data ディレクトリの内容を /backup/ にバックアップできます。

rsync -av /home/user/data /backup/

オプションの説明

オプション	説明
-a	アーカイブモード（パーミッションやシンボリックリンクを維持）
-v	詳細情報を表示

rsyncを使ったリストア

rsync は、バックアップデータを高速に復元できるツールで、ディレクトリやファイル単位での復元に適しています。

特に、ネットワーク経由での復旧が必要な場合に便利です。

rsyncリストアの特徴

• バックアップデータの差分を自動的に判別し、必要なデータのみ復元
• ローカルおよびリモートのリストアに対応
• パーミッションやシンボリックリンクを保持

基本的なリストア手順

以下のコマンドを実行すると、 /backup/ 内のデータを /home/user/data に復元できます。

rsync -av /backup/ /home/user/data

オプションの説明

オプション	説明
-a	アーカイブモード（パーミッション、シンボリックリンクを保持）
-v	詳細情報を表示

ddを使ったディスクイメージ作成

dd は、ディスク全体やパーティションをそのままコピーできるツールです。

低レベルなバックアップが可能で、ブート可能なディスクのクローン作成にも使用されます。

ddの特徴

• ディスクやパーティション単位でバックアップが可能
• OSが起動しなくなった場合のリカバリーに活用できる
• ブートセクタやMBR（マスターブートレコード）も含めてコピー可能

ddの基本的な使い方

以下のコマンドを実行すると、 /dev/sda ディスク全体のイメージを /backup/disk.img に作成できます。

dd if=/dev/sda of=/backup/disk.img bs=4M

オプションの説明

オプション	説明
if=/dev/sda	入力ファイル（バックアップ元）を指定
of=/backup/disk.img	出力ファイル（バックアップ先）を指定
bs=4M	ブロックサイズを4MBに設定（速度向上）

このように、Linuxでは「rsync」「tar」「dd」などのツールを使い分けることで、目的に応じたバックアップを実施できます。

dumpを使ったバックアップ/リストア

ファイルシステム全体を丸ごとバックアップ・リストアしたい場合は、dumpコマンドとrestoreコマンドを使う方法が有効です。

tarコマンドによるファイル単位のバックアップと異なり、ファイルシステムの整合性を保った状態で取得・復元できるため、障害復旧時のリストアで威力を発揮します。

ここではdumpコマンドを使ったバックアップ方法とrestoreコマンドを使ったリストア方法を具体的に紹介します。

dumpとrestoreコマンドはextファイルシステム専用のツールであり、ext2 / ext3 / ext4の環境でのみ使用可能です。他のファイルシステムを使用している場合は、そのファイルシステムに対応したバックアップツールを使用する必要があります。近年のRHEL系Linux環境ではXFSが標準ファイルシステムとして主流になっていますが、Ubuntu系や小規模環境ではext4も依然として多く利用されています。それぞれの運用方針や管理体制に合わせてファイルシステムを選択することが重要です。

dumpを使ったバックアップ

ここではdumpコマンドを使ってファイルシステム全体をバックアップする方法を紹介します。

バックアップ対象となるファイルシステムを指定し、出力ファイルとしてバックアップデータを生成します。

バックアップファイルは保管領域に保存し、障害時やリストアが必要になったときに使用します。

dump -0u -f /backup/dump_sda2_20250701.dump /dev/sda2

この例では、/dev/sda2を対象にレベル0（フルバックアップ）でdumpを行い、バックアップファイル/backup/dump_sda2_20250701.dumpとして保存しています。

-0はレベル0（フルバックアップ）、-uはバックアップ日時の更新、-fは出力先ファイルを指定するオプションです。

dumpからのリストア

システムパーティションをdump/restoreでリストアする場合は、LiveCDやrescueモードなど別環境からディスクをマウントして作業する必要があります。単純なデータ領域のリストアとは手順が異なるため注意してください。

ここではdumpコマンドで取得したバックアップファイルをrestoreコマンドでリストアする方法を紹介します。リストア先のマウントポイントに注意し、ファイルシステムがアンマウント状態であることを確認してから作業することが重要です。

cd /mnt/restorepoint
restore -rf /backup/dump_sda2_20250701.dump

この例では、/mnt/restorepointへ移動後、restoreコマンドで-dumpで取得したバックアップファイルをリストアしています。

-rはリストア実行、-fは対象のバックアップファイルを指定するオプションです。

リストア後は適宜ファイルシステムの整合性確認やパーミッション確認を行うことを推奨します。

コマンド	用途	ポイント
dump	ファイルシステム全体のバックアップ	ファイルシステムの整合性を保ったままフルバックアップが可能
restore	dumpバックアップのリストア	ファイルシステム単位での障害復旧に活用可能

dumpとrestoreによるバックアップ運用は、特にシステム全体の復旧が必要な場合やファイル単位のバックアップではカバーしきれない障害時に役立ちます。

tarバックアップやDBバックアップと併用し、障害対応計画の一つとして活用しておくことをおすすめします。

データベースのバックアップとリストア

データベースのバックアップとリストアは、システムの安定運用に不可欠なプロセスです。

本章では、MySQLとPostgreSQLのバックアップとリストアの方法を解説します。

MySQLのバックアップ

MySQLデータベースのバックアップには、 mysqldump コマンドを使用します。

SQLスクリプト形式でデータをエクスポートし、復元時に簡単に適用できます。

mysqldumpの特徴

• データベース全体または特定のテーブルをバックアップ可能
• SQLスクリプト形式で出力されるため、復元が容易
• リモートデータベースにも対応

データベース全体をバックアップ

以下のコマンドで、データベース全体をSQL形式でバックアップできます。

mysqldump -u root -p mydb > backup.sql

特定のテーブルのみをバックアップ

特定のテーブルのみをバックアップする場合は、以下のように指定します。

mysqldump -u root -p mydb users orders > backup_users_orders.sql

すべてのデータベースをバックアップ

MySQLサーバー内のすべてのデータベースをバックアップする場合、以下のコマンドを使用します。

mysqldump -u root -p --all-databases > all_databases.sql

MySQLのリストア

MySQLのデータをリストアするには、 mysql コマンドを使用します。

データベース全体をリストア

バックアップファイルを使ってデータベースを復元する場合、以下のコマンドを実行します。

mysql -u root -p mydb < backup.sql

すべてのデータベースをリストア

サーバー全体のバックアップを復元する場合、以下のコマンドを使用します。

mysql -u root -p < all_databases.sql

特定のテーブルのみをリストア

バックアップファイルから特定のテーブルをリストアするには、バックアップ時に指定したテーブルのみを含むSQLファイルを使用します。

mysql -u root -p mydb < backup_users_orders.sql

PostgreSQLのバックアップ

PostgreSQLのデータベースをバックアップするには、 pg_dump コマンドを使用します。

SQLスクリプト形式やカスタムフォーマットでバックアップ可能です。

pg_dumpの特徴

• データベースを運用中でもバックアップが可能
• SQLスクリプト形式やカスタムフォーマットで保存可能
• 特定のテーブルのみをバックアップ可能

データベース全体をバックアップ

以下のコマンドで、データベース全体をバックアップできます。

pg_dump -U postgres -d mydb -F c -f backup.pgdump

特定のテーブルのみをバックアップ

特定のテーブルのみをバックアップする場合は、 -t オプションを使用します。

pg_dump -U postgres -d mydb -t users -F c -f users_backup.pgdump

SQLスクリプト形式でバックアップ

SQLスクリプト形式でバックアップを取得する場合は、以下のように実行します。

pg_dump -U postgres -d mydb -F p -f backup.sql

PostgreSQLのリストア

PostgreSQLのデータベースをリストアするには、 pg_restore や psql を使用します。

カスタムフォーマット（-F c）でバックアップされたデータをリストア

カスタムフォーマットでバックアップされたデータをリストアするには、以下のコマンドを使用します。

pg_restore -U postgres -d mydb backup.pgdump

SQLスクリプト形式のリストア

SQLスクリプト形式（ backup.sql）でバックアップを取得した場合、以下のコマンドを使用してリストアできます。

psql -U postgres -d mydb -f backup.sql

特定のテーブルのみをリストア

バックアップファイルから特定のテーブルのみをリストアする場合は、 -t オプションを使用します。

pg_restore -U postgres -d mydb -t users backup.pgdump

リストア前の注意点

• 既存のデータベースにリストアする場合、事前にデータを削除する必要がある
• リストア時にデータの整合性を確認するため、 CHECK TABLE や ANALYZE を実行
• リストア後に REINDEX を実行し、インデックスの最適化を行う

このように、MySQLとPostgreSQLのバックアップとリストアには、それぞれ適切なツールと手順を理解し、運用に合わせて活用することが重要です。

バックアップとリストアの自動化

バックアップ作業を手動で行うのは手間がかかり、人的ミスのリスクもあります。

そのため、定期的に自動でバックアップを実行する仕組みを導入することが推奨されます。

本章では、Linuxでのバックアップとリストアを自動化する方法として、「cron」と「シェルスクリプト」を活用する方法を解説します。

cronを活用した定期バックアップ

cron は、Linuxのスケジューリング機能で、定期的にコマンドを実行できる仕組みです。

これを活用することで、指定した時間に自動でバックアップを実行することができます。

cronの特徴

• 指定した日時に自動的にコマンドを実行可能
• バックアップの実行忘れを防止できる
• シンプルな構文で設定が可能

cronの基本的な使い方

以下のコマンドを使用して、cronジョブの設定を編集できます。

crontab -e

例えば、毎日午前3時に /home/user/data を圧縮して /backup/ に保存する場合、以下の設定を追加します。

0 3 * * * tar -czf /backup/data_$(date +\%F).tar.gz /home/user/data

cronのスケジュール設定

cronのスケジュール設定は、以下のようなフォーマットで指定します。

フィールド	意味	指定可能な値
分	何分に実行するか	0-59
時	何時に実行するか	0-23
日	何日に実行するか	1-31
月	何月に実行するか	1-12
曜日	何曜日に実行するか	0-6 (日曜=0, 土曜=6)

cronの活用例

• 毎日午前3時にバックアップを実行

  0 3 * * * tar -czf /backup/data_$(date +\%F).tar.gz /home/user/data

• 毎週日曜日の深夜2時にバックアップを実行

  0 2 * * 0 tar -czf /backup/data_weekly.tar.gz /home/user/data

• 毎月1日の午前4時にバックアップを実行

  0 4 1 * * tar -czf /backup/data_monthly.tar.gz /home/user/data

シェルスクリプトでの自動化

cronと組み合わせて、より高度なバックアップ処理を行う場合は、シェルスクリプトを活用するのが有効です。

スクリプトを使うことで、エラーハンドリングやログ出力などの処理も自動化できます。

バックアップスクリプトの作成

以下のようなシェルスクリプトを作成し、バックアップ処理を自動化できます。

#!/bin/bash
BACKUP_DIR="/backup"
SOURCE_DIR="/home/user/data"
DATE=$(date +\%F)
LOG_FILE="/var/log/backup.log"

# バックアップ処理
tar -czf ${BACKUP_DIR}/data_${DATE}.tar.gz ${SOURCE_DIR} 2>> ${LOG_FILE}

# バックアップの成否を記録
if [ $? -eq 0 ]; then
echo "[$(date)] Backup successful: ${BACKUP_DIR}/data_${DATE}.tar.gz" >> ${LOG_FILE}
else
echo "[$(date)] Backup failed!" >> ${LOG_FILE}
fi

スクリプトの実行権限を設定

作成したスクリプトに実行権限を付与します。

chmod +x /usr/local/bin/backup.sh

スケジューリングの設定方法

このスクリプトをcronで定期実行する場合、以下のように設定します。

0 3 * * * /usr/local/bin/backup.sh

スクリプトを活用するメリット

• エラーハンドリングが可能（ログを記録して問題を特定）
• バックアップ前後の処理を追加できる（通知、古いデータの削除など）
• 複数のバックアップ方法を統合して管理しやすくできる

このように、cronやシェルスクリプトを活用することで、バックアップ作業を完全に自動化し、人的ミスを防ぐことができます。

次章では、バックアップとリストアのトラブルシューティングについて解説します。

トラブルシューティングとベストプラクティス

バックアップとリストアには、さまざまなトラブルが発生する可能性があります。

ここでは、よくある問題とその解決策を整理し、安定した運用を実現するためのベストプラクティスを紹介します。

バックアップに失敗する原因と対策

バックアップが失敗する主な原因は以下の3つです。それぞれの詳細と対策を見ていきましょう。

権限不足

バックアップ対象のディレクトリやファイルに適切なアクセス権限がない場合、バックアップ処理が正常に実行されません。

• sudo を使用して管理者権限で実行する
• バックアップ対象のディレクトリやファイルの権限を確認する
• chown や chmod を活用して適切なアクセス権限を付与

ストレージ容量不足

バックアップの保存先に十分な空き容量がないと、処理が途中で失敗します。

• バックアップ対象のサイズを事前に確認
• 不要な古いバックアップファイルを定期的に削除
• 圧縮形式（gzip、bzip2）を利用してバックアップファイルのサイズを削減
• クラウドストレージや外部ストレージを活用

ネットワーク障害

リモートストレージへのバックアップ時に通信が途切れると、バックアップが失敗する可能性があります。

• ネットワークの接続状態を確認（ ping や traceroute を活用）
• 安定した通信環境（有線接続など）を確保
• バックアップのリトライ機能を活用（rsyncの --partialオプションなど）
• クラウドストレージ側のAPI制限（レートリミット）を確認

リストア時のよくある問題と解決策

リストアの際にも、データの整合性やバージョン管理の問題が発生することがあります。以下のポイントを押さえておきましょう。

データの整合性チェック

リストア後のデータが破損していないかを確認する方法を紹介します。

• チェックサムの確認: md5sum や sha256sum でバックアップ時とリストア後のデータが一致するか確認
• tarの検証機能: tar -tvf backup.tar.gz を使用し、バックアップファイルの整合性をチェック
• rsyncの検証機能: rsync -c を利用し、データの完全性を確認
• データベースの整合性チェック: MySQLでは CHECK TABLE、PostgreSQLでは pg_dump -c を活用

バックアップのバージョン管理

誤ったデータをリストアしないために、適切なバージョン管理を行いましょう。

• バックアップの世代管理: 最新のバックアップだけでなく、過去のバックアップも一定期間保持する
• バックアップの命名規則: 日付を含めたファイル名（例: backup_YYYY-MM-DD.tar.gz）を使用する
• 古いバックアップの自動削除: 定期的に古いバックアップを削除するスクリプトを設定
• Gitやバージョン管理システムの活用: 設定ファイルやスクリプトのバックアップにはGitを活用し、変更履歴を追跡

適切なトラブルシューティングとベストプラクティスを実践することで、バックアップとリストアの信頼性を向上させ、システムの安定運用を実現できます。