rsnapshotバックアップ完全ガイド：Linux、Windows共有、NAS、Samba

rsnapshotは、Linuxバックアップサーバー上に直接閲覧できる履歴を保存する用途に適しています。rsyncで同期し、変更のないファイルはハードリンクで再利用します。

そのため、daily.0、daily.1、weekly.0はいずれも完全なバックアップに見えますが、変更のない同一ファイルが消費するデータ領域は通常1つ分だけです。復元時に専用データベースを読み込む必要はなく、対象のスナップショットからファイルをコピーできます。

この記事は、次の 4 つのカテゴリのソースで構成されています。

Linux ネイティブディレクトリ。
SSH 経由でアクセスされるリモート Linux ディレクトリ。
Windows または Samba 共有。
SMB/CIFS または NFS 経由でファイルを提供する NAS。

この例では、スナップショットを均一に書き込みます。

1

/mnt/backup/rsnapshot/

作業を始める前に、例示したIPアドレス、ユーザー名、共有名、ディレクトリを実際の環境に合わせて置き換えてください。

機能概要と基本コマンド

rsnapshotのデータフロー

最も一般的な展開方法は、Linux マシンをバックアップサーバーとして機能させることです。

1
2
3


Linux 本机目录 ───────────────┐
远程 Linux ── SSH + rsync ────┼──> rsnapshot 快照根目录
Windows/NAS ── SMB 或 NFS ────┘

バックアップサーバーは、ソースデータの読み取り、スナップショットの書き込み、スケジュールされたタスクの実行、およびログの保存を担当します。リモート Linux の場合、rsnapshot は SSH 経由でアクティブにプルされます。 Windows または NAS の場合、通常、共有ディレクトリは最初に Linux にマウントされ、次にローカルディレクトリとしてバックアップされます。

rsnapshotはリアルタイム同期ツールではなく、それだけで遠隔地バックアップを実現するものでもありません。誤削除や誤変更から履歴を復元しやすくなりますが、オフラインコピー、遠隔地コピー、復元訓練の代わりにはなりません。

必要なパッケージをインストールする

Ubuntu または Debian は以下をインストールできます。

1
2


sudo apt update
sudo apt install -y rsnapshot rsync openssh-client cifs-utils nfs-common

各コンポーネントの用途は次のとおりです。

rsnapshot: 同期とスナップショットのローテーションを管理します。
rsync: 変更されたデータをコピーします。
openssh-client: リモート Linux に接続します。
cifs-utils: Windows、Samba、および一般的な NAS の SMB 共有をマウントします。
nfs-common: NAS の NFS エクスポートをマウントします。

コマンドの場所を確認します。

1
2
3


command -v rsnapshot
command -v rsync
command -v ssh

この記事の例では、/usr/bin/rsnapshot、/usr/bin/rsync、および /usr/bin/ssh を使用します。システム出力が異なる場合は、実際のパスが優先される必要があります。

バックアップ先ディスクを確認する

スナップショットのルートディレクトリを作成します。

1
2
3


sudo mkdir -p /mnt/backup/rsnapshot
df -Th /mnt/backup/rsnapshot
findmnt -T /mnt/backup/rsnapshot

スナップショットのルートは、ext4やXFSなど、ハードリンクに対応するLinuxファイルシステム上に配置します。Unixのハードリンクに対応しないFATやexFATには直接配置しないでください。

/mnt/backup が独立したハードディスクである場合は、それが実際にマウントされていることも確認します。そうしないと、ディスクのマウントが失敗した後、タスクがシステムディスク上の同じ名前の空のディレクトリにバックアップを書き込む可能性があります。

最初にハードリンクをテストします。

1
2
3
4


sudo sh -c 'echo test > /mnt/backup/rsnapshot/.link-test'
sudo ln /mnt/backup/rsnapshot/.link-test /mnt/backup/rsnapshot/.link-test-2
ls -li /mnt/backup/rsnapshot/.link-test*
sudo rm /mnt/backup/rsnapshot/.link-test /mnt/backup/rsnapshot/.link-test-2

