MariaDB dumpで確実にバックアップする方法|mysqldumpとmariadb-dumpコマンド比較

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOME > Linux技術 リナックスマスター.JP(Linuxマスター.JP) > Linuxtips > データーベース管理 > MariaDB dumpで確実にバックアップする方法|mysqldumpとmariadb-dumpコマンド比較
「mariadb-dump と mysqldump のどちらを使えばいいか分からない」
「MariaDB 11 にアップグレードしたら、いつ mysqldump のエイリアスが廃止になるか不安だ」

MariaDB 11 系からコマンド体系が整理され、バックアップコマンドの正式名称は mysqldump から mariadb-dump に変わりました。後方互換のため mysqldump コマンドはシンボリックリンクとして残っていますが、スクリプトや cron を長期運用するなら正式名称に統一しておくのが安全です。

この記事では、Rocky Linux 9 / Ubuntu 22.04 上の MariaDB 10.11 LTS・11.x を対象に、mariadb-dump による論理バックアップの実践的な手順を解説します。ダンプ取得からリストア・圧縮保存・実務でよく使うオプションまで、実機の出力例付きで説明します。

この記事のポイント

・mariadb-dump は MariaDB 11 の正式名称で、mysqldump はシンボリックリンクに格下げされた
・InnoDB テーブルは --single-transaction を付けることで無停止バックアップが取れる
・--events --routines を忘れるとストアドプロシージャとイベントがダンプに含まれない
・リストアは mariadb コマンドにダンプファイルをリダイレクトするだけで完了する


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

mysqldump と mariadb-dump の違いと命名変更の背景

MariaDB プロジェクトは MySQL からのフォーク当初、コマンド名を MySQL 互換に保っていました。しかし MariaDB 11.0(2023年リリース)からは MySQL への依存を断ち切る方針として、全コマンドを「mariadb-」プレフィックスに統一する作業が進んでいます。

主な対応表は次のとおりです。

・mysql → mariadb(クライアント)
・mysqldump → mariadb-dump(論理バックアップ)
・mysqladmin → mariadb-admin
・mysqlcheck → mariadb-check

旧名称は後方互換のためシンボリックリンクとして残っています。Rocky Linux 9 上の MariaDB 10.11 LTS 環境で確認すると、次のようになっています。

[root@db01 ~]# ls -la /usr/bin/mysqldump lrwxrwxrwx 1 root root 12 Mar 15 09:23 /usr/bin/mysqldump -> mariadb-dump [root@db01 ~]# mariadb-dump --version mariadb-dump Ver 10.17 Distrib 10.11.8-MariaDB, for Linux (x86_64)

実体は同じバイナリなので、機能上の違いはありません。ただし、スクリプトに mysqldump とハードコードしている場合、将来のバージョンでシンボリックリンクが削除されると動かなくなります。新規で書くスクリプトは mariadb-dump を使うようにしてください。

MariaDB 10.x 環境に注意:MariaDB 10.11 LTS は 2028 年までサポートが続きますが、mariadb-dump コマンドは 10.4 系以降から追加されています。10.3 以前の古い環境では mysqldump しか存在しないため確認が必要です。

基本的なバックアップ手順

1. データベース単体をバックアップする

最も頻繁に使う形式です。バックアップ対象のデータベース名を引数に指定します。

# 書式 mariadb-dump -u ユーザー名 -p データベース名 > 出力ファイル.sql # 実例(myapp_db を /backup/ へ保存) mariadb-dump -u root -p myapp_db > /backup/myapp_db_20260930.sql Enter password:

実行後、ファイルが作成されたことを確認します。

[root@db01 ~]# ls -lh /backup/myapp_db_20260930.sql -rw-r--r-- 1 root root 4.2M Sep 30 14:35 /backup/myapp_db_20260930.sql

ダンプファイルの先頭を確認すると、MariaDB のダンプコマンドが正しく動いているか確認できます。

