はじめに
システム運用中、誤操作や設定ミスにより「一部のデータだけが壊れた」「マスタデータを間違えて上書きした」といったトラブルは少なくありません。
このときに全体バックアップをリストアしてしまうと、トランザクションテーブルなど正常に更新されていたデータまで巻き戻してしまう可能性があります。
この記事では、さくらのクラウドの自動バックアップ機能(アーカイブ)を活用して、必要なテーブルだけを安全に復旧する手順を紹介します。
トラブル発生ケース
環境
- さくらのクラウド上の CentOS サーバー
- MySQL / MariaDB が 稼働中
- データ登録時の不具合で、特定のマスタテーブルが誤上書きされた
- トランザクションテーブルはその後も更新が続いている(=全体リストア不可)
- 「自動バックアップ(アーカイブ)」が有効
自動バックアップ(アーカイブ)の仕組み
さくらのクラウドでは、サーバーディスクの状態を定期的にスナップショット(アーカイブ)として保存できます。
このアーカイブは「ディスク全体の状態」を保持しており、
復元や新規サーバー作成の元データとして利用可能です。
注意
アーカイブデータはさくらのストレージ上に保存されており、直接ダウンロードや参照できません。
一度別の仮想サーバーにディスクを作成してからマウントして利用します
復旧の全体フロー
- アーカイブ(バックアップデータ)を確認
- 回復用の一時仮想サーバーを作成
- SSHで接続し、対象テーブルを抽出
- 現行DBにインポート
- 一時サーバーを削除してクリーンアップ
手順詳細
Step1: バックアップを確認
Step2: 回復用サーバーの準備
3.「ディスクソース」から 「マイアーカイブ」 を選択。対象のアーカイブを指定してディスクを作成
4. root パスワードを設定し、そのほかの項目を適切に選択してから、「作成」をクリック
これでアーカイブを使用して仮想サーバーを作成できます。
ポイント:
サーバー作成後、ステータスが DOWN の場合は手動で起動してください。
Step3: 対象テーブルの抽出
SSHで一時サーバーに接続:
ssh root@[一時サーバーのグローバルIP]
※root 直接ログインが禁止されている場合、通常ユーザーでログイン後 su - でrootに切り替え。
MySQLへ接続してデータベースを確認:
SHOW DATABASES;
USE <database_name>;
SHOW TABLES;
MySQLのデータは通常 /var/lib/mysql/ に保存されています。
対象のDBディレクトリを確認して、必要なテーブルのみをSQL形式でダンプします。
cd /mnt/backup/var/lib/mysql/<database_name>/
mysqldump -u root -p <database_name> <table_name> > table_backup.sql
容量チェック(重要)
df -h
空き容量が不足している場合は、gzipで圧縮します。
gzip /tmp/table_backup.sql
完了後、SCPやFTPでローカル環境に転送します。
例:
scp root@[一時サーバーのグローバルIP]:/tmp/table_backup.sql.gz ~/Downloads/
Step4: 現行DBにインポート
抽出したSQLファイルを現行サーバーに転送し、対象テーブルを復旧します。
✅ phpMyAdminを利用する場合
GUIから直接インポート可能です。
✅ CLIを利用する場合
mysql -u root -p <database_name> < /path/to/table_backup.sql
上書き前に、現行テーブルのバックアップを必ず取得してください。
Step5:クリーンアップ
作業完了後は、一時サーバーと復旧用ディスクを削除しましょう。
- 無駄なコストを防止
- セキュリティリスクを低減
データ整合性チェック
復旧後は、以下のコマンドでデータ整合性を確認してください。
CHECK TABLE <table_name>;
SELECT COUNT(*) FROM <table_name>;
更新件数・日時などを現行データと照合すると安心です。
まとめ
さくらのクラウドのアーカイブ機能を使えば、
ディスク全体を巻き戻さずに、必要なテーブルだけを復旧できます。
部分的なデータ復旧は、
システムの整合性を保ちつつ迅速に障害対応を行うための有効な手段です。




