MariaDBデータ復旧の鍵：Mariabackup部分バックアップの全手順

2025-05-27

Mariabackupは、MariaDBの物理バックアップツールで、Percona XtraBackupから派生したものです。データベース全体ではなく、特定のデータベースやテーブルのみをバックアップ・復元する「Partial Backup and Restore」もサポートしています。これは、大規模なデータベースの一部だけを扱いたい場合に非常に便利です。

Partial Backup（部分バックアップ）の仕組み

Mariabackupでの部分バックアップは、主にInnoDBの「Transportable Tablespaces（トランスポータブル・テーブルスペース）」機能を利用します。InnoDBは各テーブルを個別のファイル（.ibdファイル）として格納する「ファイル・パー・テーブル」モードで動作している必要があります。

部分バックアップのプロセスは以下のようになります。

バックアップの実行: mariabackup --backupコマンドに--databasesオプションを使って、バックアップしたいデータベースやテーブルを指定します。
```
mariabackup --backup \
--target-dir=/path/to/backup/dir \
--databases="database1.table1 database2" \
--user=backup_user --password=your_password
```
このコマンドは、指定されたデータベースやテーブルのデータファイル（.ibdファイル）、およびそれに関連するメタデータやログファイルなどをバックアップディレクトリにコピーします。
バックアップの準備（Prepare）: バックアップされたデータは、そのままでは整合性が取れていないため、復元可能な状態にするために--prepareオプションで準備作業を行います。部分バックアップの場合、さらに--exportオプションを追加することで、トランスポータブル・テーブルスペースに必要な.cfgファイルを生成します。
```
mariabackup --prepare --export \
--target-dir=/path/to/backup/dir
```
このステップにより、バックアップデータがクラッシュリカバリの状態になり、個々のテーブルスペースをインポートできるようになります。

Partial Restore（部分復元）の仕組み

部分復元は、フルバックアップの復元とは異なり、単純にデータディレクトリにコピーするだけではできません。これは、InnoDBのシステムテーブルスペース内のデータディクショナリには、バックアップに含まれていないデータベースやテーブルのエントリが依然として存在しているためです。そのため、個々のテーブルスペースファイルをターゲットのサーバーに手動でインポートする必要があります。

部分復元の大まかな手順は以下の通りです。

ターゲットサーバーでのスキーマの作成: 復元したいデータベースとテーブルのスキーマ（テーブル構造）を、ターゲットのMariaDBサーバー上に事前に作成しておく必要があります。データは含まれていないダミーのテーブルを作成します。これはmysqldump --no-dataコマンドなどでSQLを生成して実行するのが一般的です。
```
mysqldump -u root -p --no-data --databases database1 database2 > recreate_schemas.sql
mysql -u root -p < recreate_schemas.sql
```
テーブルスペースの破棄（Discard Tablespace）: ターゲットサーバー上の作成したテーブルに対して、既存のテーブルスペースを破棄します。これにより、テーブルと物理的な.ibdファイルとの関連付けが解除されます。
```
ALTER TABLE `database_name`.`table_name` DISCARD TABLESPACE;
```
これを復元したいすべてのテーブルに対して行います。
バックアップファイルの手動コピー: 準備済みのバックアップディレクトリから、復元したいテーブルの.ibdファイルと.cfgファイルを、ターゲットサーバーの対応するデータベースディレクトリに手動でコピーします。
```
cp /path/to/backup/dir/database_name/table_name.ibd /var/lib/mysql/database_name/
cp /path/to/backup/dir/database_name/table_name.cfg /var/lib/mysql/database_name/
```
テーブルスペースのインポート（Import Tablespace）: コピーした.ibdファイルを、ターゲットサーバー上のダミーテーブルにインポートします。これにより、テーブルとコピーした物理的な.ibdファイルが関連付けられ、データが利用可能になります。
```
ALTER TABLE `database_name`.`table_name` IMPORT TABLESPACE;
```

注意点

データディクショナリの整合性: 部分復元は、既存のデータベースに新しいデータファイルをインポートする形になるため、InnoDBのデータディクショナリの整合性を保つための注意が必要です。
複雑性: フルバックアップと比較して、部分バックアップと復元は手順が複雑であり、手動でのファイルコピーやSQLコマンドの実行が必要です。特に、多数のテーブルを扱う場合はスクリプト化を検討すると良いでしょう。
ファイル・パー・テーブル: 部分バックアップはInnoDBの「ファイル・パー・テーブル」モードに依存します。この設定が無効になっている場合、部分バックアップはできません。
バージョン互換性: MariabackupのバージョンやMariaDBのバージョンによっては、--exportオプションのサポート状況や部分バックアップ・復元の手順に違いがある場合があります。MariaDB 10.2.29以降で--exportオプションが安定して利用できるとされています。

