目次

1. はじめに：なぜバックアップ・リカバリが重要か
2. SQL Server側のバックアップ戦略
   • 2.1 フル / 差分 / トランザクションログ バックアップ
   • 2.2 バックアップスケジュールとメンテナンスプラン
   • 2.3 リストア手順とテストの重要性
3. Accessフロントエンドのバックアップ
   • 3.1 フロントエンド分割のメリット
   • 3.2 バージョン管理と自動更新
   • 3.3 .accdb/.mdbファイルの保護と暗号化
4. 災害対策：地理的冗長化とクラウド活用
   • 4.1 Azureやクラウドストレージを使ったオフサイトバックアップ
   • 4.2 ミラーリング・ログ配布・Always On可用性グループ
   • 4.3 BC/DR計画（事業継続 / 災害復旧計画）の考え方
5. 具体的な運用例：コードサンプルとヒント
   • 5.1 バックアップ実行バッチの例
   • 5.2 VBAでのログ書き出し・エラーハンドリング
   • 5.3 定期自動バックアップの可視化
6. まとめ

ないものはない！お買い物なら楽天市場

1. はじめに：なぜバックアップ・リカバリが重要か

「低コストで開発が早い」という魅力のあるAccess×SQL Serverの構成ですが、データを失えばビジネスが止まるリスクは他のシステムと変わりありません。バックアップは「万が一のときにデータを復旧できる」ための最後の砦です。さらに、自然災害やサーバー障害、人為的ミスなどに備えた災害対策(BC/DR)をしっかり施すことで、長期的に安定した運用を実現できます。

2. SQL Server側のバックアップ戦略

2.1 フル / 差分 / トランザクションログ バックアップ

SQL Serverでは、以下の3種類のバックアップを組み合わせるのが基本です。

1. フルバックアップ
   • データベース全体を丸ごとバックアップする。大容量になるため、週1回程度などの頻度で実施することが多い。
2. 差分バックアップ
   • 前回のフルバックアップ以降に変更があったデータのみをバックアップ。フルと比較してファイルサイズが小さく、より頻繁に実行しやすい。
3. トランザクションログバックアップ
   • 更新履歴（ログ）をバックアップし、障害時に「更新をどこまで反映させるか」を細かくコントロールできる。運用形態によっては15～60分間隔で実施し、データロスを最小化する。

バックアップ例（Transact-SQL）

-- フルバックアップ
BACKUP DATABASE ORDIS
TO DISK = 'D:\Backup\ORDIS_Full_20250224.bak'
WITH INIT, NAME = 'ORDIS Full Backup'

-- 差分バックアップ
BACKUP DATABASE ORDIS
TO DISK = 'D:\Backup\ORDIS_Diff_20250224.bak'
WITH DIFFERENTIAL, NAME = 'ORDIS Diff Backup'

-- トランザクションログバックアップ
BACKUP LOG ORDIS
TO DISK = 'D:\Backup\ORDIS_Log_20250224.trn'
WITH NOINIT, NAME = 'ORDIS Log Backup'

2.2 バックアップスケジュールとメンテナンスプラン

SQL Server Management Studio(SSMS) のメンテナンスプラン機能を使うと、GUI操作でバックアップをスケジューリング可能です。フル・差分・ログを適切な頻度で実行し、不要になった古いファイルは自動削除する設定も行えます。

2.3 リストア手順とテストの重要性

バックアップはとっていても、「いざというときに復元できない」 という事態を防ぐには、定期的にリストアテストを行いましょう。実機とは別のテスト用サーバーにリストアを試してみたり、トランザクションログからポイントインタイムリカバリを試すことで、実運用時の確実性が上がります。

3. Accessフロントエンドのバックアップ

3.1 フロントエンド分割のメリット

Accessで開発する際は、「テーブルのみを配置したバックエンド(.accdb/.mdb)」 と**「フォームやレポート、VBAコードを持つフロントエンド」**を分割して運用することが推奨されます。

