ResticでVPSを毎日自動バックアップする方法【2026年版】

「VPS のバックアップ、いつ取ったか覚えていない」——そんな状態なら、Restic（レスティック）でのバックアップを毎日自動で回す仕組みを作っておくのがおすすめです。restic は無料のオープンソースのバックアップソフトで、暗号化・重複の削除・世代管理・復元の確認までを1つのコマンドでこなせます。

restic · Backups done right!

2026年11月13日時点の最新版は restic 0.19.1（2026年7月5日公開）です。この記事では、VPS に restic を入れてから、毎日の自動実行（cron / systemd timer）と、本当に戻せるかの復元テストまでを、コピーして使えるコマンドつきで順番に解説します。テスト用の Linux 環境で実際に動かした結果も載せています。

Resticとは？一言でまとめると

restic は、「暗号化してから、変わった部分だけを保存先へ送る」バックアップソフトです。Go で書かれた1つの実行ファイルで、サーバー側に専用のソフトを入れる必要はありません。

ポイントは、暗号化が VPS の中で終わってから送られることです。保存先の事業者や、保存先に入り込んだ人が見られるのは暗号化された塊だけです。その代わり、リポジトリのパスワードを失うと、本人でも二度と復元できません。ここは後の手順で対策します。

0.19 系では、zstd の圧縮モード（fastest・better）の追加や、大きなリポジトリでの読み込みの高速化が入りました。また 0.19.0 から、backup に直接指定したパスには除外ルールがかからなくなったので、古い版から上げる人はスクリプトの除外設定を見直しておくと安心です。

tar・rsyncとの違い：Resticを選ぶ理由

VPS のバックアップでよく見るのは、tar で固めて cron で回す方法と、rsync で別サーバーに同期する方法です。どちらも手軽ですが、毎日続けると弱点が出てきます。

• tar＋cron: 毎回まるごと固めるので、容量と転送量が日数分ふくらみます。暗号化も自分で足す必要があります
• rsync: 変わった分だけ送れて速い反面、消したファイルも同期で消えることがあり、「昨日の状態に戻したい」に弱い方法です
• restic: 変わった塊だけを送り、スナップショットとして世代が残ります。暗号化・世代の整理・壊れていないかの確認（check）までコマンドがそろっています

VPS 事業者の自動バックアップ（スナップショット）機能も便利ですが、多くは同じ事業者の中に保存されます。アカウントの乗っ取りや事業者側の障害に備えるなら、restic で事業者の外にもう1つ持つ組み合わせが心強いと考えています。XServer VPS の自動バックアップの中身は、こちらで解説しています。

あわせて読みたい

XServer VPSビジネスプランとは？通常・クラウドとの違い

始める前に決めること：保存先・対象・残す世代

手順に入る前に、3つだけ決めておきます。ここが決まっていれば、あとはコマンドを順に打つだけです。

① 保存先（リポジトリ）

例として Cloudflare R2 は、毎月 10GB までの保存と、100万件の書き込み系・1,000万件の読み出し系の操作が無料で、超えた分は 1GB・月 0.015ドル、ダウンロード（egress）は無料です（2026年11月13日時点）。リポジトリが 10GB に収まるうちは、保存の料金はかかりません。

② バックアップする対象

• サイトのファイル: /var/www など
• 設定ファイル: /etc（Nginx・PHP・cron の設定など）
• データベース: ファイルを直接コピーせず、ダンプ（mysqldump など）を restic に流し込むのが安全です

OS 全体を丸ごと取るより、戻すときに必要なデータだけに絞ると、容量も時間も小さく済みます。

③ 残す世代

迷ったら 「毎日7つ・毎週4つ・毎月6つ」から始めるのがおすすめです。1週間以内ならどの日にも戻れて、それより前は週ごと・月ごとにさかのぼれます。

VPS を借りた直後の初期設定（SSH の鍵認証・ファイアウォールなど）がまだの人は、先にこちらを済ませておくと安心です。

あわせて読みたい

さくらのVPSのセキュリティ初期設定：最初にやる5つの対策【2026年版】

手順① Resticをインストールする

全体の流れは次の6つです。ここから順番に進めます。テスト用の環境で実際に動かした記録（つまずいた所も含む）は、後半の「実際にセットアップしてみた」にまとめています。

入れ方は3つあります。おすすめは公式バイナリです。

