btrbkを使ってssh経由で転送するときに broken pipe が発生する問題の解決
記事の導入
ZFSからbtrfsに乗り換えた。
TrueNAS(FreeBSD系)からDebian(Linux系)への乗り換えに伴って、ライセンス的に不安があるZFSではなくbtrfsを利用することにした。
データを物理的に複数の場所に置いておく方法として、ZFS(TrueNAS)には「Replication」という機能が提供されていた。
btrfsはsendとrecieveという機能がある。これは、btrfsのサブボリュームを標準出力に出す事(send)と、標準入力から受け取る事(recieve)ができる。
標準入出力を使うので、例えばパイプで渡したり、サブボリュームをファイルに書き出すことができる。パイプで渡せるということは、SSHで外に出すことも可能。
btrfsにはZFSと同様にスナップショット機能もある。btrfsでスナップショットを取ると、サブボリュームとして扱える。
この機能を組み合わせると、スナップショットを取って外部で保存ができるということ。
で、そのスナップショットの世代管理までやってくれるツールがbtrbk。ssh鍵を使ってssh経由での転送に対応してるのが強み。
btrbk
- GitHub - digint/btrbk: Tool for creating snapshots and remote backups of btrfs subvolumes
- btrbk - btrbk.conf(5)
ハマりどころ
使い方はドキュメントの通りなのでこの記事では割愛。ドキュメントはかなり親切に書いてある。
私の環境では、サーバー2台用意し、片方をバックアップのストレージとしている。
で、初回の転送が Broken pipe でどうしてもうまくいかないというトラブルに悩まされた。
結果を言えば、大容量の転送をsshで実施すると再現するようで、メインサーバーにストレージを直接接続してローカルで初回の転送を済ませておく事で、ssh経由の大容量転送を回避することで事なきを得た。
大容量というのが、うちの環境では4TBくらいとみている。停止するタイミングが正確には分からないが、前後のストレージ使用量からの推測。
初回の転送さえ完了させてしまえば、以降の転送は差分だけなので、一気に大量のファイルを転送することがなければ運用できると考えている。
大容量ファイルが発生する場合でも、転送の頻度を上げることで1回の量を減らすことで回避する運用をする。
コメントを残す