• バックエンド: SQL Serverへリンクしているorデータを保持している（場合によってはSQL Serverへすべて移行）。
• フロントエンド: ユーザーインターフェースを提供。更新も容易で、ユーザーごとに配布する場合は各PC側で管理。

これにより、データ（SQL Server）はサーバー側の定期バックアップに含まれ、フロントエンドはバージョン管理やローカルバックアップでシンプルに保護するだけで済みます。

3.2 バージョン管理と自動更新

フロントエンドファイル（.accdbや.accde）をユーザーごとに配布している場合、頻繁なアップデートが発生するとバージョン管理が煩雑になりがちです。

• 自動更新ツール: ログインスクリプトや専用のバッチファイルで、最新バージョンのフロントエンドをネットワークから自動コピーさせる仕組み。
• バージョン番号: フロントエンドを更新したら、メインメニューなどにバージョンを表示し、ユーザーがすぐわかるようにする。

3.3 .accdb/.mdbファイルの保護と暗号化

• パスワード保護: Accessファイル自体にパスワードをかける。ただし完全な暗号化ではないため、セキュリティを過信しない。
• Windows EFS/BitLocker: OSレベルの暗号化を利用し、ファイルが流出しても読めないようにする。
• 配布ファイルの最小化: フロントエンドには機密情報を極力持たない（接続文字列などは外部ファイルやWindows認証を使う）。

4. 災害対策：地理的冗長化とクラウド活用

4.1 Azureやクラウドストレージを使ったオフサイトバックアップ

自然災害などでオンプレミスサーバーが使用不能になった場合、クラウド上にバックアップを保管しておけばリカバリ時間を大幅に短縮できます。

• Azure BackupやAWS S3などを利用し、定期的にバックアップファイルをアップロード。
• BCP（事業継続計画）の一環として、少なくとも別の物理ロケーションにバックアップを置くことが重要。

4.2 ミラーリング・ログ配布・Always On可用性グループ

SQL Serverにはいくつかの高可用性機能があります。

1. ミラーリング: 主サーバーとミラーサーバーにリアルタイムでデータを複製（※最新バージョンではAlways On可用性グループが推奨）。
2. ログ配布: 主サーバーのトランザクションログを定期的に別サーバーへ適用し、スタンバイDBを維持。
3. Always On可用性グループ: 複数ノード間で同期/非同期にデータを複製し、高可用性とフェールオーバーを提供。

4.3 BC/DR計画（事業継続 / 災害復旧計画）の考え方

RTO（目標復旧時間） と RPO（目標復旧時点） を定義し、それに見合ったバックアップや冗長化レベルを選択しましょう。事業にどの程度の停止が許容されるか、データロスはどこまで許容できるかを明確にし、コストや運用負荷とバランスを取ることが大切です。

5. 具体的な運用例：コードサンプルとヒント

5.1 バックアップ実行バッチの例

SQL Serverのバックアップを自動実行する簡易バッチファイル（Windowsのタスクスケジューラで定期実行するイメージ）:

@echo off
set DBNAME=ORDIS
set BKUP_PATH=D:\Backup
set DT=%DATE:~0,10%_%TIME:~0,2%%TIME:~3,2%

REM フルバックアップ
sqlcmd -S MyServer\SQLEXPRESS -E -Q "BACKUP DATABASE [%DBNAME%] TO DISK = '%BKUP_PATH%\%DBNAME%_Full_%DT%.bak' WITH INIT"

REM ログバックアップ(要 Full/Bulk-logged復旧モデル設定)
sqlcmd -S MyServer\SQLEXPRESS -E -Q "BACKUP LOG [%DBNAME%] TO DISK = '%BKUP_PATH%\%DBNAME%_Log_%DT%.trn' WITH NOINIT"

echo Backup Completed: %DT%
pause

• sqlcmd でSQL Serverに接続し、BACKUP DATABASEやBACKUP LOGコマンドを実行。
• "MyServer\SQLEXPRESS" は実際のサーバー名やインスタンス名に置き換えて使用。

