Info2softは、ウェブサイトでより快適で適切な閲覧体験を提供するためにCookieを使用しています。 プライバシーポリシー
Loading...
By:
クラウドストレージやディスクベースのバックアップが現代のIT環境で主流となっているものの、テープは長期的なデータ保護において依然として重要なメディアです。オフラインである特性からランサムウェアに対する強固な防御を実現し、コストが低いため、MySQLの膨大なデータを数年間保持する必要がある組織に適しています。
本ガイドでは、論理バックアップと物理バックアップの2種類の手法を用いてMySQLをテープにバックアップする方法を解説します。各手法の使い分け、バックアップデータのテープへの保存手順、正常にリストア可能かどうかの検証手順についても説明します。
ディスクやクラウドストレージが現在のバックアップ戦略の主流ですが、テープは複数の独自のメリットを持つため、エンタープライズのバックアップ環境において重要な位置を占めています。
MySQLをテープにバックアップする際は、論理バックアップと物理バックアップのいずれかを選択できます。
大半の環境では、まずディスク上にバックアップを作成し、その後バックアップソフトまたは標準のテープユーティリティを使用してテープへアーカイブします。
mysqldumpはMySQL標準の論理バックアップ作成ユーティリティです。データベースのスキーマとデータをSQL文として出力し、圧縮した上でテープにアーカイブできます。
# 手順1：圧縮済み論理バックアップを作成
mysqldump ‑u root ‑p ‑‑single‑transaction ‑‑quick ‑‑all‑databases | gzip > /backup/mysql_dump.sql.gz
# 手順2：バックアップをテープにアーカイブ
tar ‑cvf /dev/st0 /backup/mysql_dump.sql.gz
‑‑single‑transactionを使用すると、テーブルをロックせずに一貫性のあるスナップショットを取得できます。ディスクの空き容量が少ない場合は、一時ファイルを作成せずバックアップを直接テープへストリーム出力できます。
mysqldump ‑u root ‑p ‑‑single‑transaction ‑‑quick ‑‑all‑databases | gzip | dd of=/dev/st0 bs=64k
適した用途
考慮事項
物理バックアップはSQL文を出力するのではなく、データベースファイルを直接コピーします。Percona XtraBackupとMySQL Enterprise BackupはInnoDBデータベースのホットバックアップに対応しており、大規模本番環境で推奨される手法です。
一般的なワークフローとして、ステージィング用ディスク上にバックアップを作成した後、テープへアーカイブします。
# 手順1：物理バックアップを作成
xtrabackup ‑‑backup ‑‑target‑dir=/backup/physical/
# 手順2：バックアップをテープにアーカイブ
tar ‑cvf /dev/st0 /backup/physical/
Percona XtraBackupはストリーミングバックアップにも対応しており、データを直接テープへ書き込むことが可能です。
xtrabackup ‑‑backup ‑‑stream=xbstream | dd of=/dev/st0 bs=64k
適した用途
考慮事項
適切なバックアップ手法は主にデータベースのサイズとリカバリ要件に依存します。下記の表を参考にしてください。
| データベースサイズ | 主な要件 | 推奨手法 |
|---|---|---|
| 小規模（50GB未満） | 可搬性と柔軟性 | mysqldump + tar |
| 中～大規模（50GB～1TB） | 高速なバックアップとリカバリ | Percona XtraBackup または MySQL Enterprise Backup + テープ |
| 超大規模（1TB超） | バックアップ時間の最小化と高速リカバリ | ストリーム出力による物理バックアップ（xbstream） |
テープにバックアップを作成するだけでは不十分です。定期的な検証とリストア試験を実施し、必要な時にMySQLバックアップを確実に復旧できることを確認してください。
リストア実行前に、テープが読み取り可能でバックアップファイルが存在することを確認します。
mt ‑f /dev/st0 rewind
tar ‑tvf /dev/st0
標準的なリストアのワークフローは以下の通りです。
mysqldumpで作成した論理バックアップの場合は、テープからSQLダンプを展開しMySQLにインポートします。
zcat /tmp/restore/mysql_dump.sql.gz | mysql ‑u root ‑p
Percona XtraBackupで作成した物理バックアップの場合は、まずバックアップを準備処理してからデータベースファイルをリストアします。
# バックアップの準備処理
xtrabackup ‑‑prepare ‑‑target‑dir=/tmp/physical_restore/
# データベースファイルをリストア
systemctl stop mysql
xtrabackup ‑‑copy‑back ‑‑target‑dir=/tmp/physical_restore/
# パーミッションを修正しMySQLを起動
chown ‑R mysql:mysql /var/lib/mysql/
systemctl start mysql
リストア完了後、基本的なクエリを実行しデータベースが利用可能でリカバリしたデータにアクセスできることを確認します。本番環境で使用する前に、必ず隔離された環境でリストア試験を実施してください。
MySQLデータベースをテープにバックアップする際には、ハードウェアアクセスのエラーからバックアップの一貫性に関する問題まで、複数の運用上の課題が発生する可能性があります。これらの一般的な問題を理解することで、より信頼性の高いバックアップ・リカバリプロセスを実現できます。
テープバックアップ実行時に/dev/st0や/dev/nst0へのアクセスで「permission denied」または「no such device」といったエラーが発生することがよくあります。
Linuxシステムでは、テープデバイスは特定のユーザーまたはグループにアクセスが制限されているのが一般的です。バックアップスクリプトが必要な権限を持たないサービスアカウントで実行されると、テープドライブへのアクセスに失敗します。
# テープデバイスの権限を確認
ls ‑l /dev/st0
# バックアップ用ユーザーをtapeグループに追加
sudo usermod ‑aG tape backupuser
権限更新後、バックアップサービスまたはユーザーセッションを再起動し変更を反映させてください。
稼働中の本番データベースに対しmysqldumpを使用すると、バックアップ実行時にテーブルロックが発生しパフォーマンス上の問題を引き起こす場合があります。これはMyISAMなどトランザクション非対応ストレージエンジンのテーブルで特に顕著です。
InnoDBテーブルについては‑‑single‑transactionオプションにより、テーブルをロックせずに一貫性のあるバックアップを作成できます。ただし、トランザクション非対応テーブルに対するロック要件は回避できません。
mysqldump ‑u root ‑p ‑‑single‑transaction ‑‑quick ‑‑all‑databases > backup.sql
大規模本番環境では、プライマリデータベースへの影響を抑えるため、読み取りレプリカに対して論理バックアップを実行することを検討してください。
Percona XtraBackupで作成した物理バックアップをリストアする際、メモリ不足またはバックアップファイルの不完全さによりxtrabackup ‑‑prepareフェーズが失敗する場合があります。
大規模データベースの場合は、リソース枯渇を回避するため準備処理時のメモリ使用量を制限してください。
xtrabackup ‑‑prepare ‑‑use‑memory=2G ‑‑target‑dir=/tmp/physical_restore/
バックアップをテープへ保存する前に、元のバックアップジョブが正常に完了し、バックアップファイルが完全かつ一貫性を持っていることを必ず確認してください。
mysqldumpまたはXtraBackupのジョブを手動でスクリプト化しテープへ転送することは可能ですが、スケジューリング、検証、保持期間管理の全ての負担がDBAにかかります。
i2Backupはテープを保存先として利用しつつ、こうした手作業の大半を解消します。
MySQLのテープバックアップに関連するi2Backupの主な機能：
i2Backupを使用してMySQLをテープにバックアップする手順は以下の通りです。
手順1. i2Backupプラットフォームにログインし、ストレージユニットにテープライブラリがバックアップ先として登録済みであることを確認します。
手順2. MySQLデータベースとホストノードがクライアントとしてプラットフォームに登録されていることを確認し、新しいバックアップルールを作成します。
手順3. バックアップ種別としてMySQLを選択し、次へをクリックします。
手順4. MySQLデータベースに対応するクライアントを選択し、バックアップ先としてテープライブラリを選択しテーププールを指定します。次へをクリックします。
手順5. バックアップ対象のデータベースインスタンスを選択します。
手順6. バックアップ種別（フルバックアップまたは増分バックアップ）を選択し、バックアップルールの時間枠と実行頻度を設定します。即時実行の1回限りタスクとして実行することも可能です。
手順7. 全設定を確認し確定をクリックしバックアップルールを登録します。
登録後、バックアップタスクダッシュボードから進捗を監視できます。タスク詳細を開くと転送速度、タスクログ、関連するクライアントとストレージユニット、エラーの有無を確認可能です。タスク完了後、バックアップとリストアからバックアップセットを参照し、ストレージユニット種別がテープライブラリと表示されていることを確認し、テープへの書き込みが正常に完了したことを検証します。
mysqldumpスクリプト、cronジョブ、手動によるテープ検証の組み合わせによる運用から脱却したいチームにとって、i2Backupは処理を単一のスケジュール管理・監査可能なワークフローに統合します。60日間の無料トライアルを申し込み、実際のMySQLバックアップ要件に合わせて動作を試すことができます。
Info2softは幅広いデータ保護ニーズに対応する関連ソリューションも提供しています。定期的なバックアップよりもゼロに近いRPOが必要な場合は、i2CDPが変更データをバイト単位でリアルタイムにレプリケートします。MySQLを他のデータベースやプラットフォームへレプリケーションする企業向けには、i2Streamがリアルタイムデータベースレプリケーションと移行に対応します。
テープは特に長期保持とエアギャップによるランサムウェア対策の観点から、MySQLのバックアップ戦略において依然として有用です。論理バックアップにmysqldumpを使用するか、物理バックアップにXtraBackupを使用するかは、データベースのサイズ、RTO/RPO要件、必要なリストア速度に依存します。
どの手法を選択した場合でも、テープバックアップを定期的に検証し、本番で必要になる前にリストア試験を実施してください。手作業を削減したいチームに対し、Info2softはスケジューリング、保持期間管理、テープ対応を一つのワークフローに自動化するバックアップソリューションを提供しています。