両方のテストファイルの i ノード番号は同じである必要があります。

設定ファイルの基本構成

通常、主な構成は /etc/rsnapshot.conf です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


config_version	1.2

snapshot_root	/mnt/backup/rsnapshot/

cmd_cp	/usr/bin/cp
cmd_rm	/usr/bin/rm
cmd_rsync	/usr/bin/rsync
cmd_ssh	/usr/bin/ssh
cmd_du	/usr/bin/du

retain	daily	7
retain	weekly	4
retain	monthly	6

タブ文字は、構成項目とパラメータの間に使用する必要があります。コードブロックの表示幅はエディタと異なる場合があり、貼り付け後に実際の文字を確認する必要があり、タブの代わりに通常のスペース文字列を使用しないでください。

この保持ポリシーのセットは以下を表します。

毎日 7 つのスナップショットを保存します。
毎週のスナップショットを 4 つ保存します。
6 つの月次スナップショットを保存します。

デフォルトモードでは、リスト内で最も頻繁に使用される daily が実際の rsync 同期を実行し、毎日のスナップショットをローテーションします。 weekly および monthly は主に、古いスナップショットを下位レベルから上にローテーションします。 sync_first 1 が有効になっている場合、動作が変わり、この記事のタイミングメソッドをコピーできなくなります。

基本コマンド早見表

構成構文を確認してください。

1

sudo rsnapshot configtest

通常の結果には次のものが含まれます。

1

Syntax OK

実際にバックアップせずにコマンドをプレビューします。

1

sudo rsnapshot -t daily

毎日の同期を実行するには:

1

sudo rsnapshot daily

スナップショットの占有率を表示します。

1
2


sudo rsnapshot du
df -h /mnt/backup/rsnapshot

カスタム構成ファイルを使用します。

1
2
3


sudo rsnapshot -c /home/test/rsnapshot.conf configtest
sudo rsnapshot -c /home/test/rsnapshot.conf -t daily
sudo rsnapshot -c /home/test/rsnapshot.conf daily

タスクが通常のユーザー test によって実行される場合、チェック、SSH キー、およびディレクトリのアクセス許可はすべて同じユーザーに属している必要があります。

1
2
3


sudo -u test -H rsnapshot -c /home/test/rsnapshot.conf configtest
sudo -u test -H rsnapshot -c /home/test/rsnapshot.conf -t daily
sudo -u test -H rsnapshot -c /home/test/rsnapshot.conf daily

Linuxディレクトリをバックアップする

ローカルディレクトリをバックアップする

次のディレクトリがバックアップされると仮定します。

1
2
3


/etc/
/home/
/srv/www/

/etc/rsnapshot.conf を追加します。

1
2
3


backup	/etc/	localhost/
backup	/home/	localhost/
backup	/srv/www/	localhost/

グローバル rsync_long_args に --relative が含まれる場合、ソースのディレクトリ階層は保持され、通常、結果は次のようになります。

1
2
3


/mnt/backup/rsnapshot/daily.0/localhost/etc/
/mnt/backup/rsnapshot/daily.0/localhost/home/
/mnt/backup/rsnapshot/daily.0/localhost/srv/www/

最初に実行します:

1
2


sudo rsnapshot configtest
sudo rsnapshot -t daily

本番実行の前に、dry-runの出力でソースと保存先のパスを確認し、意図しない場所へ書き込まれないことを確かめてください。

1
2


sudo rsnapshot daily
sudo find /mnt/backup/rsnapshot/daily.0/localhost -maxdepth 3 -type d | head -50

SSH経由でリモートLinuxをバックアップする

仮想環境は次のとおりです。

1
2
3
4


备份服务器：当前安装 rsnapshot 的 Ubuntu
远程服务器：192.168.1.50
远程用户：backupuser
远程目录：/data/files/

通常、リモートマシンに rsnapshot をインストールする必要はありませんが、リモート環境で SSH サービスが実行され、rsync が実行されている必要があります。