5.2 VBAでのログ書き出し・エラーハンドリング

Access側で、バッチ処理やストアドプロシージャ実行時にエラーがあった場合、ログテーブルに書き込む例：

'-------------------------------------------------------------------------------------------
'【目的】   エラー発生時にログテーブルに書き込み、バックアップやリカバリ時の参考にする
'【ポイント】
'   ①Call データベース接続を利用
'   ②SQLインジェクション対策のためパラメータバインド
'-------------------------------------------------------------------------------------------
Public Sub ログ書き込み(strログ区分 As String, strメッセージ As String)

    On Error GoTo ErrHandler
    
    Call データベース接続
    
    Dim cmd As ADODB.Command
    Set cmd = New ADODB.Command
    cmd.ActiveConnection = cn
    
    cmd.CommandText = "INSERT INTO dbo.ログテーブル (ログ日時, ログ区分, メッセージ) VALUES (GETDATE(), @ログ区分, @メッセージ)"
    cmd.CommandType = adCmdText
    
    cmd.Parameters.Append cmd.CreateParameter("@ログ区分", adVarWChar, adParamInput, 50, strログ区分)
    cmd.Parameters.Append cmd.CreateParameter("@メッセージ", adVarWChar, adParamInput, 1000, strメッセージ)
    cmd.Execute
    
    Set cmd = Nothing
    Exit Sub
    
ErrHandler:
    MsgBox "ログ書き込みでエラーが発生しました：" & Err.Description, vbExclamation
End Sub

5.3 定期自動バックアップの可視化

Accessのメインメニューなどに「最終バックアップ日時」を表示する機能を実装すれば、運用者が適宜バックアップ状況を確認しやすくなります。バックアップジョブ完了時にSQL Serverのbackupsetテーブル（msdbデータベース内）から日付を取得し、フォーム上に表示する方法もあります。

6. まとめ

Access×SQL Serverを組み合わせたシステムであっても、他の大規模システム同様に、バックアップ・リカバリと災害対策は不可欠です。ポイントを振り返ると：

1. SQL Serverのバックアップ設計
   • フル・差分・トランザクションログの組み合わせにより、障害時のデータロスを最小化する。
   • メンテナンスプランを活用し、定期実行＋リストアテストを忘れない。
2. Accessフロントエンドの保護
   • フロントエンド分割とバージョン管理、自動更新で運用負荷を減らす。
   • 必要に応じて暗号化やパスワード保護を検討。
3. 災害対策とオフサイト保管
   • クラウド（Azure、AWS）等にバックアップを保管し、物理的な災害から守る。
   • ミラーリングやAlways On可用性グループなど高可用性の仕組みも視野に入れる。
4. ログ活用と運用監視
   • 障害発生時の原因分析やリカバリ時間短縮のため、エラーログやバックアップ履歴を管理する。

「小さく始めて大きく育てる」というAccess×SQL Server開発の良さを活かしつつも、万が一のリスクに備えるバックアップと災害対策を早めに確立しておくことで、長期的に安全・安定したシステムを運用していけるはずです。

今後も当ブログでは、Access×SQL Serverの連携を中心に、運用やトラブルシュート、最適化に役立つ情報を発信していきます。ぜひ参考にしていただき、災害時にも迅速にリカバリできる堅牢な仕組みを構築してください。

DMM

管理人

駆け出しブロガー

XInstagramYouTube

入社した会社では、Accessを活用した基幹システムが長年運用されていました。しかし、開発者の高齢化により保守が困難となり、システムの維持・更新が急務に。 ほぼAccessに触れたことのなかった私は、ゼロから学びながら基幹システムを再構築してみることに。ついにはAccessによるシステム開発エンジニアとしてのスキルを身につけるまでに成長。 元々の業務のノウハウとそれを効率化するためのツール(Access)によって業務効率化システムをいくつも開発してきました。 みなさんの”なにか（業務のノウハウ）”とAccessで業務効率化を実現するお役に立てれば幸いです。