【Next.jsブログ構築】VPS の SQLite データベースを rclone と OneDrive で自動バックアップする方法

これまでの Next.js ブログ構築シリーズをまとめたページはこちらです。

【Next.jsブログ構築まとめ】WordPressからMarkdownへ完全移行

WordPressの表示速度やメンテナンス課題を解決するため、Next.jsとMarkdownを用いたモダンなブログへ移行する手順のまとめページです。非エンジニアに向けて、データ変換からVPSでのNginx・HTTPS設定まで分かりやすく解説します。

前回の記事はこちらです。

【Next.jsブログ構築】VPS の Next.js ブログを Git と GitHub でバックアップ・バージョン管理する方法

VPS 上の Next.js ブログのソースコードを Git と GitHub を使ってバックアップ・バージョン管理する方法を解説します。GitHub アカウントの作成から SSH 接続設定・初回 push まで、Cursor の GUI 操作方法もあわせて紹介します。

VPS でブログを運用していると、ソースコードのバックアップは対策できても、
データベースのバックアップはどうすればいいのか迷いませんか？

前回の第 23 回では、ソースコードを Git と GitHub でバックアップする仕組みを構築しました。
しかし、閲覧数カウンターのデータを蓄積している SQLite データベースは、
Git の管理に向かない特性があるため、別の方法でバックアップする必要があります。

この記事では、rclone というツールを使って VPS 上の SQLite データベースを
OneDrive に毎日自動でバックアップする仕組みを構築した手順を解説します。

この記事を読むとわかること：

SQLite データベースが Git 管理に向かない理由
主要なバックアップ方法の比較と OneDrive を選んだ理由
rclone のインストールから OneDrive への接続設定までの手順
安全・確実なバックアップスクリプトの作成方法
cron を使った毎日の自動実行設定

SQLite データベースを Git で管理できない理由
バックアップ方法を比較する
rclone とは何か
セキュリティについて
作業環境の確認
Step 1：rclone を VPS にインストールする
Step 2：Windows PC で OneDrive の認証を行う
Step 3：VPS に rclone の設定を行う
Step 4：OneDrive にバックアップ用フォルダを作成する
Step 5：バックアップスクリプトを作成する
1. スクリプトの主要な処理を解説する
Step 6：動作確認をする
Step 7：cron に登録して毎日自動実行する
バックアップ体制の全体像
補足：Azure アプリを登録してアクセスを特定フォルダに限定する方法
まとめ

SQLite データベースを Git で管理できない理由

まず、なぜ SQLite データベースを Git で管理するのが難しいのかを説明します。

Git はテキストファイルの差分（何がどう変わったか）を記録することが得意なツールです。
しかし SQLite データベース（.db ファイル）はバイナリファイルと呼ばれる種類のファイルで、Git では差分を意味のある形で表示できません。

さらに今回のデータベースは、誰かがブログにアクセスするたびに閲覧数が更新されます。
つまりアクセスのたびにファイルが変化するため、コミット（変更の保存）が無意味に増え続けるという問題も起きます。

このような理由から、SQLite データベースのバックアップには Git 以外の方法が必要です。

バックアップ方法を比較する

主なバックアップ方法を比較してみます。

項目	①手動 DL	②VPS 内のみ	③Google Drive	④OneDrive ★	⑤Dropbox	⑥ConoHa
難易度	⭐	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐
自動化	❌	✅	✅	✅	✅	✅
オフサイト保管	✅	❌	✅	✅	✅	△
無料容量	PC 次第	VPS 次第	15GB	5GB	2GB	❌
有料時の料金	無料	無料	¥250/月〜	¥224/月〜	¥1,600/月〜	従量制
馴染みやすさ	◎	◎	◎	◎	○	◎
運営会社	—	—	Google（米）	Microsoft（米）	Dropbox（米）	GMO（日）

①手動ダウンロード（WinSCP など）

WinSCP などの SFTP クライアントで、VPS のデータベースファイルを定期的に PC にダウンロードする方法です。

設定なしで今すぐ始められる手軽さがありますが、手動なので「やり忘れ」が起きやすく、継続するのが難しいという弱点があります。

②VPS 内のみ（cron でローカル保存）

