FreeBSD 10.2 のテスト環境で、パーティション丸ごとバックアップを取ろうとして dump コマンドを発行したところ、つぎのメッセージが表示されて、バックアップ失敗。
# dump -0uaLC 32 -f root.dump / mksnap_ffs: Cannot create snapshot //.snap/dump_snapshot: /: Snapshots are not yet supported when running with journaled soft updates: Operation not supported dump: Cannot create //.snap/dump_snapshot: No such file or directory
仮想 WordPress 環境を更新しようとテストを行っている途中で発生しました。
検索してみると同様のトラブルと対策が見つかりました。
https://forums.freebsd.org/threads/filesystem-journaling-and-dump.41503/
FreeBSD 9 以降では、ファイルシステムのジャーナル機能が強化され、ブチッと電源が切れたり、間違ってリセットボタンが押されたりしても、あっという間にファイルシステムチェックを終了して元通りに動く事が出来る仕組みが導入されたようです。各パーティションの下に、.sujournal というリードオンリー400 のファイルがあれば導入されているという事。
確かに実マシンでは安心できる機能だと思います。突然の停電で電源が落ちても、壊れて失われるファイルが発生しないという安心感はありがたいところです。（人的ミスや悪意の操作は防げませんからバックアップが必要無いという意味ではありませんよ。）
dump コマンド実行時のエラーの意味は、このジャーナルファイルシステムを使うと、バックアップコマンドの dump が未対応であることを示しています。
私の場合は、バックアップとシステムメンテナンスに dump コマンドを使用しています。パーティションを丸ごとバックアップでき、差分バックアップが出来るので、重要な操作；たとえばメジャーバージョンアップ；を行う前に実施しておけばかなり安心できます。
また、パーティション容量が不足してきたときに、大きなHDDにデータを移すときに重宝します。
今回の場合は、後者のデータ移設が目的なんですが、ジャーナルファイルシステムを一旦解除して、dump を実行し、再度ジャーナルを有効に戻す必要があるようです。（元に戻さず、ジャーナルを利用しないという手もある。）
やってみましたが使用中のパーティションに対しては変更できないため、結構面倒。
- シャットダウンしてシングルユーザーモードで再起動。
- tunefs -j disable <device file名> で、バックアップしたいパーティション分 実行する必要があります。/etc/fstab を見ながら作業します。
- その後で、.sujournal を消す。（消さなくても dump は実行できるかもしれませんが、restore の時に書き込まれそうで面倒だから、ここで消しておきます。）
- 問題は / (root) パーティションで、シングルユーザーモードでも Read Only で使用されてしまうので、ジャーナル解除した後、リブートしてマルチユーザーモードで読み書きできる状態で再度消去する必要があります。
また、消そうとすると rw パーミッションだけじゃなく、chflags で操作する必要が出てきます。
この後、元のジャーナリングに戻すなら、再度 tunefs -j が必要になります。テストシステムなので私は戻さなかった。
/boot ,/var, /dev 以外のバックアップは、cpio で十分なんですけど、こいつらの下は何が起きているか分からない動きをしているので、OSまるごとバックアップできる dump/restore の使い勝手が悪くなっているのはちょっと残念。エラーメッセージは「not yet」なので、今後が期待できるのかも。