Partial Backup and Restoreは、フルバックアップと復元に比べて手動での介入が多く、設定や手順のミスが発生しやすいです。

バックアップ時の一般的なエラー

エラーメッセージ例
FATAL ERROR: Failed to connect to MariaDB server: Access denied for user 'backup_user'@'localhost' 原因: MariabackupがMariaDBサーバーに接続するための権限が不足している。または、ユーザー名、パスワードが間違っている。 トラブルシューティング:

コマンドラインで指定しているユーザー名とパスワードが正しいか再確認します。特殊文字が含まれる場合は、適切にエスケープするか、引用符で囲む必要があります。
バックアップを実行するユーザー（例: backup_user）に、RELOAD, PROCESS, SUPER, REPLICATION CLIENT, LOCK TABLES などの必要な権限が付与されていることを確認します。
```
GRANT RELOAD, PROCESS, SUPER, REPLICATION CLIENT, LOCK TABLES ON *.* TO 'backup_user'@'localhost' IDENTIFIED BY 'your_password';
FLUSH PRIVILEGES;
```

エラーメッセージ例
[ERROR] Cannot open '/path/to/backup/dir/xtrabackup_checkpoints': No such file or directory または target directory exists and is not empty 原因: --target-dirで指定されたディレクトリが存在しないか、空ではない。 トラブルシューシューティング:

既にファイルが存在する場合は、重要データの破損を防ぐため、バックアップを実行する前にディレクトリを空にするか、別の新しいディレクトリを指定します。
--target-dirで指定したディレクトリが存在しない場合は、mkdir -p /path/to/backup/dirで作成します。

エラーメッセージ例
FATAL ERROR: Could not open tablespace file './database_name/table_name.ibd' 原因: バックアップ対象のテーブルがInnoDB file-per-tableモードで作成されていない（つまり、すべてのInnoDBデータがibdata1などの共有テーブルスペースに格納されている）。Partial Backupは、個別の.ibdファイルを持つテーブルにのみ適用できます。 トラブルシューティング:

この設定は、設定変更後に新しく作成されたテーブルにのみ適用されます。既存のテーブルを個別の.ibdファイルに移動するには、テーブルをALTER TABLE ... ENGINE=InnoDB;で再構築するか、ダンプ＆リロードする必要があります。
MariaDBの設定ファイル（my.cnfなど）でinnodb_file_per_table=ONが設定されていることを確認します。

エラーメッセージ例
FATAL ERROR: Was only able to copy log from LSN ... not ...; try increasing innodb_log_file_size 原因: InnoDBのredoログファイルが小さすぎるため、Mariabackupがすべてのトランザクションを追跡しきれない。 トラブルシューティング:

innodb_log_file_sizeを増やした後に、バックアップを再度試行します。
MariaDBの設定ファイルでinnodb_log_file_sizeの値を増やします。設定変更後はMariaDBサーバーの再起動が必要です。

エラーメッセージ例
ERROR: Option --export is not supported in this Mariabackup version 原因: 使用しているMariabackupのバージョンが--exportオプションをサポートしていない。--exportは比較的新しい機能です。 トラブルシューティング:

--exportなしでバックアップを準備し、復元時にFLUSH TABLES FOR EXPORTを使用するなどの回避策を検討します。ただし、これはより複雑な手順となります。
MariaDBのバージョンが古い可能性があります。MariaDB 10.2.29以降で--exportオプションが安定して利用できるとされています。MariaDBのバージョンアップを検討します。

復元時の一般的なエラー

エラーメッセージ例
ERROR: Tablespace is encrypted, but no encryption key was provided 原因: テーブルスペースが暗号化されているが、復元時に復号化キーが提供されていない。 トラブルシューシューティング:

バックアップ元のMariaDBサーバーで使用されていた暗号化キーを提供する必要があります。これは、通常、--innodb-encrypt-logや--innodb-encryption-key-fileなどのオプションで指定します。

エラーメッセージ例
ERROR: Tablespace for table 'database_name'.'table_name' exists, but is not in a discarded state 原因: ターゲットサーバー上でテーブルスペースをインポートする前に、対応するテーブルスペースがDISCARD TABLESPACEされていない。 トラブルシューティング:

復元対象のテーブルに対して、MariaDBクライアントからALTER TABLE database_name.table_name DISCARD TABLESPACE;を実行し、既存のテーブルスペースを破棄します。

エラーメッセージ例
ERROR: Failed to import tablespace for table 'database_name'.'table_name' 原因: * スキーマの不一致: バックアップ元のテーブルとターゲットサーバー上のダミーテーブルのスキーマ（カラム数、型、インデックスなど）が一致していない。 * ファイルコピーの失敗: .ibdファイルや.cfgファイルが正しくターゲットのデータディレクトリにコピーされていない。 * ファイル権限の問題: コピーされたファイルがmysqlユーザーとグループから読み書きできない権限になっている。 * MariaDBサーバーが起動している: IMPORT TABLESPACEを実行する際にMariaDBサーバーが起動している必要があるが、ファイルコピー中に停止していたなど。 トラブルシューティング:

IMPORT TABLESPACEコマンドを実行する前にMariaDBサーバーが起動していることを確認します。
コピーしたファイルの所有者がmysqlユーザー、グループがmysql（またはMariaDBが動作するユーザー/グループ）になっていることを確認し、必要に応じてchown -R mysql:mysql /var/lib/mysql/database_name/table_name.ibdのように権限を修正します。
バックアップされた.ibdファイルと.cfgファイルが、ターゲットサーバーの対応するデータベースディレクトリ（例: /var/lib/mysql/database_name/）に正しくコピーされていることを確認します。
mysqldump --no-dataで生成したSQLを使って、バックアップ元のテーブルスキーマと完全に一致するダミーテーブルをターゲットサーバーに作成していることを確認します。

エラーメッセージ例
復元後にMariaDBサーバーが起動しない、またはクラッシュする 原因: * システムテーブルスペースの不整合: Partial Restoreは個々のテーブルスペースを扱うため、システムテーブルスペース（ibdata1など）やInnoDBのredoログファイル（ib_logfile*）との整合性が失われることがある。 * 間違ったデータディレクトリへのコピー: バックアップされたデータファイルを誤ってMariaDBのデータディレクトリ全体に--copy-backなどで復元しようとした（Partial Restoreでは個別の.ibdファイルを手動でインポートする必要がある）。 * バージョン不一致: バックアップ元のMariaDBバージョンと復元先のMariaDBバージョンに大きな差がある。 トラブルシューティング:

innodb_force_recoveryを一時的に設定してMariaDBを起動し、問題の特定と修正を試みる場合がありますが、これはデータ破損のリスクを伴うため、注意が必要です。
復元先のMariaDBサーバーのバージョンが、バックアップ元のバージョンと互換性があることを確認します。通常、同じメジャーバージョン（例: 10.4から10.4）である必要があります。
Partial Restoreでは、--copy-backオプションは使用せず、個々の.ibdファイルを手動でインポートする手順を厳守します。

全体的なトラブルシューティングのヒント

innodb_file_per_tableの確認
この設定が常に有効になっていることを確認してください。SHOW VARIABLES LIKE 'innodb_file_per_table';で確認できます。
MariaDB Knowledge Baseの参照
MariaDBの公式ドキュメント（MariaDB Knowledge Base）は、Mariabackupに関する最も信頼性の高い情報源です。最新の情報や特定のバージョンに関する既知の問題と解決策が記載されています。
テスト環境での試行
重要な本番環境でPartial Backup and Restoreを行う前に、必ずテスト環境で手順を何度も試し、成功することを確認してください。
権限の確認
ファイルシステム上の権限（特に.ibdファイルと.cfgファイル）とMariaDBユーザーの権限は、Mariabackupの操作において非常に重要です。
詳細なログの確認
Mariabackupは詳細なログを出力します。エラーメッセージだけでなく、ログ全体を注意深く確認することで、問題の原因を特定できる場合があります。--verboseオプションを使用すると、より多くの情報が出力されます。

MariaDBのMariabackupを使った部分バックアップと復元のコード例

Mariabackupを使ったMariaDBの部分バックアップと復元は、データベース全体を扱わないため、特定のテーブルやデータベースのみを効率的に管理できます。ここでは、具体的なコード例を挙げて説明します。

部分バックアップの例

この例では、test_dbというデータベースのemployeesテーブルと、another_dbというデータベース全体をバックアップします。

事前準備