cron（定期実行の仕組み）を使って、VPS 内の別のフォルダにバックアップを保存する方法です。

自動化はできますが、VPS 自体が壊れると、バックアップも一緒に消えます。
「オフサイト保管」（別の場所への保管）ができていないため、この方法だけでは不十分です。

③rclone + Google Drive

rclone を使って Google Drive に自動アップロードする方法です。

無料で 15GB という大容量が魅力ですが、現在（2025年以降）は、rclone の標準的な認証情報が Google にブロックされるようになっており、Google Cloud Console で自分専用の OAuth アプリを作成することが必須になっています。
この手順がやや複雑なため、難易度が上がっています。

④rclone + OneDrive（採用）

今回採用した方法です。

rclone の標準の認証情報がそのまま使えるため、Google Drive のような複雑な追加設定が不要です。
Windows に標準搭載されており、Microsoft アカウントをお持ちの方であれば、すでに OneDrive が使える状態です。
今回バックアップする SQLite データベースのサイズは 1〜2MB 程度なので、5GB の無料容量で十分すぎる余裕があります。

⑤rclone + Dropbox

rclone は Dropbox にも対応していますが、無料容量が 2GB と少なく、有料プランは月額 1,600 円〜と割高です。今回の用途には向いていません。

⑥ConoHa スナップショット

ConoHa VPS のスナップショット機能を使う方法です。
操作はシンプルですが有料で、同じ ConoHa のインフラ内に保存されるため完全なオフサイト保管とは言えません。

rclone とは何か

rclone は「クラウドストレージのための rsync」と呼ばれるオープンソースのコマンドラインツールです。
Google Drive・Dropbox・Amazon S3・OneDrive など 90 以上のクラウドサービスとファイルを送受信できます。

一度セットアップすれば、コマンド 1 つでファイルのアップロード・同期・削除ができます。
今回は VPS から OneDrive へのバックアップに使用します。

セキュリティについて

rclone のデフォルト設定では、OneDrive 全体への読み書き権限を持つトークン（許可証）が発行されます。

今回バックアップする内容は「URL と閲覧数の数字のみ」で、個人情報・パスワード・クレジットカード情報は一切含まれていません。
そのため、デフォルトの設定でも実害はほぼないと判断して進めます。

より厳密なセキュリティが必要な場合は、Azure アプリを自分で登録して「特定フォルダのみに限定する」設定もできます。
詳しくは記事末尾の補足セクションで説明します。

作業環境の確認

この記事の作業環境は以下の通りです。

項目	内容
VPS OS	Ubuntu 24.04（64bit）
バックアップ対象	`~/example-blog/data/views.db`
バックアップ先（ローカル）	`~/example-blog/data/backup/`
バックアップ先（OneDrive）	`VPS-Backup/db/`
スクリプト配置場所	`~/example-blog/backup-db.sh`
cron 実行時刻	毎日深夜 2 時
世代管理	直近 7 日分を保持

Step 1：rclone を VPS にインストールする

Ubuntu の apt パッケージリポジトリに収録されている rclone は古いバージョンのままになっていることがあります。
実際に sudo apt install rclone でインストールすると、v1.60.1-DEV という古いビルドが入ってしまいました。
公式スクリプトを使って最新版をインストールします。

すでに apt で rclone をインストール済みの場合は、まず削除します。

sudo apt remove -y rclone

次に、公式スクリプトで最新版をインストールします。

sudo -v ; curl https://rclone.org/install.sh | sudo bash

コマンドの意味を説明します。

sudo -v ：管理者権限の認証を先に済ませておきます
curl https://rclone.org/install.sh ：公式サイトからインストールスクリプトをダウンロードします
| sudo bash ：ダウンロードしたスクリプトを管理者権限で実行します

インストールが完了したら、バージョンを確認します。

rclone version

以下のように表示されれば成功です（バージョン番号は時期によって異なります）。

rclone v1.74.1 has successfully installed.
Now run "rclone config" for setup.

Step 2：Windows PC で OneDrive の認証を行う

VPS にはブラウザがないため、一時的に Windows PC 側で rclone を使って Microsoft アカウントの認証を行い、その結果得られるトークン（許可証）を VPS にコピーする方式を取ります。

