SQL Serverのテーブル単位バックアップ・復元が必要なケースと対処法

SQL Serverで「特定テーブルだけ削除してしまった」「一部のマスタだけ過去に戻したい」といったトラブルに直面していませんか。 DB全体を復元すると、他の正常なデータまで巻き戻ってしまい、業務が停止する恐れがあります。

本記事では、SQL Serverでテーブル単位のバックアップ・復元が必要になるケースと、安全に復旧するための具体的な対処法を、実務視点でわかりやすく解説します。

SQL Serverでテーブル単位復旧が必要になる主な原因

SQL Serverは基本的に「データベース単位」での復元を前提としています。しかし実務では、特定テーブルのみが壊れたり、誤操作が発生したりするケースが少なくありません。

そのまま放置すると、データ消失や整合性エラーが拡大し、最悪の場合は業務停止や監査上の問題に発展する可能性があります。まずは代表的な原因を確認しましょう。

誤削除・誤更新（DELETE／UPDATE／TRUNCATE／DROP）

特定テーブルに対して誤ったDELETEやUPDATEを実行した場合、データが大量に失われることがあります。 TRUNCATEやDROPはロールバックが難しく、ログバックアップがなければ復旧困難になるケースもあります。

DB全体を復元すると、他の正常なテーブルまで巻き戻り、最新取引データが消失する危険があります。そのため、該当テーブルのみを過去状態に戻す必要が生じます。

特定テーブルの論理破損・不整合

インデックス破損やページ不整合が一部テーブルに発生すると、SELECT時にエラーが出る、件数が合わないといった症状が現れます。 この状態でREPAIR_ALLOW_DATA_LOSSを実行すると、復旧可能なデータまで削除される恐れがあります。

健全なバックアップから該当テーブルのみを抽出し、再投入する方が安全です。

マスタテーブルのみ過去時点に戻したい

商品マスタや価格マスタなどを誤更新した場合、取引データは維持したままマスタのみを巻き戻したいケースがあります。 DB全体を復元すると売上や在庫データまで戻ってしまい、二次的な不整合が発生します。

他環境への移送・検証用コピー

本番テーブルを検証環境へコピーし、影響範囲を確認したいケースもあります。 誤った方法でコピーするとデータ型不一致や制約エラーが発生し、検証環境自体が不安定になる可能性があります。

これらの問題に共通するのは、「DB全体を巻き戻せない」という点です。 誤った対応をすると、データ消失や業務停止につながる可能性があります。

ストレージ機器に物理障害が発生している状態で、むやみに通電や再起動、フリーソフトの使用、分解などを行うと、状況が悪化し、復旧の難易度が大きく上がることがあります。特にHDDやSSDは精密機器であり、ちょっとした刺激や誤操作でも内部パーツが傷ついたり、データが上書きされたりして、最終的に復旧不可能になるリスクもあります。誤った対処で大切なデータを失ってしまう前に、まずは専門業者への相談をおすすめします。

自力で修復する場合のリスク

▶ ほこりや異物が悪影響を与えてしまう

▶ 内部パーツに修復できない傷が付いてしまう

▶ 知識不足で誤った復旧作業を行ってしまう

ストレージデバイスの自力での修復は非常に難しく、誤った方法で作業を進めると、データが完全に失われるリスクがあります。安全にデータを復旧させたい場合、データ復旧業者に依頼することが確実です。編集部が厳選したおすすめ業者は下記のボタンからご参照ください。

SQL Serverのテーブル単位バックアップ・復元の対処法

テーブル単位で復旧する場合は、本番DBを直接操作せず「別名DBへ復元してから取り出す」方法が原則です。 以下に、安全性の高い実務的な対処法を順に解説します。

別名DBにフルバックアップを復元しテーブルを抽出する

SQL Server標準のバックアップ機能を利用し、フルバックアップを別名データベースとして復元します。 その上で、対象テーブルのみを本番へコピーする方法が最も安全です。

別名DBからテーブルを戻す手順

1. 最新のフルバックアップを確認し、可能であれば誤操作直前のログバックアップも特定する。
2. RESTORE DATABASEで別名DB（例：DB_restore）として復元する。
3. 必要に応じて差分・ログバックアップを適用し、誤操作直前の時点まで復元する。
4. 本番DB側の対象テーブルを別名で退避する、またはバックアップを取得する。
5. INSERT…SELECTやSSMSのコピー機能で、DB_restoreから対象テーブルを本番へ移行する。
6. 件数・合計値・参照整合性を検算し、インデックス再構築や統計更新を実施する。

