シンレンタルサーバーの自動バックアップ｜14日分の範囲と、対象外のデータ

シンレンタルサーバーには、サーバーのデータを毎日自動で保存する「自動バックアップ」があり、Webとメールのデータ、MySQLのデータベースとも過去14日分が保持されています。ただし、WordPressのキャッシュやメールの一部の領域など、対象外のデータも決まっています。また、問題に気づくのが遅れると、問題が起きる前のデータがもう残っていないことがあります。この記事では、公式ページの記載を整理し、何日以内に気づけば戻せるかを日付で計算します。

（確認：シンレンタルサーバー「自動バックアップ」のページ。確認日：2026年10月30日。筆者はシンレンタルサーバーでバックアップデータの提供を申し込んで確かめてはいません）

公式ページに書かれていること

対象外のデータ（公式ページの一覧から）

• WordPressの wp-content/cache と、プラグインの cache の配下
• WordPressの wp-content/debug.log
• Maildir の配下などのメールの領域（POPで受信して削除したメールなど、バックアップの時点でサーバーに残っていないメールは保存されない）
• PHPのセッションの保存場所
• MySQL：壊れていて処理できないデータベース、テーブルの数が1,000を超えるデータベース、処理に大きな負荷がかかるデータベース

キャッシュとログは作り直せるデータなので、記事・画像・設定（データベースと wp-content/uploads など）は対象に入っています。一方、ファイル数がとても多い場合などは、個別に対象外にされることがある、とも書かれています。

コード：何日以内に気づけば戻せるか

保持は14日分なので、改ざんや誤った削除に気づくのが遅れると、問題が起きる前のバックアップが期間の外に出てしまいます。気づいた日と、問題が起きた日から、戻せるかを判定します。

# シンレンタルサーバーの自動バックアップ（1日1回・過去14日分）で、問題が起きる前のデータが残っているかを日付で確かめる
# 公式の記載：提供できるのは、申し込みを確認した時点から14日前までのデータ（Web・メール、MySQL とも）
# 前提（簡略化）：バックアップは毎日深夜に1回取られ、申し込んだ日の前日までの14日分がそろっているとする
import datetime as dt

KEEP_DAYS = 14   # 保持日数（公式の記載）


def check(started, noticed):
    # started: 問題が起きた日（改ざん・誤削除など）、noticed: 気づいて申し込む日
    oldest = noticed - dt.timedelta(days=KEEP_DAYS)
    newest = noticed - dt.timedelta(days=1)
    clean_last = started - dt.timedelta(days=1)   # 問題が起きる前の日のバックアップ
    ok = clean_last >= oldest
    print(f'問題が起きた日 {started}／気づいた日 {noticed}（{(noticed - started).days}日後）')
    print(f'  残っているバックアップ: {oldest} 〜 {newest}')
    if ok:
        print(f'  問題が起きる前のデータ: {clean_last} の分が残っている → 戻せる')
    else:
        print(f'  問題が起きる前のデータ: {clean_last} の分は保持期間の外 → 自動バックアップでは戻せない')
    print()


today = dt.date(2026, 10, 30)
for days_ago in (3, 10, 13, 14, 20):
    check(today - dt.timedelta(days=days_ago), today)

計算の結果（Python 3）

問題が起きた日 2026-10-27／気づいた日 2026-10-30（3日後）
  残っているバックアップ: 2026-10-16 〜 2026-10-29
  問題が起きる前のデータ: 2026-10-26 の分が残っている → 戻せる

問題が起きた日 2026-10-20／気づいた日 2026-10-30（10日後）
  残っているバックアップ: 2026-10-16 〜 2026-10-29
  問題が起きる前のデータ: 2026-10-19 の分が残っている → 戻せる

問題が起きた日 2026-10-17／気づいた日 2026-10-30（13日後）
  残っているバックアップ: 2026-10-16 〜 2026-10-29
  問題が起きる前のデータ: 2026-10-16 の分が残っている → 戻せる

問題が起きた日 2026-10-16／気づいた日 2026-10-30（14日後）
  残っているバックアップ: 2026-10-16 〜 2026-10-29
  問題が起きる前のデータ: 2026-10-15 の分は保持期間の外 → 自動バックアップでは戻せない

問題が起きた日 2026-10-10／気づいた日 2026-10-30（20日後）
  残っているバックアップ: 2026-10-16 〜 2026-10-29
  問題が起きる前のデータ: 2026-10-09 の分は保持期間の外 → 自動バックアップでは戻せない

• 問題が起きてから13日以内に気づけば、問題が起きる前の日のデータが残っている計算
• 14日以上たってから気づくと、問題が起きる前のデータは保持期間の外になり、自動バックアップでは戻せない
• 実際の境目は、バックアップが終わる時刻と申し込みを確認した時刻で前後する（公式の記載は「14日前まで」）

自動バックアップだけに頼らないために（筆者の考え）

• 自分でも定期的に書き出す：WordPressは、ファイルとデータベースの両方を保存する（WordPressのバックアップ｜ファイルとデータベースの両方を保存する）
• 2週間以上前の状態に戻したい時に備える：自分のバックアップは、14日より長く残しておく
• 気づくのを早くする：記事の数や更新日を定期的に記録しておくと、知らないうちの変化に気づきやすい（今のサイトの状態を記録する方法）
• 契約の期限を切らさない：契約が有効でないとバックアップデータを申し込めない

この記事で確かめていないこと

• バックアップデータの提供を申し込んでから、受け取れるまでの時間
• Web・メールのバックアップを、サーバー上へ直接戻せるか（公式ページの記載は「データの提供」）
• メールの領域（Maildir）が、どの場合に対象外になるかの詳しい条件

まとめ

• シンレンタルサーバーの自動バックアップは、Web・メール・MySQLとも過去14日分。申し込みを確認した時点から14日前まで提供される
• キャッシュ・debug.log・メールの一部・テーブル数が1,000を超えるデータベースなどは対象外
• 問題に気づくのが14日を過ぎると、問題が起きる前のデータは戻せない。自分でも定期的にバックアップを取り、長く残す

本記事はシンレンタルサーバーの公式ページの記載にもとづく整理です。条件は変わることがあるため、申し込む前に公式で確認してください。料金とプランの比べ方はシンレンタルサーバーの料金とプランにまとめています。