フルコピーとは何か:完全複製の技術・用途・メリットとリスク管理
はじめに — フルコピーの定義と位置付け
IT における「フルコピー(フルコピー)」とは、データセットの全体をそのまま別領域に複製する操作を指します。単にファイルをコピーするという意味合いだけでなく、ディスクイメージ、ストレージボリューム、データベースの物理ファイルなど、対象を丸ごと複製して元データと同一の状態を作ることを含みます。バックアップやシステム移行、検証環境の作成、災害復旧(DR)など、幅広いシナリオで利用されます。
フルコピーと差分・増分の違い
フルコピーは常に「全データ」を複製するのに対し、差分コピーは前回のフルコピーからの変更分、増分コピーは直近のコピーからの変更分のみを複製します。フルコピーは復元時に単一状態から即時復旧できる利点があり、運用が単純ですが、保存容量と転送負荷が大きくなるのが欠点です。
フルコピーの方式と技術
- ファイルレベルコピー: rsync、robocopy、cp などでファイル単位に複製。メタデータ(権限、タイムスタンプ)を維持するオプションが重要。
- ブロック/イメージレベルコピー: dd、disk imaging(Clonezilla、ntfsclone)、ストレージベンダーのクローン機能。ファイルシステムを越えた丸ごと複製が可能で、OSやブート領域も含む。
- ストレージレプリケーション/スナップショット: ストレージアレイ(SAN/NAS)や仮想化プラットフォーム(VMware、Hyper-V)が提供するコピー効率化機能。従量でコピーを高速化したり、コピー作成を一貫して実行できる。
- クラウドイメージとスナップショット: AWS AMI/EBS スナップショット、Azure Managed Disks、GCP Persistent Disk のスナップショット。クラウドでは増分方式を内部で使いつつフルコピーのように復旧できる。
- データベースの物理コピー: pg_basebackup(PostgreSQL)、Percona XtraBackup(MySQL)、物理ファイルのレベルコピー。トランザクションログ(WAL/ binlog)と組み合わせて整合性を取る必要がある。
一貫性(Consistency)の重要性
フルコピーを行う際、データの整合性が最も重要です。アプリケーション整合性(application-consistent)は、アプリケーションを一時停止またはトランザクションをフラッシュしてからコピーすることで保証されます。一方、クラッシュ整合性(crash-consistent)は単にディスクの状態をキャプチャしたもので、起動時にリカバリ処理が走ることを前提にします。データベースやトランザクションを扱うシステムでは、バックアップとログの組合せ(例えば base backup + WAL)でポイントインタイムリカバリ(PITR)を実現します。
パフォーマンス・ネットワークへの影響
フルコピーは大量データ移動を伴うため、ネットワーク帯域やストレージI/Oに大きな負荷をかけます。大容量のフルコピーを夜間バッチで行う、ネットワーク帯域を予約する、スナップショット差分を活用して初回のみフル、その後差分にする等の設計が必要です。転送時は圧縮や重複排除(deduplication)を用いることで帯域と容量を節約できますが、CPU負荷や復元時のオーバーヘッドも考慮します。
セキュリティとコンプライアンス
フルコピーは対象データを別ストアに複製するため、個人情報や機密情報が意図せず複製されるリスクがあります。暗号化(転送中/保管時)、アクセス制御、監査ログの記録、不要データの安全な消去(NIST SP 800-88 等に準拠)を必須の対策としてください。また、法規制(GDPR、国内個人情報保護法等)により複製先の国やサブプロバイダの利用可否を検討する必要があります。
コストとストレージ効率
フルコピーは容量コストが高くなります。運用では初回にフルコピーを行い、以降は差分/増分や重複排除を組み合わせるハイブリッド戦略が一般的です。クラウド環境ではスナップショットが内部で増分化されるケースが多く、ユーザ視点ではフルコピーに見えるが実際には効率化されていることがあるため、請求モデルと技術動作の把握が重要です。
検証と復元テストの必要性
「コピーできた」だけでは不十分で、復元試験を定期的に行い、実際にシステムが期待通りに起動/復旧するか検証することが必要です。チェックサム(SHA-256等)で整合性検証、自動化されたリストアジョブ、復旧時間(RTO)と復旧ポイント(RPO)の達成可否確認を行ってください。
よくある運用上の落とし穴
- メタデータ(ACLやSELinuxラベル、拡張属性)の欠落:単純なコピーコマンドでは失われる場合がある。
- スパースファイルやパイプ、デバイスファイルの扱いの違い:イメージコピーとファイルコピーで挙動が変わる。
- 一貫性の取り忘れ:オンラインのDBやアプリケーションで整合性が取れないままコピーしてしまう。
- 暗号化キーの未移行:コピー先でデータにアクセスできない事態。
- アクセス権限設計ミス:複製後に不用意に広いアクセスを許してしまう。
具体的なツールと使い分け
- 小〜中規模ファイルサーバ:rsync(--archive, --xattrs, --sparse, --delete などオプション)でファイル整合性を重視。
- ブート可能イメージ:Clonezilla、dd、disk imaging ツールで OS を含めて丸ごとコピー。
- データベース:PostgreSQL は pg_basebackup と WAL、MySQL は Percona XtraBackup や物理ファイルのコピー+binlog。
- 仮想化環境:vSphere のクローン/快照、Hyper-V のエクスポートを使用。
- クラウド:プロバイダのスナップショット/AMI(EBS スナップショット等)を利用。
ベストプラクティスチェックリスト
- 目的とRTO/RPOを明確にする(DR、移行、検証など)。
- 初期はフルコピー、以降は差分/増分やスナップショットで効率化を図る。
- アプリケーション整合性を確保(必要ならアプリケーション側でフラッシュや一時停止)。
- 転送時・保管時の暗号化、アクセス制御、ログ取得を実施。
- 復元テストと整合性チェック(チェックサム、起動検証)を定期実施。
- メタデータや特殊ファイルの扱いを確認し、ツールのオプションを検討する。
- コスト分析と保管ポリシーを定義(ライフサイクル管理、長期保管の圧縮/アーカイブ)。
まとめ
フルコピーはシンプルで確実性の高いデータ保護手段ですが、コスト、帯域、整合性、セキュリティ面での考慮が不可欠です。近年はストレージやクラウドの差分スナップショット、重複排除、圧縮技術を組み合わせることで、フルコピーのメリットを維持しつつ効率化するのが実務上の王道です。運用に際しては、目的に応じた方式選定、厳密な整合性確保、定期的な復元テストを最優先にしてください。
参考文献
- rsync - official site
- Clonezilla
- PostgreSQL: Backup and Restore
- Percona XtraBackup
- Amazon EBS スナップショット
- NIST Special Publication 800-88 Revision 1: Guidelines for Media Sanitization


