SQLダンプやログファイルを高圧縮して保管・転送コストを削減する実務手順

DBのフルダンプやアクセスログは数百MB〜数GBに膨らみやすく、ディスク逼迫や転送遅延の原因になります。bzip2形式はテキスト系ファイルへの圧縮率が高く、同じSQLダンプでもgzipより10〜20%小さくなるケースが多いです。この記事ではファイル単体の圧縮・解凍から、tarを組み合わせたディレクトリ丸ごとの圧縮、logrotateとの自動化連携まで、コピペで即使える手順を紹介します。

bzip2を選ぶ場面と他の圧縮形式との使い分け

圧縮形式は用途に合わせて使い分けることが実務の基本です。代表的な形式の特徴を整理します。

形式	速度	圧縮率	主な用途
gzip (.gz)	速い	標準	パイプ処理・汎用圧縮
bzip2 (.bz2)	やや遅い	高い（テキスト系）	SQLダンプ・ログの長期保管
xz (.xz)	遅い	最高	パッケージ配布・最大圧縮
zstd (.zst)	速い	高い	高速かつ高圧縮が必要な場面

bzip2が特に効果を発揮するのは、SQL文のようにパターンの繰り返しが多いテキストファイルです。圧縮に数十秒かかっても問題ない長期保管用バックアップや、転送先のストレージが限られている場面に向いています。リアルタイムのパイプ処理やCPU負荷を抑えたい場合はgzipやzstdが適しています。なお、すでに圧縮済みのファイル（JPEGや動画、既存のアーカイブ）に対しては圧縮効果がほとんど得られず、むしろサイズが微増する場合もあるため注意が必要です。

ファイル単体をbzip2形式で圧縮する

bzip2コマンドにファイル名を渡すだけで圧縮できます。圧縮後は元ファイルが削除され、拡張子 .bz2 が付いたファイルが生成されます。

# 圧縮前のサイズを確認
ls -lh dump_20240718.sql
# -rw-r--r-- 1 ops ops 198M Jul 18 09:00 dump_20240718.sql

# bzip2 で圧縮（元ファイルは削除される）
bzip2 dump_20240718.sql

# 圧縮後のサイズを確認
ls -lh dump_20240718.sql.bz2
# -rw-r--r-- 1 ops ops 3.5M Jul 18 09:00 dump_20240718.sql.bz2

元ファイルを残したい場合は -k（keep）オプションを付けます。バックアップスクリプトなど、元ファイルをそのまま使い続ける運用では必須のオプションです。

# 元ファイルを残したまま圧縮
bzip2 -k dump_20240718.sql

# 両方のファイルが存在することを確認
ls -lh dump_20240718.sql dump_20240718.sql.bz2

圧縮効果を数値で確認したいときは -v（verbose）を追加します。実際の圧縮率がビット/バイト単位で表示されるため、対象ファイルがbzip2に向いているかどうか判断できます。

bzip2 -v dump_20240718.sql
#   dump_20240718.sql:  56.234:1,  0.142 bits/byte, 98.22% saved, 207421440 in, 3688960 out.

bzip2形式のファイルを解凍する

bunzip2コマンド、または bzip2 -d で解凍できます。いずれも動作は同一で、解凍後は元の .bz2 ファイルが削除されます。

# bunzip2 で解凍（.bz2 ファイルは削除される）
bunzip2 dump_20240718.sql.bz2

# bzip2 -d でも同じ結果
bzip2 -d dump_20240718.sql.bz2

解凍せずに内容だけ確認したいときは bzcat を使います。ディスクを消費せずにログのgrepや先頭行の確認ができるため、調査作業で重宝します。

# 解凍せずにエラー行を抽出
bzcat access.log.bz2 | grep "ERROR" | tail -20

# 先頭10行だけ確認
bzcat dump_20240718.sql.bz2 | head -10

転送後のファイル破損チェックには -t（test）オプションが便利です。実際に解凍を行わず整合性のみ検証するため、ディスク消費なしで確認できます。

# 圧縮ファイルの整合性チェック（解凍は行わない）
bzip2 -t dump_20240718.sql.bz2
# 正常なら何も表示されない。破損していればエラーメッセージが出る

tarと組み合わせてディレクトリごと圧縮する

複数ファイルやディレクトリ構造をまとめて圧縮する場合は、tar の -j オプションを使って .tar.bz2 アーカイブを作成します。

# ディレクトリを .tar.bz2 に圧縮（-j で bzip2 を指定）
tar -cjvf backup_20240718.tar.bz2 /var/log/myapp/

# 圧縮後のサイズを確認
ls -lh backup_20240718.tar.bz2

# .tar.bz2 を展開（カレントディレクトリに展開される）
tar -xjvf backup_20240718.tar.bz2

# 展開先を指定する場合は -C オプション
tar -xjvf backup_20240718.tar.bz2 -C /tmp/restore/

# 展開せずに中身を一覧表示
tar -tjvf backup_20240718.tar.bz2

tar オプションの読み方は c（create）/x（extract）/t（list）＋j（bzip2）＋v（verbose）＋f（filename）の組み合わせです。一度覚えれば迷いません。

実務でよく使うオプションと応用テクニック

圧縮レベルの調整でCPU負荷をコントロールする

-1（高速・圧縮率低め）から -9（低速・圧縮率最大）まで指定できます。デフォルトは -9 です。バッチ処理中にCPU負荷が問題になる場面では -1 から試すと良いでしょう。

# CPU負荷を抑えて速度優先で圧縮
bzip2 -1 large_dump.sql

# 最大圧縮率（デフォルトと同等）
bzip2 -9 large_dump.sql

数GBを超えるファイルは並列圧縮ツールを活用する

bzip2はシングルスレッド動作のため、数GB以上のファイルでは処理時間がボトルネックになります。pbzip2（parallel bzip2）はマルチコアを活用して大幅に高速化でき、出力フォーマットは標準のbzip2と完全互換です。

# pbzip2 のインストール（Ubuntu 22.04 / Debian 12）
sudo apt install pbzip2

# pbzip2 のインストール（RHEL 9 / Rocky / AlmaLinux）
sudo dnf install pbzip2

# 並列圧縮（コア数は自動検出）
pbzip2 -k large_dump.sql

# tar と組み合わせる場合（パイプ経由）
tar -cf - /var/log/myapp/ | pbzip2 -c > backup_20240718.tar.bz2

同名ファイルの上書きを防ぐ自動化設計

bzip2は同名の .bz2 ファイルが存在する場合、上書きを拒否してエラーになります。毎日バックアップを自動生成するスクリプトでは、ファイル名に日付を含めるか、世代管理で古いファイルを削除する設計にします。

#!/bin/bash
# 日付付きファイル名でSQLダンプを圧縮バックアップ
DATE=$(date +%Y%m%d)
DUMP_FILE="/var/backup/dump_${DATE}.sql"
mysqldump -u root mydb > "${DUMP_FILE}"
bzip2 "${DUMP_FILE}"

# 30日より古いバックアップを自動削除
find /var/backup/ -name "dump_*.sql.bz2" -mtime +30 -delete

logrotateと連携してログを自動圧縮する

運用現場でのログ圧縮は、手動で実行するよりもlogrotateに任せるのが定石です。/etc/logrotate.d/の設定ファイルにcompressとcompresscmdを指定するだけで、ローテート後のログが自動的にbzip2圧縮されます。

# /etc/logrotate.d/myapp の設定例
/var/log/myapp/*.log {
    daily
    rotate 30
    compress
    compresscmd /usr/bin/bzip2
    compressext .bz2
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        systemctl reload myapp.service || true
    endscript
}

delaycompressを指定すると、直前のローテートファイルは1世代分を非圧縮で保持します。障害調査で最新ログを即座に参照できるため、ある運用現場では「圧縮は必ず1世代遅延させる」をチームのルールにしているケースが多いです。設定変更後は logrotate -d /etc/logrotate.d/myapp でドライランを実行し、意図通りに動作することを確認してから本番適用します。