TrueNAS の ZFS 同士で Snapshot を利用して同期をとる Replication (レプリケーション)の設定手順です。
Snapshot を利用するので、高速で転送するデータ量が節約できるはずです。
元のデータセットの Snapshot が必要なので、まずは Periodic Snapshot Tasks を設定して一度は実行を完了しておく必要があります。
Rsync の内容を整理するので力尽きたので、ひとまず途中状態です。
(内容の整理もまだ途中なので、随時追記・設定内容の変更・差し替え・順番の変更があり得ます)
TrueNAS Scale 25.10.1 同士の Replication 設定手順
Replication Tasks を参考にしていますが、そのまま翻訳ではありません。
この手順は TrueNAS Scale 25.10.1 同士で Replication を行うための設定手順をまとめたものです。
はじめに:Replication と Rsync の違い
TrueNAS 同士でバックアップを行う際、「転送元のデータを削除したとき、転送先のデータをどうしたいか」で手段が決まります。
1. Replication (推奨:ブロックレベル同期)
- 動作の仕組み: 変更部分のスナップショットを転送して同期します。ファイルの中身を1つずつ調べるのではなく、ZFSが記録している「変更されたブロック(データの断片)」だけを抽出して転送するため、非常に高速で効率的です。
- 削除の扱い: 転送元でファイルを削除すると、次回の転送時に転送先からも削除されます(完全ミラーリング)。
- 目的: システム全体の完全なバックアップ、ランサムウェア対策、Disaster Recovery(災害復旧)。権限や属性も完全に維持されます。
2. Rsync (ファイルレベル同期)
- 動作の仕組み: ファイルを確認して新しいファイルを転送します。送信側と受信側のファイルリストを比較し、日付やサイズが異なる「新しいファイル」を見つけて転送します。ファイル数が多いと、比較(スキャン)に時間がかかります。
- 削除の扱い: Delete 設定により、転送元で削除されたファイルも、転送先には残す(増分コピー・蓄積)ことができます。
- 目的: 誤って消したファイルの救出用アーカイブ作成や、ZFSではないサーバーへのファイル転送。データセット内の一部のフォルダのみとかも対応可能。
本手順書は、1. の「Replication(完全ミラーリング)」を行うための設定手順です。
前提環境
- 送信元データセット:
/mnt/tank/data - 送信元・宛先: 両方とも TrueNAS 25.10.1
- スケジュール: 毎日1回、1:00にスナップショットを作成、2:00 にレプリケーション実行 (頻度、時刻を変更する場合は、定期スナップショットのスケジュールや寿命の設定にも考慮が必要)
- タスクを実行するユーザー:
replication(任意ですが、replication 専用で作成を推奨)
全体の流れ
- 【送信側】 スナップショットタスク、ホームディレクトリ、ユーザー(SMB除外・仮パスワード)の作成
- 【受信側】 ホームディレクトリ、保存先データセット、ユーザー(SMB除外・仮パスワード)の作成、SSHサービスの有効化
- 【連携】 SSH 鍵の自動交換と、双方のパスワード認証無効化
- 【送信側】 レプリケーションタスクの作成と実行
1. 【送信側】環境準備
まず、送信側で「送るデータ」と「送るユーザー」を準備します。送信したいデータセット(例では /mnt/tank/data)自体はすでに存在している想定です。
1-1. Periodic Snapshot Task の作成
Replication は「データそのもの」ではなく「ZFS スナップショット」を転送する仕組みであるため、まずその元データとなるスナップショットを取得する設定をします。
すでに「Windowsのシャドウコピー(以前のバージョンの復元)用」などで定期スナップショットを設定している場合でも、Replication 用に新しいタスクを追加して構いません。
- スケジュールの重複: もし既存のタスクと時間が重なっても、ZFS が効率的に処理するため問題ありません(二重にデータが増えるわけではありません)。
- 保存期間の管理: 既存のタスクとは別に「Lifetime(保持期間)」を設定できるため、「普段のスナップショットは2週間、Replication用は1ヶ月」のように目的に合わせて管理できます。
- 場所: Data Protection > Periodic Snapshot Tasks
- 操作: Add
- 設定:
- Dataset:
/mnt/tank/data(例:転送したいデータセット) - Exclude: 空欄(特定のサブデータセットを除外したい場合は指定する)
- ■ Recursive: チェック(サブデータセットも含めない場合はチェックしなくてもいい)
- Snapshot Lifetime:
1 MONTH(任意の保持期間でいいが Replication の際に欠落がないように余裕をとる) - Naming Schema:
backup-%Y-%m-%d_%H-%M(既存のスナップショットがある場合は名前を変更することを推奨) - Schedule:
Daily 01:00(レプリケーション実行時刻より前、実行時までに完了するように設定。Create で Presets を Daily にして、 Hour を 0→1 に変更する。右上のSchedule Previewで確認して Done。 Custom At 01:00 AM となる) - ■ Allow Taking Empty Snapshots (レプリケーション用途のスナップショットの場合は、スナップショット切れを起こさないためチェック推奨)
- ■ Enabled: チェック(チェックしないと実行されない)
- Dataset:
- 保存: Save
1-2. ホームディレクトリ用データセットの作成
Replication ユーザー用のホームディレクトリを作成します。間違って操作しないように他の共有用データセットとは区別して設定します。
- 場所: Storage > Datasets
- 操作: Add Dataset
- 設定:
- Name:
home - Dataset Preset: Generic
- Name:
- 結果:
/mnt/tank/homeが作成されます。その中にユーザー毎にディレクトリが作成されます。
1-3. Replication ユーザーの作成(SMB除外・仮パスワード)
管理者権限を使わず、安全に転送するための専用ユーザーを作ります。ファイル共有には使わないため、SMB認証は無効にします。
- 場所: Credentials > Users
- 操作: Add
- 設定:
- Username:
replication(推奨) - □ SMB Access Unchecked (無効) ※重要:SMBアクセスを除外
- ■ SSH Access Checked (有効) ※重要:SSHアクセスを有効、同時にShell Accessも有効になる
- Password: (任意の仮パスワード) ※一時的に設定
- Confirm Password: (同上)
- ■ Allow SSH Login with Password (not recommended): Checked (有効) ※一時的に有効化
- Home Directory:
New directory under /mnt/tank/home(鉛筆マークをクリックして ■ Create Home Directory 、 /mnt/tank/home を選択) - Shell:
/usr/bin/zsh(デフォルトのままでOK) - Sudo commands: ■ Allow all sudo commands (有効) (鉛筆マークをクリックして ■ Allow all sudo commands をチェック)※zfs send/receive 実行に必須
- Username:
- 保存: Save
2. 【受信側】環境準備
受信側も送信側と同じ流れで、「入れ物(データセット)」を作ってから「ユーザー」を作ります。
2-1. 保存先データセット (Destination Dataset) の作成
Replication Wizard では新規データセットを作成できないため、受け皿を事前に作ります。
- 場所: Storage > Datasets
- 操作: Add Dataset
- 設定:
- Name:
data(例:/mnt/tank/data)
- Name:
※ 送信元と同じ名前(例:data)にするのが一般的で管理しやすいです。別のTrueNAS(別のプール)であれば名前が重複しても問題ありません。
2-2. ホームディレクトリ用データセットの作成
- 場所: Storage > Datasets
- 操作: Add Dataset
- 設定:
- Name:
home - Dataset Preset: Generic
- Name:
- 結果:
/mnt/tank/homeが作成されます。その中にユーザー毎にディレクトリが作成されます。
2-3. Replication ユーザーの作成(SMB除外・仮パスワード)
- 場所: Credentials > Users
- 操作: Add
- 設定:
- Username:
replication(推奨) - □ SMB Access Unchecked (無効) ※重要:SMBアクセスを除外
- ■ SSH Access Checked (有効) ※重要:SSHアクセスを有効、同時にShell Accessも有効になる
- Password: (任意の仮パスワード) ※一時的に設定
- Confirm Password: (同上)
- ■ Allow SSH Login with Password (not recommended): Checked (有効) ※一時的に有効化
- Home Directory:
New directory under /mnt/tank/home(鉛筆マークをクリックして ■ Create Home Directory 、 /mnt/tank/home を選択) - Shell:
/usr/bin/zsh(デフォルトのままでOK) - Sudo commands: ■ Allow all sudo commands (有効) (鉛筆マークをクリックして ■ Allow all sudo commands をチェック)※zfs send/receive 実行に必須
- Username:
- 保存: Save
2-4. SSH サービスの有効化
- 場所: System > Services
- 操作: SSH の Start Automatically をONにし、Status の三角をクリック。RUNNING になります。
3. 【連携】SSH 接続設定とセキュリティ強化
鍵交換を自動で行い、その後、送信元・受信側の両方で仮パスワードを無効化してセキュアな状態にします。
3-1. 【送信側】SSH Connection の作成(自動鍵交換)
TrueNAS の "Semi-Automatic" モードを使うことで、鍵の生成と受信側への登録を同時に行います。
- 場所: Credentials > Backup Credentials > SSH Connections
- 操作: Add
- 設定:
- Name:
replication-to-backup(任意の名前) - Setup Method: Semi-Automatic (TrueNAS only)
- TrueNAS URL:
http://(受信側IPアドレス) - Admin Username:
truenas_admin(受信側TrueNASの管理者ユーザー) - Admin Password: (受信側TrueNASの管理者ユーザーのパスワード)
- Username:
replication(転送用に作成したユーザー) - Private Key: Generate New
- Name:
- 保存: Save
3-2. 【受信側】パスワード認証の無効化
鍵の登録が完了したため、受信側でのSSHパスワードログイン及びパスワードを無効化します。
- 場所: Credentials > Users
- 操作:
replicationユーザーの Edit - 設定変更:
- ■ Disable Password: Checked (有効) ※パスワード自体を無効化
- □ Allow SSH Login with Password (not recommended): も同時にUnchecked (無効) に変更
- 保存: Save
3-3. 【送信側】パスワード認証の無効化
送信元のユーザーも、外部からの不正侵入を防ぐためにSSHパスワードログイン及びパスワードを無効化します。
- 場所: Credentials > Users
- 操作:
replicationユーザーの Edit - 設定変更:
- ■ Disable Password: Checked (有効) ※パスワード自体を無効化
- □ Allow SSH Login with Password (not recommended): も同時にUnchecked (無効) に変更
- 保存: Save
4. 【送信側】タスク作成と実行
最後にレプリケーションタスクを設定し、動作を確認します。
4-1. Replication Task の作成
- 場所: Data Protection > Replication Tasks
- 操作: Add (Wizardが起動します)
- Step 1: What and Where
- Source Location: On This System
- Source Dataset:
/mnt/tank/data - Destination Location: On a Different System
- SSH Connection:
replication-to-backup(3. で設定したもの) - Destination Dataset:
/mnt/tank/data(送信元と同じ名前を指定)
- Step 2: When
- Replication Schedule: Run On a Schedule
- Schedule:
Daily 02:00(スナップショット作成より後の時間) - Snapshot Retention Lifetime: Source と整合
- 保存: Save
4-2. 初回実行と確認
初期設定ミスを早期発見するため、手動で一度実行します。
注意 対象のデータセットのスナップショットがないと実行に失敗します。作ったばかりのデータセットの場合、定期スナップショットタスクのスケジュールを調整するなどしてスナップショットを1つは作成する必要があります。
- 操作: 作成したタスクのリストにある再生ボタン(Run Now)をクリック。
- 確認:
- State が
SUCCESSになること。 - 受信側の
/mnt/tank/data内にデータ(スナップショット)が転送されていること。
- State が
5. 受信側 TrueNAS での定期スナップショットタスクの設定は不要
受信側のデータセットに対して、定期スナップショットタスク(Periodic Snapshot Task)を設定する必要はありません。 むしろ、設定しないのが一般的です。
理由:送信側の Replication Task が管理するため
Replication(レプリケーション)は、送信元で作成されたスナップショットを「そのまま」送信先にコピーする仕組みです。
作成: スナップショットは送信元の定期タスクで作られます 。
転送: Replication Task がそれを送信先にコピーします 。
削除(寿命管理): 送信先の古いスナップショットの削除は、Replication Task の設定項目である Snapshot Retention Lifetime(スナップショットの保持期間) によって制御されます 。
Same as Source(ソースと整合)にした場合: 送信元のスナップショットが期限切れで消去されると、次回のレプリケーション実行時に、送信先にある同じスナップショットも削除されます。つまり、常に送信元と同じスナップショット構成が維持されます 。
Custom(カスタム)にした場合: 「送信元は7日で消すが、送信先(バックアップ)は1年残したい」といった場合はここで設定します。この場合も、Replication Task が期限を管理して削除を行うため、別途削除を目的としたスナップショットタスクを作る必要はありません。
受信側データセットの定期スナップショットタスクの設定は 「何もしない(タスクを作らない)」 が正解です。 受信側はあくまで「送信元の鏡(ミラー)」として、Replication Task に管理を任せてください。
補足:もしもの時のリストア(復元)と事業継続について
バックアップは「戻せて」初めて意味を持ちます。TrueNAS の Replication でバックアップしたデータを利用する主な方法は、状況に合わせて以下の通りです。
A. 間違って消したファイルだけを取り出したい場合
送信先(バックアップ機)のデータセットは、そのまま SMB (Windows共有) で共有設定することで、中身を見ることができます。ただし、Replication されたデータセットは通常 「読み取り専用 (Read-only)」 に設定されています。
- 受信側の TrueNAS で、バックアップデータセット (
/mnt/tank/data) に対して SMB 共有を作成する。 - PC からアクセスし、必要なファイルをコピーして手元に戻す。
B. 送信元のデータが全損し、丸ごと復旧したい場合
送信元のドライブ故障などでデータを喪失した場合の対応は、復旧の緊急度によって2つのアプローチ(本復旧と一時利用)があります。
B-1. データを書き戻す(逆方向レプリケーション)
基本となる復旧方法です。送信元(復旧先)の TrueNAS を修理・再構築した後、受信側(バックアップ機)から 送信元に向けて、Replication Task を作成して実行します。これにより、バックアップ機のデータをそっくりそのままメイン機に書き戻すことができます。
B-2. バックアップ機で業務を即座に再開する(フェイルオーバー)
【Bの副案:代替運用】
データの書き戻しには時間がかかるため、その間の業務停止を避けるための戦略です。メイン機の修理を待たずに、受信側(バックアップ機)を一時的にメイン機の代わりとして利用します。
- レプリケーションの停止: 受信側で、定期的に実行されているレプリケーションタスクを一時停止(または無効化)します。
- 読み取り専用の解除: 受信側のデータセット設定で「Read-only」を解除し、書き込み可能にします。
- 共有の開始: 受信側で SMB 共有などを有効化し、ユーザーに接続先を案内(またはIPアドレスを変更)して業務を再開します。
※注意: 後日メイン機が直った際は、メイン機をバックアップとして設定するか、バックアップ機で増えた分のデータをメイン機に戻す作業(フェイルバック)が必要になります。
重要:復元のリハーサル(リストア訓練)について
環境が許すのであれば、実際に障害が起きる前に「復元のリハーサル」を行っておくことを強く推奨します。
- バックアップデータが正しく開けるか?
- 手順通りに操作してエラーが出ないか?
- 代替運用への切り替えにどれくらい時間がかかるか?
いざという時は心理的にも焦りが生じます。避難訓練と同様に、平常時に一度でも手順を通しておくことで、実際のトラブル時にスムーズに対応できるようになります。
重要:手順書の保管場所について(「鍵」の閉じ込め防止)
作成した復旧手順書やリハーサルの記録は、必ず対象の TrueNAS 以外の場所に保管してください。
- 理由: TrueNAS 自体が故障してアクセスできなくなった際、その中に保存されている手順書も読めなくなってしまいます(金庫の中に鍵を入れてロックするのと同じ状態です)。
- 推奨される保管場所:
- クラウドストレージ(Google Drive, OneDrive など)
- 管理者のローカル PC
- 紙に印刷したもの(停電やネットワーク障害時でも参照できるため、物理的なプリントアウトが最も確実です)
補足:送信先データの「読み取り専用」属性について
Replication で転送された受信側のデータセットは、データの整合性を守るために自動的に 「読み取り専用 (Read-only: On)」 に設定されるのが一般的です。
- 現象: 受信側の TrueNAS で、バックアップデータ内のファイルを削除したり編集しようとしても「許可がありません」と拒否されます。
- 理由: 勝手に変更されると、次回の Replication 時に送信元との差分計算が狂ってしまうためです。
- 対策: バックアップデータは「見るもの(コピー元)」として扱い、編集はしないように運用します(B-2の代替運用時を除く)。
補足:初回の転送時間について
初回実行時は「全てのデータ」を転送するため、データ量(TB単位など)によっては非常に時間がかかります。2回目以降は「変更された差分だけ」が転送されるため、数分〜数十分で終わるようになります。初回のタスクが完了するまでは、ネットワークを切断しないように注意してください。
万が一中断しても大丈夫です:
転送中にネットワーク切断や再起動などで処理が止まってしまった場合でも、ZFS のレプリケーションは「リジューム(再開)機能」に対応しています。次回のタスク実行時(または手動で Run Now を押した時)に、最初からではなく「中断した箇所」から転送を再開してくれるため、巨大なデータでも安心して転送できます。