注意したいのが apt です。Ubuntu 24.04 の apt で入るのは 0.16.4 で、終了コード 10（リポジトリが無い）・11（ロックできない）・12（パスワード違い）は 0.17 以降の機能なので、スクリプトでの失敗の見分けにも差が出ます。公式ドキュメントも、パッケージが古いときは公式バイナリを使うよう案内しています。

公式バイナリは、GitHub のリリースからダウンロードし、チェックサム（SHA-256）を照合してから置きます。

cd /tmp
curl -LO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
curl -LO https://github.com/restic/restic/releases/download/v0.19.1/SHA256SUMS
sha256sum --ignore-missing -c SHA256SUMS
bunzip2 restic_0.19.1_linux_amd64.bz2
sudo install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

restic_0.19.1_linux_amd64.bz2: OK
restic 0.19.1 compiled with go1.26.4 on linux/amd64

bunzip2 が無いと言われたら、sudo apt install bzip2 で入れてください。ARM の VPS なら、ファイル名の amd64 を arm64 に変えます。以後の更新は sudo restic self-update だけで済みます。

手順② リポジトリを作ってパスワードを保管する

restic では、バックアップの保存場所をリポジトリと呼びます。最初に1回だけ init で作ります。毎回パスワードを打たずに済むよう、パスワードと保存先をファイルに書いて、root だけが読めるようにしておきます。

sudo mkdir -p /etc/restic
openssl rand -base64 32 | sudo tee /etc/restic/password > /dev/null
sudo chmod 600 /etc/restic/password

RESTIC_REPOSITORY=/srv/restic-repo
RESTIC_PASSWORD_FILE=/etc/restic/password

sudo chmod 600 /etc/restic/env
sudo sh -c 'set -a; . /etc/restic/env; restic init'

created restic repository d990f81fa6 at /backup/restic-repo

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

最後の英文は「パスワードを失うとデータは二度と戻らない」という警告です。/etc/restic/password の中身は、パスワード管理アプリなど VPS の外にも必ず控えておきましょう。VPS が丸ごと消えたとき、新しいサーバーから復元するのに必要になります。restic key add で2つ目のパスワードを足しておくこともできます。

保存先を VPS の外にする場合

ローカルで動きを確かめたら、本番は VPS の外に置くのがおすすめです。/etc/restic/env を次のように書き換えて、もう一度 init します（アカウントやバケットは各サービスで先に用意します）。

RESTIC_REPOSITORY=sftp:backup@203.0.113.10:/srv/restic-repo
RESTIC_PASSWORD_FILE=/etc/restic/password

RESTIC_REPOSITORY=s3:https://<ACCOUNT_ID>.r2.cloudflarestorage.com/<バケット名>
RESTIC_PASSWORD_FILE=/etc/restic/password
AWS_ACCESS_KEY_ID=<R2のアクセスキーID>
AWS_SECRET_ACCESS_KEY=<R2のシークレットアクセスキー>

SFTP は、root から接続先へパスワードなしの SSH 鍵でログインできることが条件です（cron や systemd は root で動くため、root の鍵が必要です）。R2 のリージョンは auto 扱いなので、restic 側でリージョンを指定しなくても動く設計です。

手順③ 初回バックアップとスナップショットの確認

準備ができたら、最初のバックアップを取ります。--verbose を付けると、何がどれだけ保存されたかが分かります。

sudo sh -c 'set -a; . /etc/restic/env; restic backup --verbose /var/www /etc'
sudo sh -c 'set -a; . /etc/restic/env; restic snapshots'

Files:          52 new,     0 changed,     0 unmodified
Added to the repository: 50.022 MiB (50.014 MiB stored)
snapshot ae45a43d saved

2回目からは、変わった部分だけが保存されます。テスト用の約50MBのデータで1ファイルに1行足しただけの場合、増えたのは 18.641 KiB（圧縮後 3.429 KiB）でした。毎日取っても容量がほとんど増えないのが、restic を毎日回せる理由です。

データベースはダンプを直接流し込む

WordPress などのデータベースは、--stdin-from-command でダンプの出力をそのままスナップショットにするのが手軽です。ダンプのコマンドが失敗すると、restic はスナップショットを作りません。

sudo sh -c 'set -a; . /etc/restic/env; restic backup --stdin-filename wordpress.sql --stdin-from-command -- mysqldump --single-transaction wordpress'

除外したいものがあるとき

キャッシュやログなど、戻す必要のないものは外すと速くなります。

手順④ forgetとpruneで世代を管理する

毎日バックアップすると、スナップショットは毎日1つずつ増えます。forget は残すルールに合わないスナップショットの記録を消し、prune は使われなくなったデータを実際に消して容量を空けます。forget だけでは容量は減らないので、--prune を付けて一緒に動かすのが基本です。