なぜこの手順が必要なのか

OneDrive は外部ツールが勝手にアクセスすることを許可していません。
「この VPS が私の OneDrive を読み書きしていいですよ」という許可を Microsoft に伝えるための仕組みが OAuth 認証です。

認証が成功すると「トークン」という長い文字列が発行されます。
このトークンを VPS の rclone 設定に登録することで、以降は VPS から自動的に OneDrive にアクセスできるようになります。
OneDrive のパスワード自体は VPS に保存されません。

Windows PC に rclone をインストールする

PowerShell で以下を実行します。

winget install Rclone.Rclone

インストール後、PowerShell を一度閉じて再度開き、バージョンを確認します。

rclone version

VPS と同じバージョンが表示されることを確認します。
バージョンを揃えることで動作が安定します。

OneDrive の認証トークンを取得する

PowerShell で以下を実行します。

rclone authorize "onedrive"

実行するとブラウザが自動的に開き、Microsoft アカウントのログイン画面が表示されます。
ログイン後「rclone にアクセスを許可しますか？」という画面で「はい」をクリックします。

注意： ブラウザが開いたら 30 秒以内にログインしてください。
時間がかかりすぎると Microsoft 側でエラーが発生します。
その場合は Ctrl + C でキャンセルし、ブラウザのキャッシュをクリアしてから再実行します。

認証が成功すると、ブラウザに「Success!」と表示され、PowerShell 画面に以下のような形式でトークンが表示されます。

Paste the following into your remote machine --->
{"access_token":"eyJ...（長い文字列）...","expiry":"2026-..."}
<---End paste

{ から } までの JSON 文字列全体をコピーして、次のステップで使います。

セキュリティ上の注意： このトークンは個人の認証情報を含むため、チャットや公開の場所に貼り付けてはいけません。

Step 3：VPS に rclone の設定を行う

VPS 側で rclone の設定を対話形式で行います。

rclone config

以下の順番で入力していきます。

# 新しいリモート（接続先）を作成する
e/n/d/r/c/s/q> n

# リモートの名前（後でスクリプトで使う）
name> onedrive

# ストレージの種類（onedrive と入力するか番号で選ぶ）
Storage> onedrive

# クライアント ID（空のまま Enter）
client_id>

# クライアントシークレット（空のまま Enter）
client_secret>

# リージョン（1 を選ぶ：Microsoft Cloud Global）
region> 1

# テナント ID（空のまま Enter）
tenant>

# 詳細設定は不要
Edit advanced config? n

# VPS にはブラウザがないので n を選ぶ
Use web browser to automatically authenticate? n

ここで以下のメッセージが表示されます。

Execute the following on the machine with the web browser:
    rclone authorize "onedrive"
Then paste the result.
config_token>

Step 2 で Windows PC の PowerShell に表示された { から } までの JSON 文字列を貼り付けて Enter を押します。

続いて接続タイプを選択する画面が表示されます。
「OneDrive Personal or Business」を選びます。

config_type> 1

次に、アカウントに紐づいているドライブの一覧が表示されます。
「Found drive “root” of type “personal”」と表示されている項目を選びます。

確認画面では y を選んで保存し、最後に q で終了します。

接続テスト：

rclone lsd onedrive:

OneDrive のフォルダ一覧が表示されれば接続成功です。

Step 4：OneDrive にバックアップ用フォルダを作成する

バックアップファイルの保存先フォルダを作成します。

フォルダ名を SQLite-Backup と VPS-Backup のどちらにするか検討しました。
将来的に SQLite データベース以外のファイルもバックアップしたくなった場合に同じフォルダの中にサブフォルダで整理できる拡張性を考えて、VPS-Backup を採用しました。

rclone mkdir onedrive:VPS-Backup/db

確認します。

rclone lsd onedrive:VPS-Backup

db フォルダが表示されれば成功です。

Step 5：バックアップスクリプトを作成する

スクリプトを作成します。

nano ~/example-blog/backup-db.sh

以下の内容を貼り付けます。

#!/bin/bash
set -euo pipefail

