Info2softは、ウェブサイトでより快適で適切な閲覧体験を提供するためにCookieを使用しています。 プライバシーポリシー
Loading...
By:
大規模データベースは多くのストレージ領域を消費し、バックアップに時間がかかるため、ストレージコストの上昇とパフォーマンス低下を引き起こします。SQL Serverバックアップ圧縮はこれらの課題を解決します。平均でバックアップファイルを50％～80％削減し、ストレージ領域を節約すると同時にバックアップ処理を大幅に高速化します。
SQL Serverのバックアップ処理を高速化したい場合、圧縮はCPU使用率を若干消費するものの非常に有効な手段です。本記事では、SSMSによる簡単な手順からZSTDアルゴリズムといった高度なツールまで、SQL Serverでバックアップ圧縮を有効にする4つの方法を解説します。
SQL Serverバックアップ圧縮は、バックアップファイルのサイズを削減する機能です。この機能を有効にすると、データベースエンジンはディスクへ書き込む前にデータを圧縮します。その結果、元のデータベースサイズよりもはるかに小さいバックアップファイルが生成されます。
他の種類の圧縮と区別することが重要です。例えば「データ圧縮」（行・ページ圧縮）はデータベーステーブル内部で実行されます。バックアップ圧縮はバックアップ処理実行時のみ動作します。圧縮済みテーブルがなくても圧縮バックアップを利用可能です。
技術的に、バックアップの圧縮率はデータ型に依存します。テキストデータや数値データは圧縮効果が高い一方、暗号化データや既に圧縮済みのファイル（PDF、ZIPなど）はサイズがほとんど縮小しません。旧バージョンのSQL Serverは独自の標準アルゴリズムを使用していましたが、SQL Server 2025では圧縮効率に優れたZstandard（ZSTD）アルゴリズムが導入されました。
圧縮を活用することで、データベース管理者にとって複数の大きな利点が得られます。大規模データ管理でよく発生する速度、領域、コストの課題に対応します。
ストレージ使用量の削減
圧縮によりバックアップファイルサイズが大幅に縮小され、一般的な圧縮率は50‑80％です。テキストや重複値を含むデータベースで効果が高く、暗号化データや画像などのバイナリファイルでは領域削減効果は小さくなります。
バックアップ時間の短縮
圧縮によりCPU使用率は上昇しますが、ディスクへ書き込むデータ量が減少するためディスクI/Oのボトルネックが解消されます。これによりSQL Serverのバックアップ処理が高速化され、保守時間枠内でバックアップを完了させやすくなります。
オフサイト転送の高速化
サイズの小さい圧縮バックアップは、オフサイトや災害復旧先へより速く転送できます。帯域幅の消費を抑え、オフサイトのバックアップを最新の状態に保ち、復旧準備性（RPO）を高めます。
（クラウド）バックアップコストの削減
圧縮バックアップは、使用ギガバイト数を抑えることでAzure、AWSなどのクラウドストレージコストを削減します。また、ローカルへリストアするためクラウドからバックアップをダウンロードする際の出力帯域料金も削減できます。
SQL Serverのバックアップ圧縮は、GUI画面、T‑SQLスクリプト、サーバー全体の既定設定など複数の柔軟な方法で有効化できます。実装が簡単で広く使われている方法から順に解説します。
多くのDBAにとって、SQL Server Management Studio（SSMS）は圧縮バックアップを作成する最も簡単な手段です。手動バックアップタスクや単一のバックアップジョブの圧縮設定変更に適しています。
手順：
自動実行やジョブスケジューリングが容易なため、多くのDBAがT‑SQLスクリプトによるバックアップを好んで使用します。バックアップコマンドに`COMPRESSION`キーワードを追加するだけで圧縮を有効にできます。
T‑SQLでの圧縮バックアップは直感的に記述できます。代表的な3種類のバックアップの簡潔なスクリプトを以下に示します。
データベースの完全な圧縮コピーを作成します：
-- 圧縮付き完全バックアップ（完全性検証＋進捗表示）
BACKUP DATABASE [YourDatabaseName]
TO DISK = 'C:\Backups\YourDatabase_Full.bak'
WITH COMPRESSION, CHECKSUM, STATS = 10;
前回の完全バックアップ以降に変更されたデータのみを圧縮します：
-- 圧縮付き差分バックアップ
BACKUP DATABASE [YourDatabaseName]
TO DISK = 'C:\Backups\YourDatabase_Diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;
トランザクションログを圧縮します。ログ量が多い高負荷データベースで重要です：
-- 圧縮付きトランザクションログバックアップ
BACKUP LOG [YourDatabaseName]
TO DISK = 'C:\Backups\YourDatabase_Log.trn'
WITH COMPRESSION;
ベストプラクティスとして例に`CHECKSUM`を含めています。バックアップ作成時にファイルの破損を検知します。T‑SQLにより、圧縮バックアップの保存先や設定を制御でき、自動化ワークフローに柔軟に対応可能です。
すべてのバックアップごとに手動で圧縮を有効にするのは手間がかかり、設定漏れの原因になります。代わりにインスタンスレベルでSQL Serverバックアップ圧縮の既定値を設定すると、以降の新規バックアップは自動的に圧縮され、個別ジョブごとの操作が不要になります。
SSMSで既定値を設定
T‑SQLで既定値を設定
`sp_configure`コマンドで迅速に設定可能で、複数サーバーを一括管理する場面に適しています：
-- インスタンス全体の既定としてバックアップ圧縮を有効化
EXEC sys.sp_configure N'backup compression default', N'1';
RECONFIGURE WITH OVERRIDE;
この既定値を設定後、明示的な圧縮指定のないバックアップコマンドは自動で圧縮が適用されます。一時的に非圧縮のバックアップを実行したい場合はT‑SQLスクリプトに`NO_COMPRESSION`キーワードを追加してください。最新のSQL Server環境における標準的なベストプラクティスであり、全バックアップのストレージを自動的に節約できます。
SQL Server 2025では、従来の内部圧縮方式に代わる新しい高度なバックアップ圧縮アルゴリズムZstandard（ZSTD）が導入されました。ZSTDは圧縮率に優れ、CPUオーバーヘッドが低いため従来の圧縮より効率的です。
非常に大きなデータベースに適しており、バックアップファイルをより効果的に小さくし、バックアップ処理を高速化します。
ZSTD圧縮はT‑SQLからのみ利用可能で、SSMSに専用のチェックボックスはまだ存在しません。圧縮バックアップコマンドに`ALGORITHM = ZSTD`パラメータを追加するだけで利用できます：
-- SQL Server 2025 ZSTD圧縮アルゴリズムによるバックアップ
BACKUP DATABASE [YourDatabaseName]
TO DISK = 'C:\Backups\YourDatabase_ZSTD.bak'
WITH COMPRESSION (ALGORITHM = ZSTD), CHECKSUM;
SQL Server 2025を使用している場合、ZSTDはバックアップ速度とファイル圧縮率のバランスに優れた最適な選択肢です。
SQL Serverにはネイティブのバックアップ圧縮機能がありますが、多くの組織は単なるファイルサイズ削減以上の要件を持っています。最新環境では、データベース、仮想マシン、ファイルシステム、異種ストレージを横断した集中バックアップ管理、ネットワーク利用やバックアップ時間枠の詳細な制御が求められることが多いです。
i2Backupは、SQL Serverだけでなく複数のワークロードを保護するために設計されたバックアッププラットフォームです。高効率な圧縮、インテリジェントな転送最適化、柔軟なスケジューリングによりSQLバックアップを強化すると同時に、同一プラットフォーム上でシステム、ファイル、ストレージレベルのバックアップもサポートします。
個人プロジェクトや小規模サーバーであればSQL Serverネイティブの圧縮で十分な場合が多いです。一方、大規模環境、コンプライアンスが求められる環境、ミッションクリティカルな環境では、i2Backupがより完全で信頼性の高いソリューションとなります。圧縮、インテリジェントな帯域制御、エンタープライズ向けバックアップ管理を単一プラットフォームに統合しています。
以下のベストプラクティスを守ることで、圧縮処理を効率的かつ信頼性の高いものにし、回避可能なエラーを防げます。圧縮ファイルのメリットを最大限に引き出しつつ、バックアップの完全性を守る上で重要です。
SSMSまたはT‑SQLを問わず、すべての圧縮バックアップコマンドに`WITH CHECKSUM`句を追加してください。バックアップ処理中にデータ完全性を検証し、圧縮によって見えにくくなる元データまたはバックアップファイルの破損を検知し、圧縮バックアップがリストア可能であることを保証します。
大きなデータベースでは、圧縮と併せてバックアップストライピングを使用します。圧縮バックアップを複数のディスクファイル／ボリュームに分割します。単一ドライブのI/O競合を抑え、圧縮バックアップとリストアの時間を短縮し、巨大な圧縮ファイルの管理や転送を容易にします。
既に圧縮済みのデータを再度圧縮しないでください。CPUリソースを浪費する上、ファイルサイズが増大する、またはほとんど削減効果が得られない場合があります。ZIP、PDF、暗号化ファイル、圧縮済みメディアなどを含むバックアップでは圧縮を無効にし、SQL Serverの圧縮済みバックアップファイルに対してOSレベルの圧縮を適用しないでください。
T‑SQLバックアップコマンドで`MAXTRANSFERSIZE = 131072 (128KB)`を設定し圧縮効率を最適化します。この128KBブロックサイズはSQL Serverの圧縮エンジンに適合し、オーバーヘッドを抑え、多くのデータベースワークロードにおいて圧縮率とバックアップ速度を向上させます。
バックアップが正常完了したと安易に考えず、作成直後に圧縮バックアップを必ず検証してください。SSMSのバックアップ完全性検証ツール、または`RESTORE VERIFYONLY`のT‑SQLコマンドを使用し、圧縮ファイルが破損しておらず読み取り・リストア可能であることを確認し、重要な復旧局面で破損が発覚する事態を回避します。
Q1：SQL Serverバックアップ圧縮はリストア時間に影響しますか？
通常はリストアが高速になります。CPUはデータの展開処理を行うものの、ディスクから読み込むデータ量が大幅に減少します。ほとんどの環境でボトルネックはディスク速度であるため、圧縮バックアップの方が非圧縮より速くリストアできます。
Q2：バックアップ圧縮におけるSQL Server StandardとEnterpriseエディションの違いは？
古いSQL Serverバージョンではバックアップ圧縮はEnterpriseエディションのみで利用可能でした。2016以降はStandard、Enterprise両エディションで圧縮バックアップの作成に対応しています。Expressエディションは圧縮バックアップのリストアのみ可能で、作成はできません。
Q3：差分バックアップやログバックアップも圧縮できますか？
はい。SQL Serverのバックアップ圧縮は完全、差分、トランザクションログ、すべてのバックアップ種別に対応します。ログデータが大量に生成される高負荷データベースでは、ログバックアップの圧縮が特に有用です。
Q4：圧縮を有効にするとバックアップ作成処理は遅くなりますか？
いいえ、通常は速くなります。圧縮によりCPU使用率は上昇しますが、ディスクへ書き込むデータ量が大幅に削減されます。多くのサーバーではディスクI/Oが主なボトルネックであるため、書き込むデータが少なくなることでバックアップ完了が速くなります。
Q5：期待できる圧縮率はどの程度ですか？
一般的な圧縮率は50‑80％で、バックアップファイルは元データの2‑5分の1のサイズになります。テキストや数値データで効果が大きく、暗号化データ、画像やPDFなどのファイルでは圧縮によるサイズ削減効果はほとんど得られません。
SQL Serverバックアップ圧縮はすべてのDBAにとって重要なツールです。バックアップ処理の遅延とストレージコスト高騰の課題を解決します。ファイルサイズを削減することで領域を節約し、保守タスクをより速く完了できます。
本記事ではSQL Serverでバックアップ圧縮を有効にする4つの方法を紹介しました。手動作業にはSSMS、自動スクリプトにはT‑SQLを使用できます。またインスタンスレベルの既定設定や、最高のパフォーマンスを得るための高度なZSTDアルゴリズムも利用可能です。
さらに良い結果を得たい場合はi2Backupのようなプロフェッショナルツールの活用を検討してください。これらのソリューションはバックアップ圧縮戦略をより信頼性が高く、管理しやすいものにします。今日からサーバーの既定値に圧縮を設定し、時間とコストの節約を始めましょう。