[root@db01 ~]# head -5 /backup/myapp_db_20260930.sql -- MariaDB dump 10.19 Distrib 10.11.8-MariaDB, for Linux (x86_64) -- -- Host: localhost Database: myapp_db -- ------------------------------------------------------ -- Server version 10.11.8-MariaDB

先頭行に「MariaDB dump」と出ていれば、MariaDB のダンプコマンドが動いている証拠です。「mysqldump」表記になっている場合は、MySQL のクライアントツールが混在している可能性があります。

2. 全データベースをまとめてバックアップする

--all-databases(短縮形 -A)を使うと、全データベースを1ファイルにまとめてダンプできます。

mariadb-dump -u root -p --all-databases > /backup/all_databases_20260930.sql

複数の特定データベースのみダンプしたい場合は --databases(短縮形 -B)を使います。

# app_db と log_db の2つをダンプ mariadb-dump -u root -p --databases app_db log_db > /backup/app_and_log_20260930.sql

--databases を使うと出力 SQL に CREATE DATABASE と USE 文が含まれるため、リストア時にデータベースを事前作成する手間が省けます。

3. テーブル単位でダンプする

特定テーブルだけを抜き出したい場合は、データベース名の後ろにテーブル名を続けます。

# myapp_db の orders テーブルだけダンプ mariadb-dump -u root -p myapp_db orders > /backup/orders_20260930.sql

テーブル単位ダンプでは CREATE DATABASE 文は出力されないため、リストア時は対象データベースを指定して読み込みます。

リストア手順

1. 同じサーバーへリストアする

リストアは mariadb(または互換の mysql)クライアントにダンプファイルをリダイレクトするだけです。

# データベースを事前に作成(--databases なしのダンプの場合) mariadb -u root -p -e "CREATE DATABASE IF NOT EXISTS myapp_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;" # リストア実行 mariadb -u root -p myapp_db < /backup/myapp_db_20260930.sql Enter password:

エラーなく完了したら、テーブルが復元されているか確認します。

[root@db01 ~]# mariadb -u root -p myapp_db -e "SHOW TABLES;" Enter password: +--------------------+ | Tables_in_myapp_db | +--------------------+ | orders | | products | | users | +--------------------+

2. 別サーバーへ移行する

サーバー移行時は、移行先に対して直接リストアします。--databases オプション付きでダンプしていれば、リストア先でのデータベース名指定は不要です。

# 移行先サーバーへ直接流し込む(IPは移行先の実際のアドレスに置き換える) mariadb -u root -p -h 移行先IPアドレス < /backup/myapp_db_20260930.sql

実務で押さえるオプション

1. --single-transaction(InnoDB の無停止バックアップ)

テーブルが InnoDB の場合、--single-transaction を付けることで、テーブルをロックせずに一貫性のあるバックアップが取れます。サービス稼働中のバックアップにはほぼ必須のオプションです。

mariadb-dump -u root -p --single-transaction myapp_db > /backup/myapp_db_20260930.sql

・仕組み:バックアップ開始時に START TRANSACTION WITH CONSISTENT SNAPSHOT を発行し、トランザクション分離レベルを利用して一貫したスナップショットを取得します。
・対象:InnoDB テーブルのみ有効。MyISAM テーブルが混在する場合、MyISAM は依然として読み取りロックがかかります。
・注意:--single-transaction と --lock-tables は同時に使えません(前者が後者を上書きします)。

2. --events --routines(ストアドプロシージャとイベントを含める)

デフォルトの mariadb-dump はトリガーを含みますが、ストアドプロシージャ・ストアド関数・イベントスケジューラのイベントは含まれません。移行や完全バックアップが目的なら必ず付けてください。

mariadb-dump -u root -p \ --single-transaction \ --events \ --routines \ myapp_db > /backup/myapp_db_full_20260930.sql

付け忘れると「移行後にアプリが動かない」「バッチ処理が消えた」といったトラブルになります。特にバッチ系の処理をイベントスケジューラで管理しているサーバーでは要注意です。

3. gzip 圧縮して保存する

