法人サイトや業務システムでは、「バックアップ機能がある」だけでは十分とは言えません。重要なのは、どこまでのデータ損失を許容できるか、何時間で復旧したいか、障害時に本当に戻せるかまで設計されていることです。
特に会社のWebサイト、顧客情報、受注データ、メールなどは、消失したときの影響が大きいため、バックアップの保存先・世代数・復元方法まで確認する必要があります。
30秒でわかる結論
- 法人サーバーでは「バックアップあり」ではなく、保存世代・保存先・復元方法まで確認する
- 最低限、本番サーバーとは別の場所にバックアップを持つ
- 重要データは日次バックアップだけでなく、更新頻度に応じて数時間単位も検討する
- RPOは「何時間分のデータ損失を許容できるか」、RTOは「何時間で復旧したいか」を決める指標
- 7世代だけでは、8日前から侵害されていた場合に正常データへ戻れないことがある
- ランサムウェア対策では、通常運用から簡単に消せないバックアップを持つことが重要
- バックアップは「取得できた」ではなく、定期的に復元テストして初めて使えると判断する
法人サーバーのバックアップで重要なのは「戻せるか」
バックアップは、サーバー上のデータを別の場所へ複製して保存する仕組みです。
ただし、企業利用では「バックアップファイルが存在する」だけでは不十分です。障害・誤操作・不正アクセスが起きたときに、必要な時点へ戻し、業務を再開できることが重要です。
ここで伝えたいポイント
法人のバックアップは、保存する仕組みではなく、事業を再開する仕組みとして考えます。「何日前へ戻れるか」「復元に何時間かかるか」「誰が復元するか」まで決めておく必要があります。
まずRPOとRTOを決める
法人向けのバックアップ体制を考えるときは、RPOとRTOという2つの考え方を使うと整理しやすくなります。
| 項目 | 意味 | 例 |
|---|---|---|
| RPO | どこまで過去のデータへ戻っても許容できるか | RPO 4時間なら最大4時間分のデータ損失を許容 |
| RTO | 障害発生から何時間以内に復旧したいか | RTO 2時間なら2時間以内の復旧を目標 |
具体例
注文データが1時間に100件増えるECサイトで、1日1回しかバックアップしていない場合、障害のタイミングによっては最大約24時間分、単純計算で最大2,400件近い注文データを失う可能性があります。
100件/時間 × 24時間 ＝ 最大2,400件
この会社が「4時間分までなら手作業で復元できる」と判断するなら、RPOは4時間程度を目安にし、少なくとも4時間以内の間隔でバックアップできる体制を検討します。
バックアップ頻度はデータの更新量で決める
「毎日バックアップすれば十分」と一律に決めるのではなく、失って困るデータがどの程度の頻度で増えるかを基準にします。
| 用途 | 更新頻度 | バックアップの考え方 |
|---|---|---|
| 会社案内サイト | 月数回 | 日次でも十分な場合が多い |
| オウンドメディア | 毎日 | 日次＋更新前バックアップ |
| ECサイト | 常時 | 数時間単位やDBの高頻度保護を検討 |
| 予約サイト | 常時 | 予約データ損失を基準に短いRPOを設定 |
| 社内業務システム | 業務時間中に頻繁 | 業務停止許容時間に合わせて設計 |
更新が少ない会社サイトと、注文が入るECサイトを同じ「1日1回」で考えない
バックアップ頻度はサイト種別ではなく、失ったときの損失で決めます。静的な会社案内なら日次でも現実的ですが、売上に直結するデータが継続的に増える場合は、より短い間隔が必要です。
保存世代は「何日前の異常まで戻したいか」で決める
バックアップの「7世代保存」は、通常なら直近7回分を残すという考え方です。日次バックアップなら、おおむね1週間程度前まで戻れる構成になります。
ただし、問題に気づくまでに時間がかかるケースでは、7日では足りません。
7世代では足りない例
Webサイトが不正改ざんされ、気づいたのが10日後だった場合、日次7世代しか残していなければ、保存されているバックアップすべてが改ざん後の状態になっている可能性があります。
このため法人では、日次だけでなく週次・月次を組み合わせる方法が有効です。
| 保存方法 | 例 | 役割 |
|---|---|---|
| 日次 | 7～14世代 | 直近の誤操作・障害から戻す |
| 週次 | 4～8世代 | 数週間前の正常状態へ戻す |
| 月次 | 6～12世代 | 長期間気づかなかった問題に備える |
注意
保存世代を増やすほど必要容量も増えます。毎回フルバックアップを取るのか、差分・増分を使うのかで必要容量は大きく変わるため、保存期間だけでなく方式も確認してください。
本番サーバーと同じ場所だけに保存しない
バックアップを本番サーバーと同じディスクや同じVPS内だけに保存すると、サーバー自体が壊れたときにバックアップまで失う可能性があります。
法人では、少なくとも本番環境から分離された場所へバックアップを保存することが重要です。
本番データ ＋ 別環境のバックアップ
さらに重要度が高いデータでは、一般に「3-2-1」の考え方が使われます。
すべての中小企業が厳密な3-2-1構成を必要とするとは限りませんが、少なくとも「本番サーバーが消えたらバックアップも消える」という構成は避けるべきです。
ランサムウェア対策では「消されにくいバックアップ」が重要
ランサムウェアや管理者アカウント侵害では、本番データだけでなく、同じ認証情報でアクセスできるバックアップまで削除・暗号化されることがあります。
そこで重要になるのが、通常運用から簡単に変更・削除できないバックアップです。
| 方式 | 特徴 |
|---|---|
| 別アカウント保存 | 本番環境の認証情報が漏れても影響範囲を分けやすい |
| イミュータブル保存 | 一定期間、変更・削除できないようにする |
| オフライン保存 | 通常時はネットワークから切り離す |
ここが法人では重要
バックアップの保存先が本番サーバーから常に書き換え可能なら、侵害時に一緒に消されるリスクがあります。重要データでは、「別に置く」だけでなく「簡単に消せない」ことまで確認してください。
自動バックアップがあっても確認する項目
レンタルサーバーや法人向けサーバーには、自動バックアップ機能が標準搭載されていることがあります。
便利ですが、「自動バックアップあり」の一文だけで決めず、次の項目まで確認します。
契約前チェックリスト
- 何日分・何世代保存されるか
- Webファイルだけでなくデータベースも対象か
- メールもバックアップ対象か
- バックアップ保存先は本番環境と分離されているか
- 復元は自分で操作できるか
- 復元に追加料金がかかるか
- 特定ファイルだけ戻せるか
- バックアップ取得時刻を確認できるか
- 解約・障害時にバックアップへアクセスできるか
復元時間まで含めてバックアップを評価する
同じバックアップがあっても、復元に10分で済む場合と、サポートへ依頼して数時間待つ場合では、事業への影響が違います。
停止時間を金額で考える
Webサイト停止による機会損失が1時間あたり10万円だと仮定します。
10万円 × 6時間 ＝ 60万円
6時間の復旧待ちで60万円相当の影響が出るなら、月額数千円のバックアップ・冗長化費用を追加する価値が出てきます。
法人では、バックアップ料金だけでなく「停止1時間あたりの損失」と比較すると判断しやすくなります。
バックアップと冗長化は同じではない
バックアップと冗長化は、どちらも障害対策ですが役割が異なります。
| 対策 | 主な目的 | 対応しやすい問題 |
|---|---|---|
| バックアップ | 過去の状態へ戻す | 誤削除、改ざん、データ破損 |
| 冗長化 | サービスを止めにくくする | サーバー故障、機器障害 |
サーバーを2台にして同じデータをリアルタイム同期していても、誤ってファイルを削除すれば、その削除も同期される可能性があります。
よくある誤解
RAID、ミラーリング、クラスタリングがあるからバックアップ不要、とは言えません。冗長化は「止まりにくくする」ための仕組みで、過去の状態へ戻すバックアップとは目的が違います。
復元テストをしないバックアップは信用しすぎない
バックアップ処理が「成功」と表示されていても、実際に復元できるとは限りません。
ファイル破損、設定不足、暗号鍵の紛失、復元手順の不備などが、障害発生時に初めて判明するケースがあります。
初心者はこれでOK
最低でも四半期や半年に一度など、自社で決めた周期で復元テストを行い、「何分で、誰が、どの手順で戻せたか」を記録してください。
会社規模・用途別に必要なバックアップ体制を考える
日次バックアップ＋7～14世代程度を一つの目安にし、更新前にも手動バックアップを取ると運用しやすくなります。
日次バックアップに加え、記事更新・テーマ変更・プラグイン更新前のバックアップを習慣化します。
注文・予約データが継続的に増えるため、日次だけでなく短いRPOを設定し、データベースを高頻度で保護する構成を検討します。
バックアップだけでなく、冗長化、別拠点保存、復旧手順、担当者体制まで含めてBCPとして設計します。
社内で決めておくべき5つのルール
バックアップの仕組みだけでなく、運用ルールも必要です。
- 誰がバックアップ成功を確認するか
- 異常時に誰へ連絡するか
- 誰が復元作業を行うか
- どの時点のデータへ戻すかを誰が決めるか
- 復元後に誰が業務再開を判断するか
担当者不在も想定する
バックアップ担当者が休暇中・退職済みで復元できない状態では、仕組みがあっても事業継続に使えません。手順書と権限管理を整え、最低2人以上が復旧方法を把握する運用が安全です。
教科書判定｜法人は「日次自動バックアップあり」だけで選ばない
小規模法人でも「別保存・複数世代・復元確認」の3つは最低限確認する
会社案内サイト程度なら、毎時間バックアップする必要は通常ありません。しかし、日次バックアップが本番と別の場所に保存され、複数世代残り、実際に復元できることは確認すべきです。EC・予約・業務システムでは、そこからさらにRPO・RTOを短くして設計します。
本サイトでは、法人サーバーを選ぶときにバックアップを次の順番で確認します。
- 本番とは別の場所に保存されるか
- 何世代残るか
- ファイル・DB・メールのどこまで対象か
- 自分で復元できるか
- 復元に何時間かかるか
- 重要システムなら削除耐性・別拠点も確認する
よくある質問
Q．法人サイトなら毎日バックアップすれば十分ですか？
会社案内サイトなど更新頻度が低いサイトでは日次で足りる場合があります。一方、ECや予約システムのように常時データが増えるサービスでは、1日分の損失を許容できないことがあるため、より短い間隔を検討します。
Q．7日分の自動バックアップがあれば安心ですか？
直近の誤操作には役立ちますが、異常の発見が8日以上遅れると正常な世代が残っていない可能性があります。重要データでは週次・月次を組み合わせることも検討します。
Q．サーバー会社の自動バックアップだけで十分ですか？
更新頻度が低い小規模サイトならサーバー会社の自動バックアップだけで運用できる場合があります。一方、法人の重要データでは保存世代、保存先、復元条件、対象データ、復元料金まで確認し、自社側の別バックアップも検討します。
Q．RAIDがあればバックアップは不要ですか？
不要にはなりません。RAIDは主にディスク障害への耐性を高める仕組みで、誤削除や改ざん前の状態へ戻すためのバックアップとは役割が違います。
Q．バックアップはどのくらいの頻度で復元テストすべきですか？
一律の正解はありませんが、重要度に応じて定期的なテスト日を決めます。少なくともシステム構成変更後やバックアップ方式変更後は、実際に復元できることを確認してください。
まとめ｜法人バックアップは「何日前へ、何時間で戻せるか」で考える
この記事の結論
- バックアップは保存の有無だけでなく復元可能性まで確認する
- RPOで許容できるデータ損失、RTOで許容できる停止時間を決める
- 本番サーバーとは別の場所にバックアップを保存する
- 日次だけでなく週次・月次を組み合わせると長期的な異常にも対応しやすい
- 重要データは削除されにくいバックアップも検討する
- RAIDや冗長化をバックアップの代わりにしない
- 定期的に復元テストを行う
法人サーバーでは、「バックアップがあります」ではなく「何日前の状態へ、何時間で戻せるか」まで答えられる体制を作ってください。小規模サイトならシンプルな構成でも構いませんが、売上や業務停止の影響が大きくなるほど、保存先・世代・復旧時間を強化する必要があります。
次に読むなら
法人サーバー全体の選定基準を確認するなら、「企業ホームページに必要なサーバースペックとは？」で、CPU・メモリ・容量・安定性をどこまで重視すべきか整理してください。