MariaDBの設定
innodb_file_per_table=ONがMariaDBの設定ファイル（通常/etc/my.cnfや/etc/mysql/my.cnf.d/内のファイル）で有効になっていることを確認してください。無効な場合、部分バックアップはできません。
```
[mariadb]
innodb_file_per_table=ON
```
設定変更後、MariaDBを再起動します。

バックアップユーザーの作成と権限付与
Mariabackupがデータベースにアクセスするためのユーザーを作成し、必要な権限を付与します。

CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'your_secure_password';
GRANT RELOAD, PROCESS, SUPER, REPLICATION CLIENT, LOCK TABLES ON *.* TO 'backup_user'@'localhost';
FLUSH PRIVILEGES;

ダミーデータの準備
バックアップ対象となるデータベースとテーブルを作成し、データを挿入します。

CREATE DATABASE test_db;
USE test_db;
CREATE TABLE employees (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(100),
    department VARCHAR(100)
);
INSERT INTO employees (name, department) VALUES ('Alice', 'HR'), ('Bob', 'IT');

CREATE DATABASE another_db;
USE another_db;
CREATE TABLE products (
    product_id INT AUTO_INCREMENT PRIMARY KEY,
    product_name VARCHAR(100),
    price DECIMAL(10, 2)
);
INSERT INTO products (product_name, price) VALUES ('Laptop', 1200.00), ('Mouse', 25.00);

バックアップの実行

# バックアップを保存するディレクトリを作成
BACKUP_DIR="/tmp/mariabackup_partial_$(date +%Y%m%d%H%M%S)"
mkdir -p "$BACKUP_DIR"

echo "Partial backup started at: $(date)"
echo "Backup directory: $BACKUP_DIR"

mariabackup --backup \
    --target-dir="$BACKUP_DIR" \
    --databases="test_db.employees another_db" \
    --user=backup_user \
    --password='your_secure_password' \
    --stream=xbstream > "$BACKUP_DIR/backup.xbstream" # ストリーム形式で出力し、後で解凍する

if [ $? -eq 0 ]; then
    echo "Backup completed successfully."
else
    echo "Backup failed!"
    exit 1
fi

echo "Extracting backup stream..."
cd "$BACKUP_DIR"
xbstream -x < backup.xbstream

echo "Partial backup prepare started at: $(date)"
mariabackup --prepare --export \
    --target-dir="$BACKUP_DIR"

if [ $? -eq 0 ]; then
    echo "Prepare completed successfully."
else
    echo "Prepare failed!"
    exit 1
fi

echo "Partial backup and prepare finished."
ls -l "$BACKUP_DIR"
ls -l "$BACKUP_DIR/test_db/"
ls -l "$BACKUP_DIR/another_db/"

解説

--export: 部分復元に必要な--exportオプションです。これにより、各テーブルスペースに対応する.cfgファイルが生成され、これをターゲットサーバーでインポートできるようになります。
--prepare: バックアップされたデータを復元可能な状態にするための前処理（クラッシュリカバリの適用など）を行います。
xbstream -x < backup.xbstream: xbstreamツールを使ってバックアップアーカイブを解凍します。
--stream=xbstream > "$BACKUP_DIR/backup.xbstream": バックアップデータを単一のxbstreamファイルとして出力し、後で解凍することで、大量のファイルを効率的に転送できます。
--user, --password: バックアップユーザーの認証情報です。
--databases="test_db.employees another_db": これが部分バックアップの最も重要なオプションです。スペース区切りで、database_name.table_name形式で特定のテーブルを、database_name形式でデータベース全体を指定できます。
--target-dir: バックアップファイルを格納するディレクトリを指定します。
--backup: バックアップ操作を実行します。

部分復元の例

この例では、バックアップしたtest_db.employeesテーブルとanother_db.productsテーブルを、既存のMariaDBサーバーに復元します。

事前準備（ターゲットMariaDBサーバー上）

MariaDBの停止（推奨）またはアクセス制限
復元作業中は、MariaDBサーバーを停止するか、復元対象のデータベースへのアクセスを制限することをお勧めします。
既存のデータベース/テーブルの削除（または別の場所へ移動）
もし復元先に同じ名前のデータベースやテーブルが既に存在し、それが復元対象のデータと競合する場合は、事前に削除またはリネームします。
```
DROP DATABASE IF EXISTS test_db;
DROP DATABASE IF EXISTS another_db;
```

スキーマの再作成
バックアップされたテーブルの構造（スキーマ）を、データを含まずにターゲットサーバー上に作成します。これはmysqldump --no-dataコマンドなどで生成するのが確実です。