SQL テキストは圧縮率が高く、gzip で 5~10 倍程度に圧縮できます。バックアップ先のディスクを圧迫しないためにも、圧縮保存を標準にしておくのがおすすめです。

# ダンプしながら gzip で圧縮する(中間ファイルを作らない) mariadb-dump -u root -p --single-transaction myapp_db | gzip > /backup/myapp_db_20260930.sql.gz # 圧縮ファイルのサイズ確認 [root@db01 ~]# ls -lh /backup/myapp_db_20260930.sql.gz -rw-r--r-- 1 root root 542K Sep 30 14:37 /backup/myapp_db_20260930.sql.gz # 圧縮ファイルからリストアする場合 gunzip -c /backup/myapp_db_20260930.sql.gz | mariadb -u root -p myapp_db

トラブルシュート

「Access denied for user」エラーが出た時

ダンプ実行時に以下のようなエラーが出る場合、ユーザーの権限が不足しています。

mariadb-dump: Got error: 1045: Access denied for user 'backup_user'@'localhost' (using password: YES)

mariadb-dump には最低限 SELECT と SHOW VIEW 権限が必要です。バックアップ専用ユーザーを作る場合の権限付与例を示します。

# バックアップ専用ユーザーへの権限付与例 GRANT SELECT, SHOW VIEW, EVENT, TRIGGER ON *.* TO 'backup_user'@'localhost' IDENTIFIED BY 'パスワード'; FLUSH PRIVILEGES;

「2006: MariaDB server has gone away」が出る時

大量データのダンプ中にタイムアウトして切断されることがあります。--quick オプションで行単位の出力に切り替えることで回避できます。

# --quick を付けると大テーブルをバッファせず1行ずつ出力する mariadb-dump -u root -p --quick --single-transaction myapp_db > /backup/myapp_db_20260930.sql

1GB を超えるデータベースのダンプでは --quick を標準オプションに加えることを検討してください。

リストア時に「ERROR 1005 (HY000): Can't create table」が出る時

外部キー制約の参照先テーブルが参照元より先に作成されようとして失敗するケースです。ダンプファイルの先頭には SET FOREIGN_KEY_CHECKS=0; が含まれているはずですが、部分リストアや途中から流し込んだ場合に外れることがあります。

# 外部キーチェックを一時的に無効にしてリストアする mariadb -u root -p myapp_db -e "SET FOREIGN_KEY_CHECKS=0;" mariadb -u root -p myapp_db < /backup/myapp_db_20260930.sql mariadb -u root -p myapp_db -e "SET FOREIGN_KEY_CHECKS=1;"

本記事のまとめ

やりたいこと コマンド
単一DBのバックアップ mariadb-dump -u root -p db_name > backup.sql
全DBのバックアップ mariadb-dump -u root -p --all-databases > all.sql
InnoDB無停止バックアップ mariadb-dump -u root -p --single-transaction db_name > backup.sql
プロシージャ・イベント込み mariadb-dump -u root -p --single-transaction --events --routines db_name > backup.sql
gzip圧縮して保存 mariadb-dump -u root -p db_name | gzip > backup.sql.gz
バックアップからリストア mariadb -u root -p db_name < backup.sql
圧縮ファイルからリストア gunzip -c backup.sql.gz | mariadb -u root -p db_name
mariadb-dump は MariaDB 11 系の正式コマンド名です。mysqldump は当面エイリアスとして残りますが、新規スクリプトでは mariadb-dump を使い、--single-transaction と --events --routines を基本オプションとして組み込んでおきましょう。Linuxサーバーの本番運用を体系的に学びたい方には、2日間のハンズオンセミナーでバックアップ・リストアの実践トレーニングも行っています。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、

MariaDB / MySQL のバックアップ設計から cron 自動化・リストア検証まで、現役サーバー管理者が実際の現場ノウハウをそのまま教える2日間のハンズオンセミナーです。受講者3,100名以上の実績があります。

>> Linux Master Pro Seminar の詳細を見る

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。