ルールは「どれか1つに当てはまれば残す」という考え方です。たとえば毎日1回バックアップしている場合、--keep-daily 7 --keep-weekly 4 で残るのは次のようになります。

ルールを変えたら、まず --dry-run で何が消えるかを見てから実行します。

sudo sh -c 'set -a; . /etc/restic/env; restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run'
sudo sh -c 'set -a; . /etc/restic/env; restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune'

prune の間はリポジトリがロックされ、バックアップが取れません。データが多いと時間もかかるので、バックアップの直後に続けて動かすか、R2 などで転送量が気になるなら週1回にずらすのが無難です。ルールはホスト名とパスの組ごとに当てはめられるため、別のサーバーのスナップショットを誤って消す心配はありません。

手順⑤ cron・systemd timerで毎日自動で動かす

restic 自体には「毎日動かす」機能がありません。cron か systemd timer に、バックアップ → 世代の整理 → 確認をまとめたスクリプトを登録します。

① スクリプトを作る

#!/bin/sh
set -u
set -a; . /etc/restic/env; set +a

restic backup /var/www /etc --exclude-caches --tag daily
rc=$?
# 0 = 成功、3 = 一部のファイルを読めなかった（スナップショットは作られる）
if [ "$rc" -ne 0 ] && [ "$rc" -ne 3 ]; then
  echo "restic backup failed (exit $rc)" >&2
  exit "$rc"
fi

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune || exit $?
restic check --read-data-subset=5% || exit $?

sudo chmod 700 /usr/local/bin/restic-backup.sh
sudo /usr/local/bin/restic-backup.sh

backup の終了コード 3 は「一部のファイルが読めなかったが、スナップショットは作った」という意味です。set -e で書くとここで止まってしまうので、上のように 0 と 3 を分けて扱います。まず手で1回実行して、エラーなく終わるかを確かめてから自動化に進みます。

② systemd timer で毎日3時に動かす（おすすめ）

[Unit]
Description=restic backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/restic-backup.sh
Nice=10
IOSchedulingClass=idle