# ===== 設定 =====
DB_PATH="$HOME/example-blog/data/views.db"
BACKUP_DIR="$HOME/example-blog/data/backup"
RCLONE_DEST="onedrive:VPS-Backup/db"
KEEP_DAYS=7
BACKUP_DATE=$(date +%Y%m%d)
BACKUP_FILE="$BACKUP_DIR/views_$BACKUP_DATE.db"
LOCK_FILE="$BACKUP_DIR/backup.lock"
LOG_FILE="$BACKUP_DIR/backup.log"
START_TIME=$(date +%s)

# ===== ログ関数 =====
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

# ===== バックアップ先ディレクトリを作成 =====
mkdir -p "$BACKUP_DIR"

# ===== ログローテーション（5000行超で古い行を切り捨て）=====
if [[ -f "$LOG_FILE" ]] && [[ $(wc -l < "$LOG_FILE") -gt 5000 ]]; then
    tail -n 5000 "$LOG_FILE" > "${LOG_FILE}.tmp" && mv "${LOG_FILE}.tmp" "$LOG_FILE"
fi

# ===== 外部コマンドの stderr をログファイルへ記録 =====
exec 2>> "$LOG_FILE"

# ===== 同時実行の防止 =====
exec 9>"$LOCK_FILE"
if ! flock -n 9; then
    log "エラー: 別のバックアッププロセスが実行中です - 処理を中断します"
    exit 1
fi

# ===== 異常終了時のクリーンアップ =====
cleanup() {
    local exit_code=$?
    if [[ $exit_code -ne 0 && -f "$BACKUP_FILE" ]]; then
        rm -f "$BACKUP_FILE"
        log "クリーンアップ: 不完全なバックアップファイルを削除しました"
    fi
}
trap cleanup EXIT

log "===== バックアップ開始 ====="

# ===== ディスク空き容量の事前確認 =====
AVAIL_KB=$(df -P "$BACKUP_DIR" | awk 'NR==2 {print $4}')
DB_SIZE=$(stat -c%s "$DB_PATH" 2>/dev/null || echo 0)
if [[ $(( AVAIL_KB * 1024 )) -le $DB_SIZE ]]; then
    log "エラー: ディスク空き容量不足 (空き: $((AVAIL_KB / 1024))MB, DB: $((DB_SIZE / 1024 / 1024))MB)"
    exit 1
fi

# ===== DB ファイルの存在確認 =====
if [[ ! -f "$DB_PATH" ]]; then
    log "エラー: DB ファイルが見つかりません: $DB_PATH"
    exit 1
fi

# ===== SQLite のバックアップ =====
log "SQLite バックアップ中..."
if sqlite3 "$DB_PATH" ".backup '$BACKUP_FILE'"; then
    log "SQLite バックアップ成功: $BACKUP_FILE"
else
    log "エラー: SQLite バックアップ失敗 - 処理を中断します"
    exit 1
fi

# ===== バックアップファイルのサイズ検証 =====
BACKUP_SIZE=$(stat -c%s "$BACKUP_FILE")
if [[ "$BACKUP_SIZE" -eq 0 ]]; then
    log "エラー: バックアップファイルが空です (0 bytes)"
    exit 1
fi
log "バックアップファイルサイズ: $((BACKUP_SIZE / 1024))KB"

# ===== バックアップファイルの整合性検証 =====
log "整合性チェック中..."
if sqlite3 "$BACKUP_FILE" "PRAGMA integrity_check;" | grep -q "^ok$"; then
    log "整合性チェック成功"
else
    log "エラー: バックアップファイルの整合性チェック失敗 - 処理を中断します"
    exit 1
fi

# ===== OneDrive にアップロード =====
log "OneDrive へアップロード中..."
if rclone copy "$BACKUP_FILE" "$RCLONE_DEST" --log-level INFO; then
    log "OneDrive アップロード成功"
else
    log "エラー: OneDrive アップロード失敗"
    exit 1
fi