# バックアップ元のスキーマをダンプ（--no-dataが重要）
mysqldump -u root -p --no-data --databases test_db another_db > /tmp/partial_restore_schemas.sql

# ターゲットサーバーでスキーマを再作成
mysql -u root -p < /tmp/partial_restore_schemas.sql

復元の実行

# 事前に作成したバックアップディレクトリのパス
BACKUP_DIR="/tmp/mariabackup_partial_YYYYMMDDHHMMSS" # バックアップ時に指定した実際のパスに置き換える

# MariaDBのデータディレクトリのパス
MARIADB_DATA_DIR="/var/lib/mysql" # 環境に合わせて変更

echo "Starting partial restore..."

# 1. 各テーブルの既存テーブルスペースを破棄（DISCARD TABLESPACE）
#    MariaDBクライアントで実行
mysql -u root -p <<EOF
ALTER TABLE test_db.employees DISCARD TABLESPACE;
ALTER TABLE another_db.products DISCARD TABLESPACE;
-- another_db内の他のテーブルも復元する場合、それらもDISCARDする
EOF

if [ $? -eq 0 ]; then
    echo "Tablespaces discarded successfully."
else
    echo "Failed to discard tablespaces. Check MariaDB logs."
    exit 1
fi

# 2. バックアップされた.ibdファイルと.cfgファイルをデータディレクトリにコピー
echo "Copying .ibd and .cfg files..."
cp "$BACKUP_DIR/test_db/employees.ibd" "$MARIADB_DATA_DIR/test_db/"
cp "$BACKUP_DIR/test_db/employees.cfg" "$MARIADB_DATA_DIR/test_db/"

cp "$BACKUP_DIR/another_db/products.ibd" "$MARIADB_DATA_DIR/another_db/"
cp "$BACKUP_DIR/another_db/products.cfg" "$MARIADB_DATA_DIR/another_db/"

# another_db内の他のテーブルも復元する場合、それらもコピーする
# cp "$BACKUP_DIR/another_db/some_other_table.ibd" "$MARIADB_DATA_DIR/another_db/"
# cp "$BACKUP_DIR/another_db/some_other_table.cfg" "$MARIADB_DATA_DIR/another_db/"

if [ $? -eq 0 ]; then
    echo "Files copied successfully."
else
    echo "Failed to copy files. Check paths and permissions."
    exit 1
fi

# 3. コピーしたファイルの権限を調整（mysqlユーザーとグループに）
echo "Setting file permissions..."
chown -R mysql:mysql "$MARIADB_DATA_DIR/test_db/employees.ibd"
chown -R mysql:mysql "$MARIADB_DATA_DIR/test_db/employees.cfg"
chown -R mysql:mysql "$MARIADB_DATA_DIR/another_db/products.ibd"
chown -R mysql:mysql "$MARIADB_DATA_DIR/another_db/products.cfg"

# another_db内の他のテーブルも復元する場合、それらも権限変更する

if [ $? -eq 0 ]; then
    echo "File permissions set successfully."
else
    echo "Failed to set file permissions. Check permissions."
    exit 1
fi

# 4. 各テーブルのテーブルスペースをインポート（IMPORT TABLESPACE）
#    MariaDBクライアントで実行
echo "Importing tablespaces..."
mysql -u root -p <<EOF
ALTER TABLE test_db.employees IMPORT TABLESPACE;
ALTER TABLE another_db.products IMPORT TABLESPACE;
-- another_db内の他のテーブルも復元する場合、それらもIMPORTする
EOF

if [ $? -eq 0 ]; then
    echo "Tablespaces imported successfully."
else
    echo "Failed to import tablespaces. Check MariaDB logs for schema mismatch or other errors."
    exit 1
fi

echo "Partial restore completed."

# MariaDBサーバーを起動（もし停止していた場合）
# systemctl start mariadb # またはサービス名に合わせて変更

解説

IMPORT TABLESPACE: コピーした.ibdファイルを、対応するテーブルにインポートし、新しいデータディクショナリのエントリを登録します。
権限の調整: コピーしたファイルの所有者とグループをmysql（またはMariaDBが動作するユーザー/グループ）に設定し、MariaDBがファイルにアクセスできるようにします。
ファイルコピー: 準備されたバックアップデータ（.ibdと.cfgファイル）を、ターゲットMariaDBサーバーの対応するデータベースディレクトリに手動でコピーします。
DISCARD TABLESPACE: ターゲットサーバー上のテーブルと既存の.ibdファイルとの関連付けを解除します。これにより、新しい.ibdファイルをインポートする準備ができます。