まずリモートマシンで確認します。

1

command -v rsync

rsnapshot が root の cron によって実行されている場合は、root の SSH キーを構成します。

1
2
3


sudo ssh-keygen -t ed25519
sudo ssh-copy-id [email protected]
sudo ssh [email protected]

最後のコマンドは直接ログインを有効にする必要があり、パスワードやホストキーの確認を要求することはできません。

タスクがユーザー test によって実行される場合:

1
2
3


sudo -u test -H ssh-keygen -t ed25519
sudo -u test -H ssh-copy-id [email protected]
sudo -u test -H ssh [email protected]

バックアップポイントを構成します。

`1`	`backup [email protected]:/data/files/ remote-linux/`

次に、順番に検証します。

1
2
3
4


sudo rsnapshot configtest
sudo rsnapshot -t daily
sudo rsnapshot daily
ls -lah /mnt/backup/rsnapshot/daily.0/remote-linux/

--relative が使用されている場合、data/files レイヤーがスナップショットに保持される場合があります。これは重複バックアップではなく、rsync の相対パスの動作です。

スナップショット内のディレクトリ階層を調整する

/data/files/ のコンテンツを remote-linux/ の直下に表示したい場合は、/./ を使用して相対パスの開始点をマークできます。

`1`	`backup [email protected]:/data/files/./ remote-linux/`

バックアップ結果は次のようになります。

1
2


/mnt/backup/rsnapshot/daily.0/remote-linux/项目A/
/mnt/backup/rsnapshot/daily.0/remote-linux/项目B/

パスのセマンティクスは末尾のスラッシュと --relative の影響を受けやすいため、期待だけに頼らないでください。最初に rsnapshot -t daily を実行してから、必要に応じて直接 rsync ドライランを実行する必要があります。

標準以外のSSHポートを使用する

リモート SSH ポートが 2222 の場合、グローバル構成に次のように書き込むことができます。

1
2


cmd_ssh	/usr/bin/ssh
ssh_args	-p 2222

まず手動でテストします。

1

ssh -p 2222 [email protected]

1台のサーバーだけが標準以外のポートを使う場合は、~/.ssh/config を使用することを推奨します。これにより、グローバルな ssh_args が他のバックアップポイントへ影響するのを防げます。

1
2
3
4
5


Host server50-backup
    HostName 192.168.1.50
    User backupuser
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

対応する構成は次のとおりです。

1

backup	server50-backup:/data/files/	remote-linux/

複数のLinuxホストをバックアップする

ソースごとに個別のターゲット名を使用します。

1
2
3


backup	[email protected]:/data/files/	server50-files/
backup	[email protected]:/home/	server50-home/
backup	[email protected]:/srv/www/	server60-www/

これにより、復元時にデータの取得元をすぐ確認でき、異なるソースが同じディレクトリへ書き込まれることも防げます。

ルート直下のベア.gitリポジトリだけをバックアップする

NAS 上のディレクトリが次であると仮定します。

1
2
3
4
5
6
7


/volume1/homes/git/
├── vuepress_sites.git/
├── zcb.git/
├── zyys_book_v2.git/
├── website/
├── test/
└── README.txt

ルートディレクトリ内の .git で終わるディレクトリとその内容全体のみを保持します。

`1`	`backup [email protected]:/volume1/homes/git/./ git/ +rsync_long_args=--rsync-path=/usr/bin/rsync --include=/.git/** --exclude=*`

最初の 3 つの区切り文字にはタブを使用し、4 列目の rsync パラメータには通常のスペースを使用します。 +rsync_long_args= は、グローバルパラメータ全体を置き換えるのではなく、グローバルパラメータに追加することを意味します。

