「送信機」と「受信機」という2つのマシンがあります。
送信者は毎晩次のコマンドを実行します。
zfs send -i bpool/backups@2018-09-04 bpool/backups@2018-09-05 | ssh receiver /sbin/zfs receive bpool/backups
送信者から受信者に最新のbpool /バックアップを送信します。 （日付は毎晩自動的に生成されます。）
誰か（受信者側）が次のことを行う場合：
cd /bpool/backups
ls
次のエラーにより、夜間のバックアップ操作が中断されます。
root@sender:~# zfs send -i bpool/backups@2018-09-04 bpool/backups@2018-09-05 | ssh recevier /sbin/zfs receive bpool/backups
cannot receive incremental stream: destination bpool/backups has been modified
since most recent snapshot
warning: cannot send 'bpool/backups@2018-09-04': Broken pipe
（atimeが更新されたためだと思います。）
これが起こらないようにするにはどうすればよいですか？ （receiver：/ bpool / backupsを読み取り専用に設定すると、受信操作はどうなりますか？）
ベストアンサー1
あなたもちろんターゲットデータセットを読み取り専用にします（ターゲットreadonly=onデータセットまたは親データセットのいずれかにzfsプロパティを直接設定することによって）。これは、更新されたスナップショットの受信を妨げません。これはreadonly、データセットに含まれるファイル（ディレクトリ、属性）を変更できないことを意味します。
readonly=onこれはプールをインポートするときの設定とは異なります。プールを使用することは、readonlyIOがプールのバックエンドに何も書き込めないことを意味します。
私は原則として、誰もとにかく許可されたデータセットを変更してはいけないので、許可された答えにあまり満足していません。
私が移行に反対するもう1つの理由は、増分スナップショットデータ（）を受け取る-Fと移行が行われるためです。zfs send -i data@older-snap data@newer-snap-F返品元のデータセットに存在しないスナップショットは、バックアップデータセットから削除されます（最新のデータでも）。予期しない状況が発生した場合（単にエラーを無視するよりも）、サービスが失敗してエラーを報告するようにサービスを設計することを常にお勧めします。
atime=offバックアッププール/データセットの場合は目的に反しているため、これを設定することもできます。
編集：ああ、次を使用して受信データセットでのみこれらのプロパティを設定できることを追加する必要があります（これらのプロパティはソースデータセットで直接設定するとオーバーライドされます）。zfs receive -o atime=off -o readonly=on