重要事項と注意点

テストの実施: 本番環境で実行する前に、必ず開発環境やテスト環境で十分に手順を検証し、成功することを確認してください。
手動操作の多さ: フルバックアップと比較して、部分バックアップと復元は手動でのファイルコピーやSQLコマンドの実行が多く、手順が複雑です。自動化スクリプトを作成する際は、エラー処理とログ記録を十分に行うことが重要です。
スキーマの一致: IMPORT TABLESPACEは、ターゲットサーバー上のテーブルスキーマ（カラム、データ型、インデックスなど）がバックアップ元のテーブルスキーマと完全に一致していることを要求します。少しでも異なるとインポートに失敗します。mysqldump --no-dataでスキーマを再作成するのが最も安全な方法です。
innodb_file_per_table: 部分バックアップと復元は、この設定が有効になっているInnoDBテーブルのみに適用できます。共有テーブルスペース（ibdata1など）に格納されているデータは部分的にバックアップ・復元できません。
バージョン互換性: バックアップ元のMariaDBバージョンと復元先のMariaDBバージョンは、基本的には同じメジャーバージョンである必要があります（例: 10.6から10.6）。異なるメジャーバージョン間では、特にInnoDBのフォーマット変更などにより問題が発生する可能性があります。

これらのコード例は、Mariabackupを使った部分バックアップと復元の基本的な流れを示しています。実際の環境に合わせて、パスやユーザー名、パスワードなどを適宜変更してご使用ください。 MariaDBのMariabackupを使ったPartial Backup and Restore（部分バックアップと復元）は、特定のデータベースやテーブルのみを対象とするため、非常に便利です。しかし、そのプロセスはフルバックアップよりも複雑で、いくつかのステップを踏む必要があります。

ここでは、その一連の操作について具体的なコマンド例を交えて説明します。

Partial Backupの例

部分バックアップでは、--databasesオプションを使ってバックアップしたいデータベースやテーブルを指定します。

特定のデータベースをバックアップする

database1というデータベース全体をバックアップする場合。

mariabackup --backup \
--target-dir=/data/backups/partial_db1_$(date +%Y%m%d%H%M%S) \
--user=backup_user \
--password=your_password \
--databases="database1"

--databases="database1": database1というデータベースをバックアップ対象として指定します。複数のデータベースを指定する場合は、スペースで区切って記述します（例: --databases="database1 database2"）。
--user, --password: MariaDBサーバーに接続するためのユーザー名とパスワードです。このユーザーには適切な権限（RELOAD, PROCESS, SUPER, REPLICATION CLIENT, LOCK TABLESなど）が必要です。
--target-dir: バックアップデータを保存するディレクトリを指定します。$(date +%Y%m%d%H%M%S)を付けることで、実行日時を含むユニークなディレクトリ名が自動的に作成されます。

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

database1内のtable_aとdatabase2内のtable_bをバックアップする場合。

mariabackup --backup \
--target-dir=/data/backups/partial_tables_$(date +%Y%m%d%H%M%S) \
--user=backup_user \
--password=your_password \
--databases="database1.table_a database2.table_b"

--databases="database1.table_a database2.table_b": データベース名.テーブル名の形式で、バックアップしたいテーブルを指定します。

バックアップの準備（Prepare）の例

バックアップしたデータは、そのままでは復元できません。--prepareオプションで、クラッシュリカバリのような処理を行い、復元可能な状態にします。Partial Backupの場合は、さらに--exportオプションを付加して、トランスポータブル・テーブルスペースに必要な.cfgファイルを生成します。

# 上記で作成したバックアップディレクトリを指定
BACKUP_DIR="/data/backups/partial_db1_YYYYMMDDHHMMSS" # 実際のバックアップディレクトリに置き換えてください

mariabackup --prepare --export \
--target-dir="${BACKUP_DIR}"

このコマンドが正常に完了すると、指定されたバックアップディレクトリ内に、各テーブルの.ibdファイルと、それに対応する.cfgファイル（トランスポータブル・テーブルスペースのメタデータ）が生成されます。

Partial Restoreは、フルバックアップの復元と異なり、より多くの手動ステップが必要です。

ターゲットサーバーでの事前準備

ターゲットサーバーでMariaDBが動作している必要があります。

復元したいデータベースとテーブルのスキーマを作成する

これは非常に重要なステップです。データは不要で、テーブル構造のみを作成します。mysqldump --no-dataを使用するのが一般的です。