フィルタルールの順序を逆にすることはできません。 rsync は、最初に一致したルールに基づいてオブジェクトを含めるかどうかを決定するため、--include=/*.git/*** は --exclude=* の前になければなりません。

まず rsync を直接テストします。

1
2
3
4
5
6
7


/usr/bin/rsync -avhn \
  --relative \
  --rsync-path=/usr/bin/rsync \
  '--include=/*.git/***' \
  '--exclude=*' \
  [email protected]:/volume1/homes/git/./ \
  /tmp/git-backup-test/

.git ディレクトリとその内容が出力に表示されます。 website/、test/、または README.txt は表示されません。

後でルールが「すべてバックアップ」から「.git のみバックアップ」に変更された場合、古いスナップショットの他のコンテンツは履歴スナップショットから消えません。新しい daily.0 で除外されたオブジェクトをクリーンアップするには、--delete-excluded の影響を理解し、テストする必要があります。フィルタリングルールに一致しなくなったターゲット内のデータは削除される可能性があり、ドライラン検証なしでは直接有効にすることはできません。

Windows共有、NAS、Sambaディレクトリをバックアップする

SMB、NFS、SSHのどれを使うか決める

ソースの機能に応じて選択できます。

Windows ファイル共有: 通常は SMB/CIFS を使用します。
Samba サーバー: 通常は SMB/CIFS を使用するか、SSH + rsync 経由で直接使用します。
Synology や QNAP などの NAS: 制御された環境で SMB/CIFS、NFS、または SSH + rsync を使用できます。
OpenSSH と WSL rsync が構成されたリモート Windows: SSH 経由でプルすることは可能ですが、展開とパスの処理がより複雑になります。

一般的なWindows共有では、まずLinuxへ読み取り専用でマウントし、そのマウントポイントをrsnapshotでバックアップする方法が管理しやすいでしょう。

SMB認証情報ファイルを作成する

パスワードを /etc/fstab またはコマンド履歴に直接書き込まないでください。 root が読み取り可能な認証情報ファイルを作成します。

1
2


sudo install -m 600 /dev/null /root/.smb-backup-credentials
sudo nano /root/.smb-backup-credentials

内容は次のとおりです。

1
2
3


username=backupuser
password=替换为真实密码
domain=WORKGROUP

ドメインを使用しない場合は、domain 行を削除します。権限を再度確認します。

1

sudo stat -c '%a %U:%G %n' /root/.smb-backup-credentials

予期される権限は 600 root:root です。

WindowsまたはSamba共有を手動でマウントする

共有アドレスが //192.168.8.100/files であると仮定します。

1
2
3


sudo mkdir -p /mnt/source/windows-files
sudo mount -t cifs //192.168.8.100/files /mnt/source/windows-files \
  -o ro,credentials=/root/.smb-backup-credentials,vers=3.0

マウントを確認して以下を読んでください。

1
2


findmnt -T /mnt/source/windows-files
sudo ls -lah /mnt/source/windows-files | head

rsnapshot 構成を書き込む前に、まず共有が安定して読み取れることを確認します。手動マウントが失敗した場合、rsnapshot は認証、プロトコル、またはネットワークの問題を解決できません。

起動時の自動マウントを設定する

/etc/fstab に行を追加します。

1

//192.168.8.100/files /mnt/source/windows-files cifs ro,credentials=/root/.smb-backup-credentials,vers=3.0,_netdev,nofail 0 0

テスト中は直接再起動しないでください。

1
2
3


sudo umount /mnt/source/windows-files
sudo mount -a
findmnt -T /mnt/source/windows-files

その中には:

ro: バックアップマシンがソースデータを誤って変更するリスクを軽減するために、読み取り専用モードでマウントします。
credentials=: 独立したファイルからアカウントのパスワードを読み取ります。
vers=3.0: SMB 3.0 を明示的に試します。
_netdev: これをネットワーク依存マウントとしてマークします。
nofail: マウントが失敗した場合でも、システムの起動の継続は妨げられません。

nofail は起動動作にのみ影響し、バックアップタスクがマウントの失敗を無視する必要があるという意味ではありません。スケジュールされたバックアップの前に、マウントステータスを確認する必要があります。

SMBマウントポイントをrsnapshotに追加する

構成:

1

backup	/mnt/source/windows-files/	windows-files/

次に、次のことを確認します。

1
2
3
4


sudo rsnapshot configtest
sudo rsnapshot -t daily
sudo rsnapshot daily
ls -lah /mnt/backup/rsnapshot/daily.0/windows-files/

ディレクトリの存在だけで判断してはいけません。SMBマウントが切断されても、ローカルのマウントポイント自体は残り、中身だけが空になる場合があります。

NASのNFSエクスポートをマウントする

NAS が 192.168.8.200:/volume1/files をエクスポートすると仮定します。

1
2
3
4


sudo mkdir -p /mnt/source/nas-files
sudo mount -t nfs -o ro 192.168.8.200:/volume1/files /mnt/source/nas-files
findmnt -T /mnt/source/nas-files
sudo ls -lah /mnt/source/nas-files | head

/etc/fstab の例に対応します。

1

192.168.8.200:/volume1/files /mnt/source/nas-files nfs ro,_netdev,nofail 0 0

RSスナップショットの設定:

1

backup	/mnt/source/nas-files/	nas-files/

NFS には、SMB とは異なるユーザーマッピングと権限モデルがあります。マウントできることは、すべてのファイルを読み取ることができることを意味するわけではありません。ディレクトリを再帰的にチェックするには、実際に rsnapshot を実行するアカウントを使用する必要があります。

共有切断時に空のスナップショットを作らない

最も簡単なcronの安全策は、必要なマウントポイントを実行前にすべて確認することです。

1
2
3


/usr/bin/mountpoint -q /mnt/source/windows-files && \
/usr/bin/mountpoint -q /mnt/source/nas-files && \
/usr/bin/rsnapshot daily

いずれかのマウントポイントが存在しなければ、rsnapshotは実行されません。

共有上にのみ存在するセンチネルファイルを確認することもできます。

1
2
3


test -r /mnt/source/windows-files/.backup-source-ok && \
test -r /mnt/source/nas-files/.backup-source-ok && \
/usr/bin/rsnapshot daily

確認用ファイルを使えば、「マウントポイントは存在するが、別の共有がマウントされている」といった問題も検出できます。このファイルはソース側の管理者が作成し、バックアップアカウントから読み取れるようにします。

定期バックアップとスナップショットのローテーション

推奨するcronの実行順序

構成が次のようになっていると仮定します。

1
2
3


retain	daily	7
retain	weekly	4
retain	monthly	6

編集可能なルートの crontab:

1

sudo crontab -e

書きます:

1
2
3
4
5
6
7
8


# 每月 1 日 03:00
0 3 1 * * /usr/bin/rsnapshot monthly >> /var/log/rsnapshot.log 2>&1

# 每周日 03:30
30 3 * * 0 /usr/bin/rsnapshot weekly >> /var/log/rsnapshot.log 2>&1

# 每天 04:00
0 4 * * * /usr/bin/rsnapshot daily >> /var/log/rsnapshot.log 2>&1

実際に crontab に書き込む場合は、アスタリスクの前にバックスラッシュを追加しないでください。

高レベルのローテーションは、毎日の同期の前にスケジュールされるため、monthly および weekly は、間もなく下位レベルから段階的に削除されるスナップショットを最初に受信します。毎月 1 日が日曜日の場合、実行順序は monthly、weekly、daily になります。

すべての保持レベルで同じロックを使用する

ディスクが遅い場合、ファイル数が多い場合、またはネットワークが不安定な場合は、毎週のスケジュールされた時間まで日次が実行されることがあります。重複を防ぐには、flock を使用します。

1
2
3


0 3 1 * * /usr/bin/flock -n /run/lock/rsnapshot.lock /usr/bin/rsnapshot monthly >> /var/log/rsnapshot.log 2>&1
30 3 * * 0 /usr/bin/flock -n /run/lock/rsnapshot.lock /usr/bin/rsnapshot weekly >> /var/log/rsnapshot.log 2>&1
0 4 * * * /usr/bin/flock -n /run/lock/rsnapshot.lock /usr/bin/rsnapshot daily >> /var/log/rsnapshot.log 2>&1

-n は、ロックを取得できない場合に直ちに終了することを意味します。これにより 2 つの rsnapshot が同時に開始されることはありませんが、長期的にロックの競合によってタスクがスキップされるのを防ぐために、ログ監視と組み合わせる必要があります。

SMB および NFS マウントを毎日前にチェックする必要がある場合は、root が所有し、通常のユーザーが変更できないラッパースクリプトを作成し、cron によって呼び出すことをお勧めします。 crontab に長い複合コマンドを積み重ねないでください。

定期実行を有効にする前の検証

順番に完了してください:

1
2
3
4
5


sudo rsnapshot configtest
sudo rsnapshot -t daily
sudo rsnapshot daily
sudo find /mnt/backup/rsnapshot/daily.0 -maxdepth 3 -type d | head -100
sudo tail -100 /var/log/rsnapshot.log

また、cron によって使用される root が対話なしで各リモート Linux に接続できることを確認してください。

1
2


sudo ssh [email protected] true
sudo ssh [email protected] true

コマンドは成功を直接返す必要があり、パスワードや最初の接続確認を待つ必要はありません。

ハードリンクが機能していることを確認する

2 つの連続したスナップショットを取得した後、変更されていないファイルを選択します。

1
2


ls -li /mnt/backup/rsnapshot/daily.0/localhost/etc/hosts
ls -li /mnt/backup/rsnapshot/daily.1/localhost/etc/hosts

inodeが同じでリンク数が1より大きければ、2つのスナップショットが同じファイルデータを共有しています。

実際の増加量を見積もる際に、du -sh daily.0 daily.1の結果を単純に合計しないでください。ハードリンクのため、ディレクトリ別の集計では各スナップショットが全容量を占めるように見えることがあります。

ファイルを復元する

復元する前に履歴スナップショットを参照します。

1
2


ls -lah /mnt/backup/rsnapshot/daily.1/remote-linux/
ls -lah /mnt/backup/rsnapshot/weekly.0/windows-files/

ファイルを一時ディレクトリに復元します。

1
2
3


mkdir -p /tmp/rsnapshot-restore
cp -a /mnt/backup/rsnapshot/daily.1/remote-linux/data/files/report.pdf \
  /tmp/rsnapshot-restore/

本番ディレクトリを上書きする前に、まず復元したファイルを確認してください。リモートサーバーへ戻す場合は、最初に一時ディレクトリへrsyncし、システム管理者またはデータ所有者に権限、所有者、内容を確認してもらうことを推奨します。

よくある問題とトラブルシューティング

configtestでエラーまたはフィールド数の不一致が表示される

最も一般的な原因は、Tabがスペースに置き換わっていることです。不可視文字を表示します。

1

sed -n '1,120l' /etc/rsnapshot.conf

Tabは通常、\t と表示されます。修正後、もう一度実行します。

1

sudo rsnapshot configtest

また、コマンドパスが実際に存在すること、および snapshot_root が読み取りおよび書き込み可能であることも確認してください。

Permission denied (publickey)

これは、タスクを実行しているローカルアカウントが SSH キー経由でログインできないことを意味します。同じアカウントでテストします。

1

sudo -u test -H ssh -vv [email protected] true

次の項目を確認してください。

公開キーがリモートアカウントの ~/.ssh/authorized_keys に追加されるかどうか。
ローカル秘密キーが rsnapshot を実行しているアカウントに属しているかどうか。
リモートの .ssh および authorized_keys の権限が広すぎるかどうか。
cron が実際に test ではなく root として実行されるかどうか。
ホストキーが同じアカウントによって確認されているかどうか。

SSH接続はできるが、rsyncでcommand not foundになる

リモート側のパスを確認します。

1

ssh [email protected] 'command -v rsync'

rsyncが標準以外の場所にある場合は、該当するバックアップポイントへオプションを追加します。

1

+rsync_long_args=--rsync-path=/usr/local/bin/rsync

パスを推測するのではなく、最初にリモートマシン上で実際に確認してください。

リモートディレクトリを読み取れない

最初にリモートバックアップアカウントをテストします。

1
2


sudo -u test -H ssh [email protected] \
  'ls -lah /data/files/'

次に、rsnapshot をバイパスして、rsync を直接テストします。

1
2
3


sudo -u test -H rsync -avhn \
  [email protected]:/data/files/ \
  /tmp/remote-backup-test/

それでも Permission denied が発生する場合、原因はrsnapshotではなく、リモートアカウントのディレクトリ走査権限またはファイル読み取り権限です。リモート側で確認します。

1
2


namei -l /data/files/
sudo -u backupuser find /data/files/ -maxdepth 2 -type f -readable | head

専用の読み取り専用アカウント、グループ権限、ACLによる許可を優先します。安易にソースディレクトリ全体を全ユーザーが読み書きできる設定へ変更しないでください。

SMBマウントでPermission deniedが表示される

まずカーネルログとマウントエラーを確認します。

1
2
3


sudo mount -v -t cifs //192.168.8.100/files /mnt/source/windows-files \
  -o ro,credentials=/root/.smb-backup-credentials,vers=3.0
sudo dmesg | tail -50

共有名、ユーザー名、ドメイン、認証情報ファイルのアクセス許可、および NAS がアカウントのアクセスを許可しているかどうかを確認してください。サーバーが本当に古い場合にのみ、他の vers= を試してください。デフォルトのソリューションとして古いプロトコルへのダウングレードを考慮しないでください。

rsnapshotは成功するが、WindowsまたはNASのスナップショットが空になる

今すぐソースマウントを確認します。

1
2
3


findmnt -T /mnt/source/windows-files
mountpoint /mnt/source/windows-files
ls -lah /mnt/source/windows-files | head

共有がマウントされていない場合は、後続のローテーションを止め、マウントを復旧してからdailyを実行します。空のマウントポイントに対して実行を続けると、新しいスナップショットにも空のソースが記録されます。

rsnapshot -tは正しいが、本番実行に失敗する

-t は主に実行されるコマンドを表示し、転送中の権限、容量、ネットワークの安定性、およびすべてのファイル名を完全に検証するわけではありません。予行演習は、成功を保証するものではなく、最初のチェックとして考えてください。

ログを確認します。

1
2


sudo tail -200 /var/log/rsnapshot.log
sudo journalctl --since today | grep -E 'rsnapshot|rsync|cifs|nfs'

ログ内の rsync コマンドをコピーし、個別に実行して、ネットワーク、権限、ファイル名、またはディスクの問題であるかどうかを確認します。

ディスク使用量が異常に増える

まず、「多数のファイル変更」と「ハードリンク障害」を区別します。

1
2
3
4


df -h /mnt/backup/rsnapshot
df -i /mnt/backup/rsnapshot
sudo du -xsh /mnt/backup/rsnapshot
sudo rsnapshot du

小さなファイルが多数あると、最初に i ノードが枯渇します。データベースファイル、仮想マシンイメージ、および変更を続ける大きなファイルは、たとえ一部が変更されただけであっても、新しいスナップショットの新しい完全なファイル領域を占有する可能性があります。

スナップショットのルートがハードリンク非対応のファイルシステムへ移動された場合や、スナップショットが複数のファイルシステムにまたがる場合も、容量を再利用できません。次のコマンドで再確認します。

1
2
3


findmnt -T /mnt/backup/rsnapshot
ls -li /mnt/backup/rsnapshot/daily.0/某文件
ls -li /mnt/backup/rsnapshot/daily.1/某文件

cronが実行されない

crontab の内容を確認します。

1
2
3


sudo crontab -l
systemctl status cron --no-pager
sudo journalctl -u cron --since today

cronの環境変数は対話型シェルより少ないため、ジョブではコマンドの絶対パスを使います。シェルで一時的に設定したPATH、SSHエージェント、手動マウントの状態には依存しないでください。

手動では成功してcronでは失敗する場合、実行アカウント、HOME、SSHキー、known_hosts、および両方の環境から見えるマウントを比較します。

ジョブが重複する、または長時間終了しない

進行状況を確認します。

1
2


pgrep -af 'rsnapshot|rsync'
sudo lsof /run/lock/rsnapshot.lock

処理段階を知らずにロックファイルを直接削除しないでください。まずログとプロセスのステータスをチェックして、アクティブな rsnapshot がないことを確認してから、残りのロックを処理します。

予定した時間枠を頻繁に超える場合は、実行時刻の調整、走査範囲の縮小、低速なネットワークの改善、共通のflockロックの導入を検討します。同じスナップショットルートを複数ジョブから同時に読み書きさせないでください。

ソースから削除したファイルが古いスナップショットに残る理由

これは想定どおりの動作です。新しいdaily.0にはソース側の削除が反映されますが、古いdaily.1とweekly.0は履歴であり、設定した保持数を超えるまで削除されません。

古いスナップショットへ入り、ファイルを1つずつ削除して「状態を同期」しないでください。履歴保持の目的が失われ、ハードリンクで共有されているデータへの参照を誤って削除するおそれがあります。

バックアップから確実に復元できるか確認する

少なくとも月に1回は、サンプルデータの復元テストを実施します。

毎日、毎週、または毎月のスナップショットを選択します。
いくつかの異なるタイプのファイルを別々の一時ディレクトリにコピーします。
ファイルサイズとチェックサムを確認し、実際に開けることを確かめます。
ベア Git リポジトリで整合性チェックを実行します。
回復時間と見つかった問題を文書化します。

Git ベアウェアハウスはランダムにチェックできます。

1

git --git-dir=/tmp/rsnapshot-restore/project.git fsck --full

スケジュールされたタスクの成功ログだけでは十分ではありません。真の合格基準は、指定された履歴時点から正しく使用可能なデータを復元できるかどうかです。

実用的な統合設定例

次の例では、ローカルマシン、リモート Linux、Git ベアリポジトリ、Windows 共有、および NAS NFS を同時にバックアップします。コードブロック内の列がタブであることを確認してください。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


config_version	1.2

snapshot_root	/mnt/backup/rsnapshot/

cmd_cp	/usr/bin/cp
cmd_rm	/usr/bin/rm
cmd_rsync	/usr/bin/rsync
cmd_ssh	/usr/bin/ssh
cmd_du	/usr/bin/du

rsync_long_args	--delete --numeric-ids --relative

retain	daily	7
retain	weekly	4
retain	monthly	6

backup	/etc/	localhost/
backup	/home/	localhost/
backup	[email protected]:/data/files/	server50-files/
backup	[email protected]:/volume1/homes/git/./	git/	+rsync_long_args=--rsync-path=/usr/bin/rsync --include=/*.git/*** --exclude=*
backup	/mnt/source/windows-files/	windows-files/
backup	/mnt/source/nas-files/	nas-files/

オンライン注文は次のように修正する必要があります。

1
2
3
4


sudo rsnapshot configtest
sudo rsnapshot -t daily
sudo rsnapshot daily
sudo find /mnt/backup/rsnapshot/daily.0 -maxdepth 3 -type d | head -100

項目ごとに確認します。

スナップショットのルートディレクトリは正しいバックアップディスク上にあります。
SMB と NFS は実際のマウントを共有し、読み取り可能です。
SSH 接続には対話は必要ありません。
予行演習には予期しないソースやターゲットはありません。
.git フィルターの結果には、予期されるディレクトリのみが含まれます。
すべてのキーファイルは daily.0 にあります。
2回目のスナップショットで、変更のないファイルがハードリンクになっていること。
回復テストではファイルを正常に開くことができました。

最後にcronを有効にします。こうすることで、問題が発生したときに、すべてのエラーを rsnapshot に起因させることなく、構成構文、SSH、共有マウント、ソース権限、ディスク容量、タイミング環境を明確に区別できます。