# ===== 古いローカルバックアップを削除 =====
log "古いローカルバックアップを削除中..."
CUTOFF_DATE=$(date -d "-${KEEP_DAYS} days" +%Y%m%d)
for fpath in "$BACKUP_DIR"/views_*.db; do
    [[ -f "$fpath" ]] || continue
    fname=$(basename "$fpath")
    FDATE="${fname#views_}"
    FDATE="${FDATE%.db}"
    if [[ ! "$FDATE" =~ ^[0-9]{8}$ ]]; then
        log "警告: 想定外のファイル名をスキップ（ローカル）: $fname"
        continue
    fi
    if [[ "$FDATE" < "$CUTOFF_DATE" ]]; then
        rm -f "$fpath"
        log "削除（ローカル）: $fname"
    fi
done
log "ローカル古ファイル削除完了"

# ===== 古い OneDrive 上のバックアップを削除 =====
log "古い OneDrive バックアップを削除中..."
if ! rclone_list=$(rclone lsf "$RCLONE_DEST"); then
    log "エラー: OneDrive ファイル一覧の取得失敗 - 削除処理をスキップします"
else
    while read -r fname; do
        FDATE="${fname#views_}"
        FDATE="${FDATE%.db}"
        if [[ ! "$FDATE" =~ ^[0-9]{8}$ ]]; then
            log "警告: 想定外のファイル名をスキップ（OneDrive）: $fname"
            continue
        fi
        if [[ "$FDATE" < "$CUTOFF_DATE" ]]; then
            rclone deletefile "$RCLONE_DEST/$fname" || log "警告: OneDrive 削除失敗（続行）: $fname"
            log "削除（OneDrive）: $fname"
        fi
    done <<< "$rclone_list"
fi
log "OneDrive 古ファイル削除完了"

ELAPSED=$(( $(date +%s) - START_TIME ))
log "===== バックアップ完了（所要時間: ${ELAPSED}秒）====="

Ctrl + X → Y → Enter で保存します。

スクリプトの主要な処理を解説する

スクリプトの各処理について説明します。

set -euo pipefail

set -euo pipefail

スクリプトの安全装置です。

set -e ：コマンドが 1 つでも失敗したらスクリプト全体を即座に停止します
set -u ：未定義の変数を使おうとしたらエラーにします
set -o pipefail ：パイプ（|）でつないだコマンドの途中が失敗しても検出します

ログ関数

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

log "メッセージ" と書くと、[2026-05-17 16:14:04] メッセージ という形式でターミナルと backup.log の両方に同時に記録します。

ログローテーション

if [[ -f "$LOG_FILE" ]] && [[ $(wc -l < "$LOG_FILE") -gt 5000 ]]; then
    tail -n 5000 "$LOG_FILE" > "${LOG_FILE}.tmp" && mv "${LOG_FILE}.tmp" "$LOG_FILE"
fi

毎日ログが追記されていくと、長期運用でファイルが肥大化します。
5000 行を超えたら古い行を捨てて最新の 5000 行だけを残します。

一旦 .tmp ファイルに書いてから mv で置き換えているのは、書き込み中にファイルを上書きするとデータが壊れるリスクがあるためです。

stderr のログ記録

exec 2>> "$LOG_FILE"

これ以降のすべての標準エラー出力（stderr）を backup.log に記録するよう設定します。
sqlite3 や rclone がエラーメッセージを出した場合も、ログファイルに残るため、問題が起きたときに原因を調査できます。

同時実行の防止

exec 9>"$LOCK_FILE"
if ! flock -n 9; then
    log "エラー: 別のバックアッププロセスが実行中です - 処理を中断します"
    exit 1
fi

cron で定期実行している場合、前回のバックアップがまだ終わっていないのに次の実行が始まることがあります。
このような「多重起動」が起きると、同じファイルへの書き込みが重なり、バックアップが壊れる可能性があります。

flock コマンドを使ってロックファイルを取得することで、1 つのバックアッププロセスしか動けない仕組みを作っています。
スクリプトが終了すると自動的にロックも解放されます。

異常終了時のクリーンアップ

cleanup() {
    local exit_code=$?
    if [[ $exit_code -ne 0 && -f "$BACKUP_FILE" ]]; then
        rm -f "$BACKUP_FILE"
        log "クリーンアップ: 不完全なバックアップファイルを削除しました"
    fi
}
trap cleanup EXIT