[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=15min
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer
journalctl -u restic-backup.service -n 50

Persistent=true にすると、3時に VPS が止まっていた日も、起動したあとに取り逃した分を実行します。RandomizedDelaySec は、同じ時刻に処理が集中しないよう最大15分ずらす設定です。タイマーの時刻に前の回がまだ動いていれば、systemd は新しく起動し直さないので、二重実行の心配も小さくなります。結果は journalctl で見られます。

③ cron で動かす場合

cron を使い慣れているなら、/etc/cron.d/ に1行足すだけです。flock -n で、前の回が終わっていなければ今回は動かさないようにしておきます。

0 3 * * * root flock -n /run/restic-backup.lock /usr/local/bin/restic-backup.sh >> /var/log/restic-backup.log 2>&1

手順⑥ checkと復元テストで「戻せる」を確かめる

バックアップは、戻せて初めて意味があります。restic には2種類の確かめ方があります。

sudo sh -c 'set -a; . /etc/restic/env; restic check'
sudo sh -c 'set -a; . /etc/restic/env; restic restore latest --target /tmp/restore-test'
sudo diff -r /var/www /tmp/restore-test/var/www && echo "一致しました"

no errors were found
Summary: Restored 56 files/dirs (50.002 MiB) in 0:00

check はリポジトリの構造が壊れていないかの確認、restore は実際に取り出してみる確認です。本番のフォルダに上書きせず、--target で別の場所に戻して比べるのが安全です。比べたあとは /tmp/restore-test を消しておきましょう。

1つのファイルだけ誤って消したときは、フォルダとファイルを指定してそれだけを戻せます。

sudo sh -c 'set -a; . /etc/restic/env; restic restore latest:/var/www/html --target /var/www/html --include /index.php'

確認の頻度は、次のくらいを目安にするとよいと考えています。

--read-data はデータを全部ダウンロードして確かめるため、S3 互換の保存先では時間と転送量がかかります。--read-data-subset で分けて読むのが現実的です。

Resticを運用している人の工夫

restic を実際の運用に入れている人の記事から、参考になる点をまとめます。

• 山口県の株式会社ホコサキは、tar＋cron と rsync の組み合わせから restic＋Cloudflare R2 に移した経緯を公開しています。毎日2時にバックアップし、週1回 forget と check、保持は7日・4週・3か月という設定で、「取れている」ことと「戻せる」ことは確かめ方が違うと強調しています（出典）
• Qiita の @masakai さんは、20人規模の町工場の NAS を systemd timer で毎日2時30分にバックアップし、--keep-daily 14 --keep-weekly 8 --keep-monthly 12 で整理しています。半年に1回は実際に戻す復元試験を勧めています（出典）
• Zenn の Penbit Lab は、Ubuntu Server を SFTP 先にバックアップする手順の中で、set -e だと終了コード3で止まる点、cron や sudo では ~ が /root になる点、forget だけでは容量が空かない点をつまずきやすい所として挙げています（出典）

3つに共通するのは、毎日の自動化に加えて、定期的に「戻す練習」を予定に入れていることです。

実際にセットアップしてみた

2026年11月13日に、テスト用の Linux 環境（Docker）で次の手順を実際に動かしました。restic の公式イメージ restic/restic:0.19.1 と Ubuntu 24.04 のコンテナを使い、保存先は同じ環境の中のフォルダ（/backup/restic-repo）です。バックアップしたのは、テスト用に作った約50MB・52ファイルのデータ（/srv/www）です。

① 公式バイナリを入れる

Ubuntu 24.04 のコンテナで、上の手順①と同じように GitHub のリリースから restic_0.19.1_linux_amd64.bz2 と SHA256SUMS を取ってきて入れました。

sha256sum --ignore-missing -c SHA256SUMS
bunzip2 restic_0.19.1_linux_amd64.bz2
install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

restic_0.19.1_linux_amd64.bz2: OK
restic 0.19.1 compiled with go1.26.4 on linux/amd64

最初は bunzip2 が入っていなかったので、apt で bzip2 を足しました。比べるために apt の restic も入れてみると、入ったのは古い版で、self-update もありませんでした。

apt-get install restic
restic version
restic self-update

restic 0.16.4 compiled with go1.22.2 on linux/amd64
unknown command "self-update" for "restic"

② リポジトリを作り、2回バックアップする

ここからは restic/restic:0.19.1 のコンテナで、環境変数 RESTIC_REPOSITORY（/backup/restic-repo）と RESTIC_PASSWORD_FILE を設定して動かしました。2回目の前に、1つのファイルに1行足しています。

restic init
restic backup --verbose /srv/www
echo "page 1 updated" >> /srv/www/html/page1.html
restic backup --verbose /srv/www
restic snapshots

1回目は52ファイルで 50.022 MiB がリポジトリに入り、2回目は「using parent snapshot ae45a43d」と前回を使って、18.641 KiB（保存したのは 3.429 KiB） だけ増えました。変わった所だけが入るので、毎日取っても容量はほとんど増えません。

③ 暗号化とパスワードを確かめる

grep -r "DB_NAME" /backup/restic-repo
RESTIC_PASSWORD=wrongpass restic snapshots

(exit 1)
Fatal: wrong password or no key found
(exit 12)

元のファイルにあった文字列（DB_NAME）は、リポジトリの中を探しても見つかりませんでした（暗号化されている）。パスワードを間違えると「Fatal: wrong password or no key found」で、終了コードは 12 です。

④ check をかけて、別の場所に戻す

restic check
restic check --read-data-subset=10%
restic restore latest --target /restore
diff -r /srv/www /restore/srv/www
rm /srv/www/html/page1.html
restic restore latest:/srv/www/html --target /srv/www/html --include /page1.html

check はどちらも「no errors were found」。別のフォルダに戻したファイルは元と diff -r で差分なし、50MB のファイルの SHA-256 も一致しました。消した page1.html だけを戻すと「Restored 1 files/dirs (48 B)」で、中身は2回目のバックアップの内容（追記した行を含む2行）でした。

⑤ forget と prune で世代を整理する

毎日の世代の整理は、練習用の別のリポジトリで試しました。restic backup --time で、10月1日〜11月13日の毎日3時の日付を付けたスナップショットを44個作っています（実際に44日間動かしたものではありません）。

restic forget --keep-daily 7 --keep-weekly 4 --dry-run
restic forget --keep-daily 7 --keep-weekly 4 --prune
restic check

--dry-run で「keep 9 snapshots」「remove 35 snapshots」と、消える前に結果が分かります。週ごとの分は 10/25・11/1 が残り、11/8 と 11/13 は日ごと・週ごとの両方に数えられていました。--prune を付けると35個が消えて使われなくなったデータも削除され、その後の check も「no errors were found」でした。

⑥ スクリプトを1回動かし、タイマーの設定を確かめる

上の手順⑤のスクリプト（restic-backup.sh）を、restic/restic:0.19.1 のコンテナで1回実行しました。

/usr/local/bin/restic-backup.sh

snapshot ad70988b saved
Applying Policy: keep 7 daily, 4 weekly, 6 monthly snapshots
read 5.0% of packfiles
no errors were found
(exit 0)

バックアップ → 世代の整理 → check がエラーなく続けて終わりました。systemd のユニットは Ubuntu 24.04 のコンテナで文法だけ確かめ、systemd-analyze verify は警告・エラーなし（exit 0）、毎日3時の指定は次のように解釈されました。

systemd-analyze verify /etc/systemd/system/restic-backup.timer /etc/systemd/system/restic-backup.service
systemd-analyze calendar --iterations=3 "*-*-* 03:00:00"

Normalized form: *-*-* 03:00:00
    Next elapse: Sat 2026-11-14 03:00:00 JST
   Iteration #2: Sun 2026-11-15 03:00:00 JST
   Iteration #3: Mon 2026-11-16 03:00:00 JST

この先は公式の手順

VPS の上で動かすこと、SFTP・Cloudflare R2 などリモートの保存先、タイマーで毎日動かし続けることは、今回は行っていません。上の「保存先を VPS の外にする場合」「手順⑤」で、公式ドキュメントの手順として説明しています。

よくある質問

Q. restic は無料ですか？ A. 無料です。BSD 2-Clause ライセンスのオープンソースです。費用がかかるのは保存先（S3 互換ストレージの容量や、2台目のサーバー）だけです。

Q. VPS 事業者の自動バックアップがあれば、restic は要りませんか？ A. 事業者の機能はサーバー丸ごとの復旧に強く、restic はファイル単位の復元や、事業者の外への保存に強い、と役割が違います。片方だけなら、事業者の外に置ける restic のほうが「事業者側のトラブル」には強い構成です。

Q. パスワードを忘れたら、どうにかなりますか？ A. なりません。公式ドキュメントも、パスワードを失うとデータは復元できないと明記しています。VPS の外にも控えを残し、restic key add で予備のパスワードを足しておくと安心です。

Q. WordPress のサイトなら、何をバックアップすればいいですか？ A. wp-content（テーマ・プラグイン・アップロード画像）を含むサイトのフォルダ、wp-config.php、データベースのダンプの3つが基本です。データベースは --stdin-from-command で mysqldump の出力をそのまま保存できます。

Q. バックアップ中にサイトが重くなりませんか？ A. 2回目以降は変わったファイルだけを読むので、初回より大幅に軽くなります。気になる場合は、systemd の Nice=10 と IOSchedulingClass=idle のように優先度を下げ、アクセスの少ない深夜に動かします。

Q. 複数の VPS を1つのリポジトリにまとめられますか？ A. できます。スナップショットはホスト名ごとに区別され、forget もホストとパスの組ごとにルールを当てはめます。Docker で動かす場合は、--hostname でホスト名を固定してください。

VPS 選びから見直したい人は、こちらも参考にしてください。

あわせて読みたい

【2026年版】VPSおすすめの選び方｜失敗しやすいポイントと候補まとめ

まとめ

Restic で VPS を毎日自動バックアップする方法のポイントをまとめます。

• 最新版：restic 0.19.1（2026年7月5日公開、2026年11月13日時点）
• 入れ方：公式バイナリがおすすめ（Ubuntu 24.04 の apt は 0.16.4）
• 暗号化：AES-256。パスワードを失うと復元できないので VPS の外にも控える
• 保存先：まずローカルで試し、本番は SFTP（別サーバー）か S3 互換（R2 など）
• 世代管理：forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune から始める
• 自動化：systemd timer（Persistent=true）か cron（flock で二重実行を防ぐ）
• 確認：毎日 check --read-data-subset、月1回は restore と diff で戻す練習

まずは今日、ローカルのリポジトリで init → backup → restore を一度通してみて、戻せることを確かめるところから始めてみてください。

XServer VPS を使っている人は、最初にやるセキュリティ対策もあわせて確認しておくと安心です。

あわせて読みたい

XServer VPSのセキュリティ対策：最初にやる6つの設定【2026年版】

IT Picks 編集部

ITツール・Webサービス紹介メディア

IT Picks 編集部。VPS・クラウド・AIツール・SaaSを中心に、実際に検証した情報を届けるITメディアです。「本当に使えるか」を基準に、初心者からエンジニアまで役立つ記事を制作しています。