# バックアップ元サーバーでスキーマをダンプ
mysqldump --no-data \
--user=root --password=your_password \
--databases database1 database2 > /tmp/recreate_schemas.sql

# ターゲットサーバーにSQLファイルをコピーし、実行してダミーテーブルを作成
# 例: scp /tmp/recreate_schemas.sql user@target_server:/tmp/
# ターゲットサーバー上で実行
mysql -u root -p < /tmp/recreate_schemas.sql

ターゲットサーバーで既存のテーブルスペースを破棄する

作成したダミーテーブルに対応するテーブルスペースを破棄し、外部からのインポートを受け入れられる状態にします。

-- MariaDBクライアントで実行
USE database1;
ALTER TABLE table_a DISCARD TABLESPACE;

USE database2;
ALTER TABLE table_b DISCARD TABLESPACE;

バックアップされた.ibdファイルと.cfgファイルをコピーする

準備済みのバックアップディレクトリから、復元したいテーブルの.ibdファイルと.cfgファイルを、ターゲットMariaDBサーバーのデータディレクトリ内の対応するデータベースディレクトリにコピーします。

# バックアップディレクトリの例
BACKUP_DIR="/data/backups/partial_db1_YYYYMMDDHHMMSS" # 実際のバックアップディレクトリに置き換えてください

# ターゲットMariaDBのデータディレクトリの例 (my.cnfで確認)
MARIADB_DATADIR="/var/lib/mysql"

# database1.table_a をコピー
cp "${BACKUP_DIR}/database1/table_a.ibd" "${MARIADB_DATADIR}/database1/"
cp "${BACKUP_DIR}/database1/table_a.cfg" "${MARIADB_DATADIR}/database1/"

# database2.table_b をコピー
cp "${BACKUP_DIR}/database2/table_b.ibd" "${MARIADB_DATADIR}/database2/"
cp "${BACKUP_DIR}/database2/table_b.cfg" "${MARIADB_DATADIR}/database2/"

# コピーしたファイルの権限をMariaDBが読み書きできるように設定
# 通常はmysqlユーザーとグループに設定
chown mysql:mysql "${MARIADB_DATADIR}/database1/table_a.ibd" "${MARIADB_DATADIR}/database1/table_a.cfg"
chown mysql:mysql "${MARIADB_DATADIR}/database2/table_b.ibd" "${MARIADB_DATADIR}/database2/table_b.cfg"
chmod 660 "${MARIADB_DATADIR}/database1/table_a.ibd" "${MARIADB_DATADIR}/database1/table_a.cfg"
chmod 660 "${MARIADB_DATADIR}/database2/table_b.ibd" "${MARIADB_DATADIR}/database2/table_b.cfg"

テーブルスペースをインポートする

MariaDBクライアントから、コピーした.ibdファイルをテーブルにインポートします。

-- MariaDBクライアントで実行
USE database1;
ALTER TABLE table_a IMPORT TABLESPACE;

USE database2;
ALTER TABLE table_b IMPORT TABLESPACE;

これで、指定したテーブルにデータが復元され、MariaDBからアクセスできるようになります。

重要な注意事項

テスト環境での確認: 本番環境でPartial Backup and Restoreを実行する前に、必ずテスト環境でこれらの手順を十分にテストし、成功することを確認してください。
権限: Mariabackupの実行ユーザーと、ファイルシステム上のコピー先ディレクトリの権限に注意してください。
バージョン互換性: バックアップ元のMariaDBと復元先のMariaDBのメジャーバージョンは、基本的に同じである必要があります。異なるバージョン間でのPartial Restoreは、予期せぬ問題を引き起こす可能性があります。
innodb_file_per_table=ON: Partial Backup and Restoreは、MariaDBのmy.cnfでinnodb_file_per_tableがONに設定されていることが前提です。この設定がない場合、テーブルは共有テーブルスペース（ibdata1）に格納され、個別にバックアップ・復元することはできません。

mysqldump / mariadb-dump (論理バックアップ)

これは、最も一般的で柔軟なバックアップ・復元方法の一つです。データベースのスキーマとデータをSQLステートメントとしてダンプします。

メリット

遠隔地からのバックアップ/復元
ネットワーク経由で簡単にダンプしたり、復元したりできます。
可読性
バックアップファイルがSQLなので、内容を確認したり、必要に応じて編集したりできます。
クロスバージョン互換性
通常、異なるMariaDB/MySQLバージョン間でもデータを移行しやすいです（ただし、メジャーバージョン間の大きな変更には注意が必要）。
非常に柔軟
特定のデータベース、特定のテーブル、特定の行（--whereオプション）まで細かく指定してバックアップできます。