trap cleanup EXIT は「スクリプトが終了するとき（正常・異常を問わず）に cleanup 関数を実行する」という設定です。

異常終了したときは、作りかけの不完全なバックアップファイルを自動削除します。
不完全なファイルが残っていると、誤って復元に使おうとしたときに問題になるためです。

SQLite のバックアップコマンド

sqlite3 "$DB_PATH" ".backup '$BACKUP_FILE'"

SQLite が公式に提供する .backup コマンドを使います。
単純なファイルコピー（cp コマンド）との違いは次の通りです。

方法	書き込み中の安全性
`cp` コマンド	❌ 書き込み中にコピーするとデータが壊れる可能性がある
`.backup` コマンド	✅ 書き込み中でも整合性を保ったままコピーできる

ブログは 24 時間アクセスを受け付けているため、バックアップ中に誰かがアクセスしてデータベースに書き込みが発生する可能性があります。
.backup コマンドを使うことで、そのような状況でも安全にバックアップできます。

整合性の検証

sqlite3 "$BACKUP_FILE" "PRAGMA integrity_check;" | grep -q "^ok$"

PRAGMA integrity_check は SQLite 公式の検証コマンドです。
データベースの内部構造が壊れていないかを確認し、正常な場合のみ ok を返します。

バックアップコマンドが成功したように見えても、稀にファイルが壊れていることがあります。
壊れたファイルを OneDrive にアップロードしても復元に使えないため、アップロード前にこのチェックを行います。

古いファイルの削除（ファイル名の日付で判断）

CUTOFF_DATE=$(date -d "-${KEEP_DAYS} days" +%Y%m%d)
for fpath in "$BACKUP_DIR"/views_*.db; do
    fname=$(basename "$fpath")
    FDATE="${fname#views_}"
    FDATE="${FDATE%.db}"
    if [[ ! "$FDATE" =~ ^[0-9]{8}$ ]]; then continue; fi
    if [[ "$FDATE" < "$CUTOFF_DATE" ]]; then
        rm -f "$fpath"
    fi
done

古いバックアップの削除基準として「ファイルの更新日時（-mtime）」ではなく、ファイル名に含まれる日付を使っています。

-mtime を使う方法は、ファイルを touch コマンドで触ったりバックアップから復元したりした場合に、意図しない動作をするリスクがあります。

ファイル名（例：views_20260517.db）から日付（20260517）を取り出して比較する方法は、ローカルと OneDrive で同じロジックが使えるため、一貫性があり保守しやすくなります。

YYYYMMDD 形式の日付は、文字列としてそのまま比較するだけで正しい時系列の比較になります（辞書順と時系列が一致するためです）。

Step 6：動作確認をする

スクリプトに実行権限を付与して、手動で実行します。

chmod +x ~/example-blog/backup-db.sh
~/example-blog/backup-db.sh

正常に動作した場合、以下のような出力が表示されます。
（日付や時刻は、実行した時点のものになります）

[2026-05-17 16:21:07] ===== バックアップ開始 =====
[2026-05-17 16:21:07] SQLite バックアップ中...
[2026-05-17 16:21:07] SQLite バックアップ成功: /home/ユーザー名/example-blog/data/backup/views_20260517.db
[2026-05-17 16:21:07] バックアップファイルサイズ: 28KB
[2026-05-17 16:21:07] 整合性チェック中...
[2026-05-17 16:21:07] 整合性チェック成功
[2026-05-17 16:21:07] OneDrive へアップロード中...
[2026-05-17 16:21:16] OneDrive アップロード成功
[2026-05-17 16:21:16] 古いローカルバックアップを削除中...
[2026-05-17 16:21:16] ローカル古ファイル削除完了
[2026-05-17 16:21:16] 古い OneDrive バックアップを削除中...
[2026-05-17 16:21:22] OneDrive 古ファイル削除完了
[2026-05-17 16:21:22] ===== バックアップ完了（所要時間: 15秒）=====

OneDrive 上にファイルが届いているかを確認します。

rclone lsf onedrive:VPS-Backup/db

views_20260517.db

Windows PC の OneDrive フォルダを開いて VPS-Backup/db/views_20260517.db が存在することも目視で確認してください。
（日付は実行日になります）

