データベースサーバー障害時の初動対応｜復旧前に確認すべきこと

本当に信頼できるデータ
復旧業者3選をチェック

2026年10月、IDCフロンティアが提供するクラウドサービスでランサムウェア攻撃による障害が発生し、495の企業・自治体が影響を受けました。同社は仮想サーバーの停止・暗号化を公表し、代替環境への移行やバックアップデータの取り出しなどの復旧支援を進めています。

この事例は、サーバーやクラウド基盤の障害が、企業の業務システム全体に影響する可能性を示しています。ただし、同事例で特定のデータベース製品が破損したと確認されたわけではありません。

企業の基幹システムでは、顧客情報、受発注情報、在庫情報、会計データなどをデータベースで管理しています。そのため、データベースサーバーに障害が発生すると、業務停止だけでなく、重要なデータの消失や不整合につながるおそれがあります。

ただし、データベースに接続できなくなったからといって、保存されているデータそのものが破損しているとは限りません。サーバー、ストレージ、データベース管理システム（DBMS）、アプリケーションなど、問題が発生している箇所によって復旧方法は異なります。

特に注意したいのは、原因を確認せずに再起動や修復を繰り返すと、復旧可能だったデータを失う場合があることです。

本記事では、法人の情報システム担当者やデータベース管理者に向けて、データベースサーバー障害時の初動対応、原因の切り分け、製品別の確認事項、バックアップやログを利用した復旧方法、専門業者への相談について解説します。

※実際の復旧手順は、DBMSの製品・バージョン、バックアップ構成、ストレージの状態などによって異なります。本番環境に対する修復操作は、必要なデータを保全したうえで、DBA（データベース管理者）や保守会社などの専門家と連携して判断してください。

データベースサーバーで障害が発生したときの初動対応

データベースサーバーに障害が発生した場合、最初に行うべきなのは、データをできるだけ早く復元することではありません。

まずは障害が発生している範囲を把握し、データの状態を悪化させる操作を避けながら、調査と復旧に必要な情報を保全することが重要です。

法人のデータベース障害では、次の5つを基本的な初動対応として確認しましょう。

① 業務への影響を確認し、不要な書き込みを抑える

データベースに障害が発生した場合は、まずどの業務システムに影響が出ているか確認します。

データベースへの接続が完全に停止している場合もあれば、一部の処理だけが失敗している場合もあります。

例えば、次のような状況を確認しましょう。

• 基幹システムや業務アプリケーションが利用できるか
• データの参照と更新のどちらに問題があるか
• 特定のテーブルやデータだけでエラーが発生しているか
• バッチ処理や自動更新処理が継続しているか
• 複数のアプリケーションから同じ障害が発生しているか

データの破損や不整合が疑われる場合は、アプリケーションからの不要な更新処理を停止することも検討します。

ただし、処理を突然停止すると、実行中のトランザクションや関連システムに影響することがあります。停止する対象と方法は、システム構成を確認して判断してください。

② サーバー・ストレージ・DBの状態を確認する

データベースに接続できない場合でも、必ずしもデータベースファイルが破損しているとは限りません。

障害の原因として、次のようなものが考えられます。

• 物理サーバーや仮想サーバーの停止
• ストレージやRAIDの障害
• OSやDBMSのサービス停止
• ネットワーク接続の問題
• 認証情報やアクセス権限の問題
• データベースファイルの破損
• ディスク容量不足
• アプリケーション側の設定不備

例えば、データベースのサービスが正常に動作していても、ネットワークや認証の問題でアプリケーションから接続できない場合があります。

一方、ストレージに物理障害が発生している場合は、DBMSに対する修復操作だけでは解決できない可能性があります。

原因を決めつけず、サーバーからアプリケーションまで段階的に確認しましょう。

③ ログ・データファイル・設定情報を保全する

復旧作業を始める前に、データベースの状態を把握するための情報を保全します。

確認したい情報には、以下のようなものがあります。

• DBMSのエラーログ
• OSやストレージのイベントログ
• データベースファイル
• トランザクションログ
• データベースの設定情報
• 障害発生日時と直前の操作履歴
• バックアップの取得履歴

データベースでは、データファイルだけでなく、トランザクションログや管理情報が復旧に必要になる場合があります。

そのため、用途が分からないファイルを削除したり、別のファイルで上書きしたりしないよう注意してください。

また、物理ストレージの故障が疑われる場合は、ファイルをコピーする作業自体が機器に負荷をかける可能性があります。ストレージの状態に応じて、保全方法を専門家と相談しましょう。

④ バックアップの取得状況を確認する

次に、復旧に利用できるバックアップがあるか確認します。

データベースのバックアップには、製品や構成によってフルバックアップ、差分・増分バックアップ、ログバックアップなどがあります。

確認したいのは、次のような内容です。

• 最後に正常なバックアップを取得した日時
• バックアップの保存場所
• フルバックアップや差分バックアップの有無
• トランザクションログなどの取得状況
• バックアップファイルの正常性
• 復元先として利用できる環境の有無
• どの時点のデータまで復旧できるか

バックアップが存在していても、必要なログが不足している場合は、希望する時点まで復旧できないことがあります。

また、バックアップファイルが破損していたり、暗号化されていたりすると利用できない可能性があります。

可能な範囲で別環境への復元テストを行い、利用できる状態か確認することが重要です。

⑤ 復旧作業の前に関係者へ連絡する

法人のデータベース障害では、情報システム担当者だけで復旧作業を進めることが難しい場合があります。

障害の種類に応じて、次の関係者への連絡を検討しましょう。

• 社内のデータベース管理者（DBA）
• 情報システム部門やシステム責任者
• 業務システムの開発・保守会社
• サーバー・ストレージの保守会社
• データ復旧専門業者
• 不正アクセスが疑われる場合のセキュリティ専門会社

特に重要な業務データを扱っている場合は、復旧によって失われる可能性があるデータの範囲を、業務部門や責任者と共有しておく必要があります。

データベース障害時の初動対応チェックリスト

復旧作業を始める前に、以下の項目を確認してください。

• □ 障害が発生した日時を記録した
• □ 影響を受けている業務システムを特定した
• □ DBサービスやサーバーの状態を確認した
• □ ストレージの物理障害がないか確認した
• □ エラーログや設定情報を保全した
• □ データファイルとトランザクションログの状態を確認した
• □ バックアップの保存先と取得日時を確認した
• □ 不要な更新処理の継続有無を確認した
• □ 復旧に関わる社内外の担当者へ連絡した
• □ 本番環境への修復操作を実施する前に影響範囲を確認した

データベース障害の原因を切り分ける復旧判断フロー

データベース障害では、接続できない、サービスが起動しない、データを読み取れないなど、さまざまな症状が発生します。

しかし、症状が似ていても原因は異なるため、障害箇所とデータの残存状況を確認してから復旧方法を選ぶことが重要です。

サーバー・ストレージ・DBMS・アプリケーションのどこに問題があるか確認する

代表的な障害と、主に確認したい箇所を整理しました。

障害状況	主な確認箇所	復旧の方向性
DBに接続できない	ネットワーク、認証、DBサービス	接続設定やサービス状態を確認する
DBサービスが起動しない	DBMS、設定、ログ、ストレージ	エラー情報から原因を切り分ける
データファイルが破損している	DBファイル、物理ストレージ	原本を保全し、バックアップからの復元を検討する
特定のテーブルが読み取れない	DBの論理構造、データファイル	整合性の確認と復旧方法を検討する
データを誤って削除した	操作履歴、バックアップ、ログ	時点指定復旧の可否を確認する
ディスク障害が発生した	物理ディスク、RAID、SAN・NAS	ストレージの保全と専門調査を検討する
不正アクセスが疑われる	認証、DB、ネットワーク、ログ	証拠保全・セキュリティ調査を優先する

例えば、データベースに接続できなくても、ネットワークの障害であればデータファイル自体は正常な可能性があります。

一方、ストレージの物理障害やファイルの破損が原因の場合は、DBサービスの再起動を繰り返すことで状況が悪化するおそれがあります。

バックアップとログの状態から復旧方法を判断する

障害原因を確認したら、次に利用できるバックアップやログの状態から復旧方法を検討します。

データの状態	検討する対応
正常なバックアップがある	別環境でバックアップを復元し、データの正常性を確認する
バックアップと必要なログがある	条件を満たす場合、特定時点への復旧を検討する
バックアップはあるがログが不足	復元可能な時点とデータ損失の範囲を評価する
バックアップがない	残存ファイルやレプリカを確認し、専門調査を検討する
サイバー攻撃が疑われる	証拠保全と安全な復旧環境の確保を優先する

特に注意したいのは、バックアップの存在だけで復旧できる時点が決まるわけではないということです。

データベースの製品や復旧設定、ログの取得状況によって、復旧可能な範囲は異なります。

復旧前に「どの時点のデータへ戻すか」を決める

データベースを復旧する際は、単に起動できる状態へ戻すのではなく、どの時点のデータが必要なのかを確認することが重要です。

例えば、午前10時に誤ってデータを削除した場合、午前9時のバックアップへ戻すと、午前9時から10時までの正常な更新も失われる可能性があります。

必要なログが揃っている場合には、誤操作の直前など、特定時点への復旧を検討できることがあります。

ただし、時点指定復旧が可能かどうかは、DBMSの仕様やバックアップ構成、ログの連続性によって異なります。

復旧時点を決める際は、以下の点を整理しましょう。

• 障害が発生した日時
• 最後に正常なデータを確認できた時刻
• バックアップとログが残っている期間
• 失われる可能性がある更新データ
• 業務上許容できるデータ損失の範囲
• ほかのシステムとのデータ整合性

法人では、RPO（目標復旧時点）をあらかじめ設定しておくことも重要です。

RPOは、障害発生時にどの程度過去の時点までのデータ損失を許容するかを示す目標です。実際の復旧可能時点がRPOを満たしているかも確認しましょう。

復旧したいデータの優先順位を決めるチェックシートを見る

データベース障害時に避けたい操作とデータ保全の注意点

データベースでは、複数のファイルやログが相互に関係しながらデータの整合性を保っています。

そのため、一般的なファイルの破損と同じ感覚で修復や削除を行うと、復旧できる可能性があったデータまで失われる場合があります。

原因不明のまま再起動・修復を繰り返さない

データベースサービスの再起動によって、一時的な問題が解消する場合はあります。

しかし、ストレージ障害やデータファイルの破損が発生している場合は、再起動時に自動復旧処理やディスクへのアクセスが発生し、状況が変化する可能性があります。

特に物理ディスクの異常が疑われる場合は、繰り返し読み書きを行うことで障害が悪化するおそれがあります。

再起動や修復を実施する前に、エラーログ、ストレージの状態、バックアップの有無などを確認しましょう。

データファイルやトランザクションログを削除・上書きしない

データベース製品ごとに、データや復旧情報を保持するファイルの種類は異なります。

DBMS	主な関連ファイル・ログ
SQL Server	MDF・NDFなどのデータファイル、LDFなどのトランザクションログ
Oracle Database	データファイル、制御ファイル、オンラインREDOログ、アーカイブログ
MySQL	データディレクトリ、InnoDB関連ファイル、REDOログ、バイナリログ
PostgreSQL	データディレクトリ、WALファイル、設定ファイルなど

これらのファイルは、それぞれ異なる役割を持っています。

例えば、トランザクションログやWALなどは、障害発生後の整合性回復や特定時点への復旧に利用される場合があります。

役割を確認せずにファイルを削除・移動・上書きすると、復旧に必要な情報が失われる可能性があります。

修復ツールや強制復旧オプションの使用には注意する

DBMSには、データベースの整合性を検査したり、障害から復旧したりするための機能が用意されています。

ただし、修復機能によっては、データの一部を失う可能性があります。

例えばSQL Serverの「REPAIR_ALLOW_DATA_LOSS」は、データ損失を伴う可能性がある修復オプションです。

Microsoftは、DBCC CHECKDBによって検出された整合性エラーについて、正常なバックアップからの復元を基本的な回復方法として推奨しています。

バックアップから復元できない場合に修復を検討することはありますが、修復操作によってデータの一部が削除されたり、業務上の整合性が失われたりする可能性に注意が必要です。

重要なデータを扱う場合は、原本を保全したうえで、可能な範囲で検証環境を用意し、DBAや保守会社とともに復旧方法を判断しましょう。

参考：Microsoft Learn「DBCC CHECKDB」

SQL Server・Oracle・MySQL・PostgreSQLの障害別確認ポイント

データベースサーバーの復旧では、利用しているDBMSによって確認すべきファイルやログ、復旧機能が異なります。

ここでは、代表的な4種類のDBMSについて、障害発生時に確認したいポイントを紹介します。

SQL Server｜SUSPECT状態・MDF/LDF破損時の確認事項

Microsoft SQL Serverでは、データベースがSUSPECT状態になるなど、正常に利用できなくなる場合があります。

SUSPECT状態は、SQL Serverがデータベースの復旧処理を正常に完了できない場合などに発生することがあります。

原因として、データファイルやトランザクションログの問題、ストレージ障害、アクセス権限の問題などが考えられます。

主に確認したい項目は次のとおりです。

• SQL Serverエラーログの内容
• MDF・NDF・LDFファイルの残存状況
• データファイルの保存先とアクセス権限
• ストレージのI/Oエラー
• DBCC CHECKDBによる整合性確認の可否
• フル・差分・ログバックアップの取得状況
• 復旧モデルとログの状態

SQL Serverでは、DBCC CHECKDBによってデータベースの整合性を確認できますが、障害のあるストレージで実行すると負荷がかかる可能性があります。

また、EMERGENCYモードやデータ損失を伴う修復オプションは、復旧の最終手段として慎重に判断する必要があります。

正常なバックアップがある場合は、原則としてバックアップからの復元を優先して検討しましょう。

Oracle Database｜データファイル・REDOログ・制御ファイルの確認

Oracle Databaseでは、データファイル、制御ファイル、REDOログなどがデータベースの稼働と復旧に関係しています。

障害が発生した場合は、どのファイルや機能に問題が発生しているかを確認します。

• データファイルの状態
• 制御ファイルの状態
• オンラインREDOログの状態
• アーカイブログの取得状況
• RMANバックアップの有無
• ARCHIVELOGモードの設定
• Oracleのアラートログやエラー情報

Oracle Databaseでは、RMAN（Recovery Manager）を利用したバックアップやリカバリーが提供されています。

正常なバックアップと必要なREDO情報が揃っている場合には、障害状況に応じた復旧を検討できます。

また、環境や設定によってはOracle Flashbackなどの機能を利用できる場合もあります。

ただし、必要なログやバックアップが不足している場合、希望する時点まで復旧できないことがあります。

参考：Oracle Database「Performing Backup and Recovery」

MySQL｜データファイル破損・起動不能時の確認事項

MySQLでデータベースサーバーが起動しない場合は、エラーログやデータディレクトリ、ストレージの状態などを確認します。

InnoDBを利用している環境では、データファイルやREDOログなどが障害復旧に関係します。

また、バイナリログを取得している場合は、バックアップと組み合わせた時点指定復旧を検討できることがあります。

主に確認したい項目は次のとおりです。

• MySQLエラーログ
• データディレクトリの状態
• InnoDB関連ファイルの状態
• バックアップの取得日時
• バイナリログの取得・保存状況
• レプリカの有無と同期状態
• 物理ストレージの障害の有無

MySQLには障害時にデータへアクセスするための強制復旧機能もありますが、設定内容によっては通常のデータベース運用とは異なる制約が生じます。

強制復旧を安易に実行するのではなく、必要なデータを保全し、公式ドキュメントや専門家の指示に沿って対応しましょう。

参考：MySQL 8.4 Reference Manual「Point-in-Time Recovery」

PostgreSQL｜WAL・データディレクトリ障害の確認事項

PostgreSQLでは、WAL（Write-Ahead Log）と呼ばれるログが、障害発生時の整合性回復などに利用されます。

WALは、データファイルへの変更を記録する仕組みで、クラッシュ後のリカバリーや、バックアップと組み合わせた時点指定復旧に関係します。

障害発生時には、以下の項目を確認しましょう。

• PostgreSQLログの内容
• データディレクトリの状態
• WALファイルの状態
• ベースバックアップの取得状況
• WALアーカイブの保存状況
• レプリカや待機系サーバーの状態
• ストレージの空き容量やI/Oエラー

PostgreSQLでは、適切に取得されたベースバックアップと連続したWALアーカイブを利用することで、特定時点への復旧が可能な場合があります。

ただし、WALファイルが一部欠落している場合や、バックアップの取得方法が適切でない場合は、復旧可能な時点が制限されることがあります。

また、通常の論理バックアップと、WALによる継続的な復旧に利用する物理バックアップは役割が異なります。

参考：PostgreSQL Documentation「Continuous Archiving and Point-in-Time Recovery」

データベースを復旧する4つの方法

データベースの復旧方法は、バックアップの有無、ログの状態、データファイルの破損状況などによって異なります。

代表的な方法として、以下の4つが挙げられます。

① 正常なバックアップから復元する

正常なバックアップが残っている場合は、そこからデータベースを復元できる可能性があります。

バックアップの種類やDBMSの仕様によって、データベース全体を復元する場合もあれば、特定のオブジェクトやファイルを対象とする場合もあります。

復元前には、次のような点を確認しましょう。

• バックアップが正常に取得されているか
• 必要なデータが含まれているか
• 復元先のDBMS・バージョンに互換性があるか
• 復旧時点以降に発生した更新が失われないか
• アプリケーションとの整合性を保てるか

可能であれば、本番環境へ直接復元する前に、別の検証環境で正常性を確認することが大切です。

② トランザクションログから特定時点へ復旧する

DBMSによっては、バックアップとトランザクションログなどを組み合わせることで、特定時点への復旧が可能な場合があります。

代表的な仕組みには、次のようなものがあります。

DBMS	復旧に利用する主なログ
SQL Server	トランザクションログバックアップ
Oracle Database	REDOログ・アーカイブログ
MySQL	バイナリログ
PostgreSQL	WAL・WALアーカイブ

例えば、誤ってデータを削除した場合、必要なバックアップとログが揃っていれば、誤操作の直前まで復旧できる可能性があります。

ただし、ログが保存されていない場合や、途中のログが欠落している場合は、希望する時点まで戻せないことがあります。

また、特定時点へ復旧すると、その時点以降に正常に実行された更新も失われる可能性があります。

復旧する日時は、業務担当者と確認したうえで慎重に決定しましょう。

③ レプリカ・待機系・別環境から復旧する

データベースの構成によっては、レプリカや待機系サーバーを利用して業務を再開できる場合があります。

ただし、レプリカが存在するだけで安全に復旧できるとは限りません。

例えば、誤削除や不正な更新がレプリカにも反映されている場合は、同じ問題が発生している可能性があります。

そのため、次のような点を確認する必要があります。

• レプリカの同期状態
• 障害や誤操作がレプリカにも反映されていないか
• フェールオーバーが可能な構成か
• 切り替えによるデータ損失の可能性
• アプリケーションの接続先変更に伴う影響
• 切り替え後の整合性と監視体制

レプリケーションは可用性向上に役立ちますが、独立したバックアップと同じものではありません。

バックアップとレプリカは、それぞれの役割を理解して利用しましょう。

④ 専門業者によるデータ抽出・復旧を検討する

正常なバックアップやレプリカを利用できない場合は、残存するデータファイルやストレージからの復旧を検討することがあります。

例えば、次のようなケースです。

• バックアップが存在しない
• データベースファイルが破損している
• 必要なログが失われている
• RAID・NAS・SANなどに障害がある
• ストレージの物理故障が疑われる
• 社内では修復操作のリスクを判断できない

ただし、データ復旧専門業者に依頼しても、すべてのデータを復旧できるわけではありません。

特にデータベースでは、ファイルの一部を取り出せたとしても、DBMSが正常に読み取れる状態とは限りません。

復旧を依頼する場合は、ファイルの抽出だけでなく、データベースとして利用できる状態まで確認可能かを相談しましょう。

データベース復旧後に確認したい整合性と業務再開の判断

データベースの復旧では、DBサービスが起動する状態になっただけで作業が完了したとは限りません。

法人の業務システムでは、データベース内のデータが正しく利用できることに加えて、アプリケーションや外部システムとの整合性も重要です。

データベースが起動するだけでは復旧完了とはいえない

復旧後には、以下のような項目を確認します。

• DBサービスが正常に起動するか
• 必要なデータベースやテーブルへアクセスできるか
• 主要なテーブルのデータ件数が妥当か
• インデックスや制約に異常がないか
• データの参照・更新を正常に実行できるか
• DBMSの整合性検査で問題が検出されないか
• 業務上必要なデータが揃っているか

データベース製品には整合性を確認する機能がありますが、それだけで業務データの正しさをすべて保証できるわけではありません。

例えば、データベースの構造上は正常でも、受注データと在庫データの更新時点が異なっている場合は、業務上の不整合が発生する可能性があります。

そのため、技術的な整合性と業務データの妥当性を分けて確認することが重要です。

アプリケーションとの整合性を確認する

データベースは、多くの場合、業務アプリケーションや外部システムと連携しています。

復旧後は、次のような確認を行いましょう。

• 基幹システムから正常に接続できるか
• ログイン・検索・登録・更新処理が正常に動作するか
• 定期バッチ処理を正常に実行できるか
• 外部APIとの連携が正常に動作するか
• ほかのシステムとデータの整合性が取れているか
• 復旧時点以降に発生した未反映データがないか

特に受発注、在庫、会計などのシステムでは、復旧時点の違いによってデータに差が生じる場合があります。

必要に応じて業務部門と連携し、未反映データの再入力や再連携について判断しましょう。

段階的な業務再開と再発防止

データベースの正常性を確認できたら、業務への影響を考慮しながら段階的にシステムを再開します。

再開後は、エラーログ、処理性能、ストレージ容量、バックアップの実行状況などを監視します。

また、障害の原因を踏まえて、以下のような対策を見直しましょう。

• バックアップの取得方法と保存先
• 定期的な復元テスト
• ストレージの容量・性能監視
• データベースの整合性チェック
• レプリケーションや待機系の構成
• 管理者権限と操作履歴の管理
• 障害時の連絡体制と対応手順

バックアップの取得だけでなく、実際に復元できることを定期的に確認しておくと、次の障害に備えやすくなります。

データ復旧後に行う再発防止チェックリストを見る

データベース障害で復旧業者へ相談すべきケース

データベース障害が発生した場合、DBMSの設定やバックアップ復元で対応できるケースもあれば、ストレージやデータファイルの専門的な復旧が必要になるケースもあります。

自社で対応できる範囲を見極め、必要に応じて適切な専門業者へ相談しましょう。

自社や保守会社だけで復旧できないケース

例えば、次のような場合は専門業者への相談を検討します。

• 正常なバックアップが存在しない
• バックアップ自体が破損している
• データファイルやトランザクションログが破損している
• RAIDや物理ストレージに障害が発生している
• 復旧操作によるデータ損失の危険性が高い
• 複数の業務システムに影響が及んでいる
• DBMSの復旧機能だけでは正常な状態に戻せない
• ランサムウェアや不正アクセスが疑われる

特に物理ストレージに障害がある場合は、DBMSの修復作業を繰り返す前に、ストレージの状態を確認することが重要です。

データ復旧業者とDB保守会社の役割の違い

データベース障害では、相談先によって対応できる内容が異なります。

相談先	主な対応範囲
DB保守会社・DBA	DBMSの設定、ログ解析、バックアップ復元、整合性確認
サーバー・ストレージ保守会社	ハードウェア、RAID、SAN・NASなどの診断・保守
データ復旧専門業者	破損した媒体や残存ファイルからのデータ抽出・復旧
セキュリティ専門会社	不正アクセス調査、証拠保全、被害範囲の確認、再感染防止

これらは一般的な役割の違いであり、実際の対応範囲は会社によって異なります。

データ復旧専門業者がデータベースの論理復旧まで対応している場合もあれば、媒体からのデータ抽出が中心となる場合もあります。

そのため、依頼前に「どの状態まで復旧できるか」を確認することが大切です。

NAS・RAID・サーバー対応のデータ復旧会社を比較する

法人向けデータ復旧会社を条件別に比較する

依頼前に整理しておきたい情報

データベース復旧について専門業者へ問い合わせる際は、次の情報を整理しておくと、状況を伝えやすくなります。

• DBMSの製品名とバージョン
• OSや仮想化環境の情報
• データベースの容量
• 障害が発生した日時
• エラーメッセージやログ
• データファイルとログの保存場所
• バックアップの取得日時と保存先
• 障害発生直前に実施した操作
• 希望する復旧時点
• 業務再開の優先度や希望納期

すべての情報が揃っていなくても相談は可能ですが、確認できている事実と不明な事項を分けて伝えることが重要です。

また、顧客情報や機密情報を含む場合は、NDA、作業場所、媒体の取り扱い、再委託の有無、作業報告書の提出可否なども確認しましょう。

データ復旧業者への問い合わせテンプレートを見る

データベースサーバーの復旧に関するよくある質問

データベースに接続できない場合、データは消えていますか？

必ずしもデータが消失しているとは限りません。

ネットワーク障害、認証エラー、DBサービスの停止、アプリケーション側の設定不備などによって接続できない場合もあります。

まずはサーバーやDBサービスの状態を確認し、データファイルが残っているかを調べましょう。

SQL ServerがSUSPECT状態でも復旧できますか？

障害の原因やバックアップの状態によっては復旧できる場合があります。

まずはエラーログやストレージの状態を確認し、正常なバックアップから復元できるか検討します。

データ損失を伴う可能性がある修復オプションは、安易に実行しないよう注意してください。

データベースファイルが破損した場合はどうすればよいですか？

まず、データファイルやログを不用意に削除・上書きしないことが重要です。

正常なバックアップがある場合は、別環境での復元を検討します。

バックアップがない場合やストレージに障害がある場合は、DB保守会社やデータ復旧専門業者に相談しましょう。

バックアップがなくてもデータベースを復旧できますか？

障害の種類や残存データによっては、復旧を検討できる場合があります。

例えば、正常なレプリカや別環境に保存されているデータが利用できる可能性があります。

ただし、バックアップが存在せず、重要なデータファイルやログが失われている場合は、完全な復旧が困難になることがあります。

誤って削除したテーブルを元に戻せますか？

バックアップやログ、DBMSの機能によっては、削除前の状態へ戻せる場合があります。

ただし、すべての環境で特定のテーブルだけを簡単に復元できるわけではありません。

復旧時点を戻すことで、ほかの正常な更新も失われる可能性があるため、検証環境で必要なデータを取り出すなど、影響範囲を考慮した方法を検討しましょう。

サーバーを再起動すればデータベース障害は復旧しますか？

一時的なサービス停止などであれば、再起動によって改善する場合があります。

しかし、ストレージ障害やデータファイルの破損が原因の場合、再起動を繰り返すことで状況が悪化する可能性があります。

再起動する前に、エラー内容やストレージの状態を確認しましょう。

ランサムウェアでデータベースサーバーが停止した場合はどうすればよいですか？

ランサムウェアや不正アクセスが疑われる場合は、通常の障害復旧とは異なる対応が必要です。

まずは感染が疑われる機器の隔離と証拠保全を優先し、セキュリティ専門家と連携して被害範囲や侵入経路を調査します。

データベースを復旧する際も、正常なバックアップと安全な復旧環境を確認することが重要です。

ランサムウェア被害時のデータ復旧初動について詳しく見る

まとめ｜データベース障害では復旧前の保全と整合性確認が重要

データベースサーバーに障害が発生した場合、接続できないからといって、保存されているデータそのものが失われたとは限りません。

サーバー、ストレージ、DBMS、アプリケーションなど、障害が発生した箇所によって復旧方法は異なります。

特に重要なのは、以下の3点です。

• 障害原因を確認する前に、データファイルやログを削除・上書きしない
• バックアップやログの状態を確認し、どの時点のデータへ復旧するか判断する
• DBサービスの起動だけでなく、データの整合性と業務システムの正常性を確認する

データベースでは、ファイルを取り戻せても、業務上必要なデータが整合していなければ、正常に利用できない場合があります。

そのため、復旧作業ではデータファイル、トランザクションログ、バックアップ、アプリケーションとの関係を考慮する必要があります。

自社だけで障害原因や復旧可能性を判断できない場合は、DB保守会社やサーバー保守会社、データ復旧専門業者などに相談しましょう。

法人向けのデータ復旧会社を比較したい場合は、以下のページも参考にしてください。

法人向けデータ復旧会社を比較｜NDA・作業報告書・オンサイト対応を調査

法人対応できるデータ復旧業者の選び方を見る

参考資料・情報確認日

本記事は、以下の公式情報を参考に作成しています。

• IDCフロンティア「【第7報】不正アクセスに関する調査結果および今後の対応について」（2026年10月27日）
• Microsoft Learn「DBCC CHECKDB」
• Microsoft Learn「報告されたデータベースの整合性エラーをトラブルシューティング」
• Oracle Database「Performing Backup and Recovery」
• MySQL 8.4 Reference Manual「Point-in-Time Recovery」
• PostgreSQL Documentation「Continuous Archiving and Point-in-Time Recovery」

情報確認日：2026年10月28日

※本記事は、法人向けのデータベース障害に関する一般的な初動対応と復旧判断を解説するものです。実際の作業では、DBMSの製品・バージョン、バックアップ構成、障害状況などに応じて、DBAや保守会社、データ復旧専門業者と連携して判断してください。

• その復元をあきらめない！本当に信頼できるデータ復旧Navi
• 法人・官公庁向けデータ復旧ガイド
• データ復旧後に行う再発防止｜バックアップ・冗長化・運用見直しチェックリスト
• 全国拠点のPC／NAS障害に対応するデータ復旧業者の選び方
• データ復旧の証明書・作業報告書の見方