デメリット

整合性
大規模なデータベースの場合、バックアップ中にデータが変更されると整合性の問題が生じる可能性があります。--single-transaction (InnoDBの場合) や--lock-tables (MyISAMの場合) などのオプションで対応しますが、アプリケーションのダウンタイムを考慮する必要がある場合もあります。
サーバー負荷
バックアップ中にサーバーに負荷がかかる可能性があります。
速度
物理バックアップに比べて、大量のデータを扱う場合のバックアップ・復元速度は遅いです。特に、復元時にはSQLを再実行するため、時間がかかります。

使用例

復元

mysql -u username -p < database_name_backup.sql

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

mysqldump -u username -p database_name table_name > table_name_backup.sql

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

mysqldump -u username -p --databases database_name > database_name_backup.sql

MyDumper / MyLoader (並列論理バックアップ)

mysqldumpのマルチスレッド版で、より高速な論理バックアップ・復元を実現します。大量のデータを扱う場合にmysqldumpのパフォーマンス問題が懸念される場合に検討されます。

メリット

mysqldumpと同様の柔軟性。
mysqldumpよりも高速なバックアップ・復元。

デメリット

物理バックアップほどの速度は期待できない。
mysqldumpに比べて導入が追加で必要（別途インストール）。

使用例

復元

myloader --host=localhost --user=username --password=your_password --database=database_name --directory=/path/to/backup_dir --threads=4

バックアップ

mydumper --host=localhost --user=username --password=your_password --database=database_name --outputdir=/path/to/backup_dir --threads=4

MariaDB Replication (レプリカからのリストア)

これは直接的なバックアップツールではありませんが、レプリケーション環境がある場合、特定の時点のデータを取得する非常に強力な方法となります。レプリカ（スレーブ）サーバーを利用して、メインサーバーに影響を与えることなくデータを取得できます。

メリット

遅延レプリカ (Delayed Replica)
意図的にレプリケーションを遅延させることで、人為的なミス（誤ったDELETE/UPDATEなど）が発生した場合に、その影響がレプリカに伝播する前にデータを救済できます。
ポイントインタイムリカバリの基盤
バイナリログと組み合わせることで、特定の時点への復旧が可能です。
ライブバックアップ
レプリカからバックアップを取得することで、プライマリサーバーへの影響を最小限に抑えられます。
RPO/RTOの改善
レプリケーションは、障害発生時のRPO（目標復旧時点）とRTO（目標復旧時間）を最小化するのに役立ちます。

デメリット

フルデータベースの復元が基本
特定のテーブルやデータベースを直接「復元」する機能は持っていません。レプリカからmysqldumpなどで必要なデータを抽出し、それをプライマリにインポートする形になります。
設定と管理の複雑さ
レプリケーションの設定と維持には専門知識が必要です。
インフラコスト
追加のサーバーが必要になるため、コストが増加します。

使用例 (遅延レプリカを活用した部分復元シナリオ)

遅延レプリカの停止
```
STOP SLAVE;
```

遅延レプリカから特定のデータをダンプ

mysqldump -u root -p --single-transaction --databases database_name table_name > /tmp/recovered_data.sql

プライマリサーバーで復元

mysql -u root -p database_name < /tmp/recovered_data.sql

遅延レプリカの再開
```
START SLAVE;
```

テーブルを論理的にパーティション化している場合、特定のパーティションを切り離して管理（バックアップ/復元）することが可能です。これはMariabackupの--export機能とは少し異なりますが、特定のデータ群を独立して扱いたい場合に有効です。

メリット

大規模テーブルの一部のみを管理する際に効率的。

デメリット

すべてのユースケースに適しているわけではない。
テーブル設計の段階でパーティション化が必要。

MariabackupのPartial Backup and Restoreは物理バックアップの利点（高速性、整合性）を持ちつつ、特定のデータ群を扱える点で優れていますが、復元時の手順が複雑です。

それに対して、mysqldump / mydumperは柔軟性と使いやすさで勝ります。特に、データベースやテーブルのサイズがそこまで大きくなく、異なるバージョンへの移行やデータの確認が頻繁に必要となる場合には、論理バックアップツールが第一の選択肢となるでしょう。

レプリケーションは、高可用性と災害復旧の戦略の一部として非常に重要であり、間接的に「特定の時点のデータ取得」という形で部分的な復元に役立ちます。