Step 7：cron に登録して毎日自動実行する

cron とは

cron は Linux に標準搭載されているタスクスケジューラです。
「毎日〇時に△のコマンドを実行する」という設定を登録しておくと、VPS が起動している限り自動的に実行され続けます。

crontab の書き方

cron の設定は以下の形式で書きます。

分  時  日  月  曜日  コマンド
0   2   *   *   *    （コマンド）

* は「毎回」を意味します。上の例は「毎日（*）の午前 2 時 0 分」です。

設定の編集

以下のコマンドで設定ファイルを開きます。

crontab -e

初めて開く場合はエディタの選択を求められます。1（nano）を選んでください。

ファイルの末尾に以下の 2 行を追加します。

MAILTO=""
0 2 * * * /bin/bash /home/ユーザー名/example-blog/backup-db.sh >> /home/ユーザー名/example-blog/data/backup/backup.log 2>&1

各部分の意味を説明します。

MAILTO="" ：cron のエラーメール通知を無効にします。スクリプト内のログで管理するため不要です
/bin/bash ：bash のフルパスを明示します。cron の実行環境は通常のターミナルより PATH が限定されているため、明示的に指定します
/home/ユーザー名/example-blog/backup-db.sh ：スクリプトの絶対パスで指定します。~ は cron では展開されないため使いません

Ctrl + X → Y → Enter で保存し、設定を確認します。

crontab -l

登録した内容が表示されれば完了です。

ログの確認方法

翌日の深夜 2 時以降に以下のコマンドでログを確認できます。

cat ~/example-blog/data/backup/backup.log

バックアップ体制の全体像

第 23 回・第 24 回が完了した時点でのバックアップ体制をまとめます。

【VPS：~/example-blog/】
  ソースコード
    └─ git push → GitHub プライベートリポジトリ
                       ↑ バージョン管理つき・任意の時点に戻せる

  data/views.db（SQLite データベース）
    ↓ backup-db.sh（毎日深夜 2 時・cron 自動実行）
  data/backup/views_YYYYMMDD.db（直近 7 日分・ローカル保持）
    ↓ rclone copy
【OneDrive：VPS-Backup/db/】
  views_YYYYMMDD.db（直近 7 日分・自動削除）
        ↑ 完全自動・手動作業なし

補足：Azure アプリを登録してアクセスを特定フォルダに限定する方法

rclone のデフォルト設定では、OneDrive 全体への読み書き権限が与えられます。
Obsidian の Remotely Save プラグインのように「特定のフォルダのみ」に限定したい場合は、Azure Portal でアプリを登録して Files.ReadWrite.AppFolder スコープを設定する方法があります。

今回バックアップする内容は URL と閲覧数のみのため、デフォルト設定でも実害はほぼありませんが、より厳密なセキュリティが必要な場合の参考としてください。

必要な手順の概要：

Azure Portal（https://portal.azure.com）にアクセスしてアプリを登録する
Files.ReadWrite.AppFolder スコープを設定する
クライアント ID とクライアントシークレットを取得する
rclone config の client_id と client_secret に入力する

この設定を行うと、rclone は アプリ/rclone/ というフォルダの中にしかアクセスできなくなります。

まとめ

この記事では、VPS 上の SQLite データベースを rclone と OneDrive を使って毎日自動バックアップする仕組みを構築しました。

今回構築したバックアップスクリプトは、エラーチェック・整合性検証・ログ記録・世代管理まで含めた実用的な内容になっています。一度設定してしまえば、あとは cron が毎日深夜に自動的に実行してくれます。

Git と GitHub を使った Next.js のコードのバックアップや更新履歴管理に加え、データベースのバックアップもできるようになり、ここまで作ってきたサイトを守ることができるようになったので、とても安心感があります。
今回のデータベースのバックアップは、スクリプトを作って、cron の自動実行も設定したので、あとは特に何もしなくても良いというのも助かりますね。

第 23 回（Git + GitHub によるソースコードのバックアップ）と今回で、VPS ブログのバックアップ体制が一通り整いました。

引き続き Next.js ブログサイトの構築シリーズを続けていきます。
公開までしばらくお待ちください。