ポイントインタイム復元＋テーブルコピー

完全復旧モデルでログバックアップを取得している場合、誤操作直前の時刻まで復元できます。 DB全体を巻き戻さず、別名DBを経由してテーブルのみ戻す方法です。

ポイントインタイム復元の手順

1. 誤操作が発生した時刻をログや監査情報から特定する。
2. フルバックアップを別名DBとして復元する（WITH NORECOVERY）。
3. 差分・ログバックアップを順に適用し、STOPATで誤操作直前まで復元する。
4. 復元済み別名DBから対象テーブルをエクスポートする。
5. 本番DBへINSERT…SELECTまたはbcpでインポートする。
6. 整合性チェック（DBCC CHECKTABLE）と業務確認を実施する。

bcpユーティリティでテーブルをエクスポート／インポート

bcpはSQL Server標準のコマンドラインツールです。 テーブル単位でファイル出力でき、定期退避や緊急復旧に有効です。

bcpでの退避と復元手順

1. bcpコマンドで対象テーブルをファイルへ出力する。
2. 出力ファイルのサイズと件数を確認し、正常に取得できたことを確認する。
3. 復元前に本番テーブルのバックアップを取得する。
4. bcp in コマンドで対象テーブルへインポートする。
5. IDENTITY列や制約エラーが出ていないか確認する。
6. 件数・主要データの検算を実施する。

SELECT INTO／INSERT…SELECTでの事前退避から戻す

同一DB内または別DBへSELECT INTOでコピーを作成している場合、そのデータを利用して復旧できます。 軽微な誤更新時に有効な方法です。

退避テーブルからの復旧手順

1. 退避テーブル（例：Backup_Table）に正常データがあることを確認する。
2. 本番テーブルを別名で退避し、現在の状態を保存する。
3. 本番テーブルをTRUNCATEせず、DELETEまたは新規作成で調整する。
4. INSERT…SELECTで退避データを戻す。
5. 主キー・外部キー制約を再有効化する。
6. 件数検算と業務テストを実施する。

専門業者に相談・依頼する

バックアップがない、ログが破損している、DB自体が起動しない場合は、自力復旧が困難です。 誤った操作を重ねると、データ消失が完全なものになる恐れがあります。

ここまでの対処法を試しても改善できなかった場合、機器に重大なエラーや物理的な故障が生じている可能性が高いです。この場合、続けて使用すると損傷がひどくなり、復旧できなくなる可能性があります。さらに、自力で分解したり復旧作業を行うのも状態が悪化するケースが多いです。少しでもデータを失いたくない方は速やかに専門業者に相談することをおすすめします。

おすすめのデータ復旧専門業者

データ復旧の専門業者を選ぶときには以下の項目が特に重要です。

すべてに対応しているサイバーセキュリティ総研おすすめのデータ復旧業者はデジタルデータリカバリーです。

デジタルデータリカバリー

デジタルデータリカバリーは、14年連続国内売上No.1の最大手のデータ復旧専門業者です。

復旧率は91.5%とかなり高い技術力を有しており、RAID復旧のノウハウを持ったエンジニアが複数名チームとなって対応することで、早期に破損個所のすべての特定ができ、修復を行うことができます。

また2021年には、HDDの最難関障害である「スクラッチ障害」の復旧技術や、SSDやSDカードのような「メモリ媒体」の復旧技術が評価され、東京都の経営革新優秀賞を受賞しました。その復旧技術・設備が詰まっている復旧ラボは見学が可能です。

また、累積の相談件数は46万件を超え、官公庁や大手企業との取引実績も豊富です。さらに、依頼されたものの8割を48時間以内に復旧するスピードも優秀です。

24時間365日の受付対応に加え、機器は全国5拠点への持ち込み・配送・出張と臨機応変に対応してくれます。相談から見積もりが無料で行えるため、データ復旧専門業者の選定に困っていたら、まずは最大手であるデジタルデータリカバリーへ相談することをおすすめします。

デジタルデータリカバリーのさらに詳しい情報は公式サイトへ

テーブル単位復旧で失敗しないために重要なこと

SQL Serverでは原則としてデータベース単位の復元が前提ですが、実務ではテーブル単位での復旧が求められる場面が少なくありません。 しかし、直接本番DBへリストアを試みたり、安易にREPAIR系コマンドやTRUNCATEを実行したりすると、復旧可能だったデータまで失われる可能性があるので注意しましょう。