「SQL Server バックアップ アクセス拒否」エラーは、高可用性（HA）とデータ整合性の維持が重要な場面において、データ保護業務を妨害する可能性があります。SQL Server 2019、2022および旧バージョンで発生することの多いエラー5（このアクセス問題に関連）は、基本的にSQL Serverサービスアカウントの権限不足が原因です。SSMSまたはSQLエージェントのログにこのエラー（エラー5）が表示される場合、Windowsが書き込み要求をブロックしています。
本ガイドでは、根本原因と実行可能な解決方法を解説します。サービスアカウントの設定、NTFS権限の管理、ネットワークセキュリティの調整方法を学び、バックアップのアクセス拒否問題の再発を防ぎます。
SQL Server権限エラーに悩まされなくなりましょう
i2BackupはSQL Serverバックアップのスケジューリングと管理を自動化し、エラー5を引き起こす権限のギャップを解消します。i2Backup無料トライアル »
SQL Server OSエラー5の主な原因
技術的な細かい要因は複数存在しますが、アクセス拒否の大半は単純な権限不足に起因します。SQL Serverバックアップでエラー5 アクセス拒否が発生する主な理由は以下の通りです。
SQLサービスアカウントのフォルダ権限不足 ：最も多い原因です。SQL Serverを実行するアカウントに、バックアップ先フォルダに対するNTFSの「書き込み」または「変更」権限が付与されていません。
無効なバックアップパス ：パスの入力ミスまたはフォルダ削除により、SQL Serverが.bakファイルを書き込めず、エラー5が発生します。
ネットワーク共有フォルダへのアクセス非対応 ：ローカルSQLサービスアカウント（例：NT Service\MSSQLSERVER）はネットワーク共有の認証を行えず、バックアップアクセス拒否エラーとなります。
UAC/Windowsセキュリティ制限 ：厳格なUACまたはグループポリシー設定により、SQLプロセスが保護されたフォルダへアクセスできなくなります。
セキュリティソフトによるブロック ：ウイルス対策・ランサムウェア対策ツールが大容量.bakファイルを脅威と判定してロックし、エラー5を引き起こします。
リモートパスの誤った使用 ：リモートバックアップ時にサーバー側ではなく手元の端末のファイルパスを指定すると、アクセスが失敗します。
SQLエージェントアカウントの不整合 ：SQLエージェントアカウントの権限がSQLデータベースエンジンのアカウントより少ない場合、スケジュールバックアップが失敗します。
復元時のファイルロック ：別プロセスによりロックされた既存のデータベースファイルに上書き復元を実行すると、権限拒否エラーが発生します。
手順別解決方法（コマンド・スクリーンショット付き）
SQL Serverバックアップのアクセス拒否エラー（エラー5を含む）を解決するには、Windowsセキュリティ設定をSQL Serverの要件に合わせます。最も多い原因であるフォルダ権限の不足から順に、代表的な問題に対する実行可能な修正手順を記載します。
修正1 – SQL Serverサービスアカウントに権限を付与する
SQL Serverのバックアップアクセス拒否の多くは、SQL Serverサービスアカウントにバックアップフォルダへの書き込み権限がないことが原因です。以下の手順で解決します。
SQL Serverサービス をクリックします。NT Service\MSSQLSERVERCORP\sql_svcプロパティ を選択、セキュリティ タブを開きます。編集 をクリック、追加 を押して先ほど確認したサービスアカウント名を正確に入力し、OK をクリックします。適用 をクリックします。icacls
:: SQLアカウントにフル権限を付与し、新規ファイルへ権限を継承させます。
:: C:\SQLBackups と NT Service\MSSQLSERVER は実環境の値に置き換えてください。
icacls "C:\SQLBackups" /grant "NT Service\MSSQLSERVER":(OI)(CI)F /T
以上の手順で、バックアップアクセス拒否エラーを引き起こす根本的な権限のギャップが解消されます。サービスアカウントを変更した直後は、SQL Serverサービスを再起動し、新しいセキュリティトークンを有効化してください。
修正2 – まずローカルドライブへバックアップを実行する
ネットワーク共有またはマップドドライブへバックアップしようとしてアクセス拒否が発生する場合、多くはWindowsのサービス向けネットワーク認証の仕組みに起因します。経験上、OSエラー5はSQL Serverサービスアカウントに他マシンへアクセスするための「ネットワークトークン」がないため発生するケースが頻出します。
問題がネットワーク側にあるのかフォルダ権限にあるのか切り分けるため、下記の手順を実施します。
サーバーのローカルCドライブまたはDドライブ直下に新規フォルダを作成 します（例：C:\LocalBackupTest 修正1のicacls手法を使用し、SQL Serverサービスアカウントにこのローカルフォルダの「フルコントロール」権限を付与 します。SQL Server Management Studio（SSMS）でT‑SQLバックアップコマンドを手動実行 し、このローカルパスへ書き込みができるか確認します。
-- ネットワーク権限の問題を回避するためローカルドライブへテストバックアップ
BACKUP DATABASE [YourDatabaseName]
TO DISK = 'C:\LocalBackupTest\Test.bak'
WITH INIT, STATS = 10;
GO
実行結果を確認 ：このローカルバックアップが成功する場合、SQL Serverエンジン自体は正常であり、バックアップアクセス拒否エラーはネットワーク設定に起因することが証明されます。マップドドライブは使用しない ：Z:\\\ServerName\BackupShare\
修正3 – ネットワーク共有（NAS/SMB）アクセスを設定する
ネットワーク共有（NAS/SMB）へのデータベースバックアップのアクセス拒否を解決するには、共有権限とNTFS権限の2層の権限を確認する必要があります。NTFS設定が正しくても共有権限を見落とすDBAは多いため、以下の手順で適切に設定します。
サービスアカウント種別を確認 ：SQL Serverサービスがドメインアカウント（例：CORP\sql_svcネットワークバックアップにLocalSystem/NetworkServiceを使用しない ：リモート共有へのバックアップにLocalSystemLocalSystem共有権限を設定 ：共有をホストするリモートサーバー上で、フォルダを右クリック → プロパティ ＞ 共有 ＞ 詳細な共有 ＞ アクセス許可 を開きます。SQL Serverサービスアカウントを追加し、変更および読み取り権限を付与します。NTFS権限を設定 ：同じリモートフォルダのセキュリティ タブを開き、SQL Serverサービスアカウントを追加して変更またはフルコントロール権限を付与します。共有権限とNTFS権限のうち、より制限の厳しい方が適用されることに注意してください。UNC（汎用名前付け規約）パスを使用 ：バックアップスクリプトでは常に\\ServerName\ShareName\Folder\Backup.bakT‑SQLでアクセスをテスト ：有効な場合はxp_cmdshell
-- SQL Serverからネットワークディレクトリが参照できるか確認
EXEC xp_cmdshell 'dir "\\RemoteServer\BackupShare\"';
GO
Tip： Windows以外のNAS機器の場合、SQLサービスアカウントのSIDをマッピングするか、SQLドメインアカウントと同じ名前・パスワードのNASローカルユーザーを作成し、SMB認証要件を満たしてください。
修正4 – SQL Serverサービスアカウントを安全に変更する
複雑なネットワーク環境におけるアクセス拒否エラーを解消する最速の手段の一つが、SQL Serverサービスアカウントを専用のドメインユーザーへ変更することです。SQLエンジンが現在LocalSystemNT Service\MSSQLSERVER
アカウント変更は標準的な手順ですが、誤った操作はサービス起動失敗を引き起こします。以下の手順で安全に変更を実施します。
SQL Server構成マネージャーを開きます 。Windowsのサービス(services.msc)から変更しないでください。セキュリティ依存関係やレジストリキーが正しく更新されません。SQL Serverサービス 」を開き、一覧から対象インスタンスを探します。SQL Server (MSSQLSERVER)プロパティ を選択します。ログオン 」タブを開き、「このアカウント」を選択し、専用ドメインユーザーアカウント（例：YOURDOMAIN\sql_backup_svcOK をクリックします。構成マネージャーは新しいアカウントにデータベースエンジン実行に必要なローカル権限を自動で付与します。サービスを再起動 します。バックアップを再実行 します。エンジンに固有のIDが割り当てられたため、このユーザーにローカルまたはネットワークフォルダのフルコントロール権限を簡単に付与できるようになります。
注記： 最新環境ではグループ管理サービスアカウント(gMSA)の使用を推奨します。パスワードローテーションの手間をなくし、パスワード期限切れによるアクセス拒否問題を回避できます。
修正5 – SQLエージェントジョブを権限エラーなしで実行する
DBAがよく遭遇する悩みとして、SSMSからの手動バックアップは成功するのに、スケジュール設定したSQLエージェントジョブだけがSQL Serverバックアップアクセス拒否エラーで失敗するケースがあります。これは手動バックアップは自身のWindows IDで実行されるのに対し、スケジュールジョブはSQL ServerエージェントサービスのID（多くの場合データベースエンジンアカウントと異なる）で実行されるため発生します。スケジュールジョブのエラー5を解決する手順は以下の通りです。
SQLエージェントサービスアカウントを確認 ：SQL Server構成マネージャーを開き、SQL Serverエージェントの「ログオン先」アカウントを確認します（データベースエンジンアカウントと異なる場合が多い）。エージェントアカウントに権限を付与 ：修正1と同様にバックアップフォルダのプロパティを開き、SQL Serverエージェントアカウントに「変更」または「フルコントロール」権限が付与されていることを確認します。ジョブの所有者を確認 ：SSMSにてSQL Serverエージェント ＞ ジョブを開き、対象のバックアップジョブを右クリック ＞ プロパティ ＞ 全般 タブを開き所有者 を確認します。バックアップパスにアクセス権のないローカルユーザーが所有者の場合、ジョブが失敗する可能性があります。プロキシアカウントを調整（任意） ：ジョブステップにプロキシアカウントを使用している場合は、プロキシのIDにバックアップ先フォルダのNTFS権限が付与されていることを確認します。SQLエージェントサービスを再起動 ：エージェントアカウントまたはADグループメンバーシップを更新した場合、サービスを再起動し新しいセキュリティトークンを有効化します。
Tip： SQL Serverバックアップのアクセスエラーを繰り返さないために、SQLエンジンとSQLエージェントを同じドメインサービスアカウントで実行してください。
修正6 – ウイルス対策・ランサムウェア対策によるブロックを解消する
アカウント権限が正しく設定されていても、OSエラー5が発生する場合、ウイルス対策(AV)、EDR、ランサムウェア対策ツールが原因の可能性があります。これらのツールはsqlservr.exeによる大容量.bakファイルの書き込みを不審な動作と判定する場合があります。以下の手順で対処します。
セキュリティログを確認 ：Windows Defender、CrowdStrikeなどAV/EDRツールのログを確認し、sqlserver.exeバックアップディレクトリを除外設定に追加 ：バックアップフォルダ（例：D:\SQLBackupsSQLプロセスを信頼対象に追加 ：sqlserver.exe sqlagent.exeバックアップファイル拡張子を除外 ：ポリシー上許可される場合は.bak .trn Windows Defenderの制御されたフォルダーアクセスを調整 ：この機能を無効にするか、SQL Serverを許可アプリに追加してください。原因不明のアクセス拒否のよくある要因です。
修正7 – 復元失敗（上書き・ファイルロックの問題）
SQL Serverバックアップのアクセス拒否エラーはバックアップ時だけでなく復元時にも発生します。多くはSQLエンジンが既存の.mdf/.ldfファイル（別プロセスにロックされている）を上書きできない、または復元先フォルダに対する「削除/変更」権限が不足していることが原因です。
復元関連のアクセス拒否を解決する手順は以下の通りです。
復元先フォルダの権限を検証 ：SQL Serverサービスアカウントに復元先フォルダ（バックアップフォルダとは異なる場合が多い）のフルコントロール権限が付与されていることを確認します。ファイルの読み取り専用状態を確認 ：既存データベースに上書き復元する場合、対象の.mdf/.ldfファイルが読み取り専用になっていないか確認します。ファイル右クリック ＞ プロパティ より読み取り専用のチェックを外します。WITH REPLACE句を使用 ：既存データベースに上書きする場合、T‑SQL復元スクリプトにREPLACE
RESTORE DATABASE [YourDB]
FROM DISK = 'C:\Backups\YourDB.bak'
WITH REPLACE, -- 既存データベースファイルを上書き
RECOVERY;
WITH MOVEでファイルを再配置 ：対象サーバー上に元のファイルパスが存在しない場合、MOVE 既存接続を切断 ：復元前にデータベースをSINGLE_USER
i2Backupで「SQL Serverバックアップ アクセス拒否」を即時解決
手動による権限管理はバックアップ戦略の弱点になりがちで、OSエラー5のようなエラーを引き起こします。長期的な解決策として、i2Backup
i2Backupの主な機能
幅広い互換性 ：Windows、Linux、Unix、仮想化環境（VMware、Hyper‑Vなど）上のSQL Server（Oracle、MySQLなど他の主要データベースも対応）に正式な互換認証を持ち、多様なエンタープライズ環境で確実な保護を実現します。一元的でインテリジェントな管理 ：分散アーキテクチャをベースに、使いやすいB/Sウェブインターフェースにより一元制御とバックアップスケジューリングが可能です。即時アラートとリアルタイムステータス更新によりITチームはタスク進捗とシステム状態を把握できます。効率的なデータライフサイクル管理 ：バックアップ、重複排除、改ざん防止、復旧、安全なクリーンアップを自動化。カスタマイズ可能な保持ポリシーとスマートクリーンアップにより運用負荷を軽減しストレージを最適化します。高速かつ柔軟な復旧 ：ファイル単位、特定時点、クロスプラットフォーム復元（物理サーバー、VM、クラウド）に対応。VMの瞬時復旧によりダウンタイムを最小限に抑え、ドライバー自動インストール付きのベアメタル/クラウド復旧もサポートします。総合的な監視とレポーティング ：バックアップ動作をリアルタイムで可視化。メール・SMSアラートにより管理者にタスク状況を通知し、潜在的な問題へ迅速に対応可能です。
管理の一元化、セキュリティの自動化、根本的な権限ギャップへの対処により、i2Backupはデータを保護する長期的なソリューションとなります。
VIDEO
SQL Serverバックアップアクセス拒否エラーの予防方法
問題が起きてからのトラブルシューティングはストレスが伴い、データ損失リスクもあります。事前の管理により安定したバックアップ実行時間を確保します。SQL Serverバックアップエラー5（アクセス拒否）の再発を防ぐ実証済みの戦略は以下の通りです。
専用のバックアップディレクトリを使用 ：ドライブ直下やシステムフォルダは避けます。専用フォルダ（例：S:\SQLBackups）を作成し、事前にSQL Serverサービスアカウントに必要なNTFS権限を付与してください。バックアップ処理を分離し、セキュリティ監査も容易になります。サービスアカウントを標準化 ：LocalSystemのようなデフォルトアカウントを避け、インスタンスごとにアカウントを混在させないでください。ドメインサービスアカウントまたはgMSAを1つ使用し、ネットワーク共有を含むSQL環境全体で一貫した権限適用を実現します。毎週バックアップと復元をテスト ：検証されていないバックアップは無価値です。毎週自動ジョブをスケジュールし、ランダムなデータベースをテスト環境へ復元して、サービスアカウントが完全な読み書き権限を持つことを確認し、緊急時のバックアップアクセス拒否を防ぎます。権限チェックを自動化 ：PowerShellスクリプトまたはxp_fileexistを使用したT‑SQLジョブで、バックアップ実行前にバックアップディレクトリのアクセス可否を検証します。パスに到達できない場合のメールアラートを設定し、バックアップが失敗する前に問題に対処します。SQLエージェントの失敗を監視 ：データベースメールとSQLエージェントアラートをエラー5向けに設定し、発生時に即座にSMS/メール通知を受け取り、解決の遅延を回避します。
まとめ
SQL Serverバックアップアクセス拒否エラー（OSエラー5）を解決する鍵は、SQL Serverサービスアカウントが対象ディレクトリに対し明示的なNTFS権限と共有権限を持つようにすることです。サービスのIDを特定し、バックアップパスを標準化し、i2Backupのようなプロフェッショナルツールを活用することで、これらの権限のギャップを根本的に解消できます。
本番環境で障害が発生してからセキュリティ設定のずれに気付くことのないよう、毎週バックアップと復元をテストし、権限が維持され、災害復旧計画が真に堅牢であることを確認することを最後のアドバイスとします。
By:
