実験段階という警告文を気にせずおうちサーバでZFSを使ってみた感想とか。まだ運用開始から3日なのであまりたいしたことは書いていません。
| [UFS] | 1回目・・・76秒 2回目・・・57秒 3回目・・・58秒 |
| [ZFS] | 1回目・・・34秒 2回目・・・4秒 3回目・・・4秒 |
DATE=`date +%y%m%d` ; zfs snapshot -r tank@$DATEこれだけ。しかも Leopard のタイムマシーンよりも速くて、現在のスナップショットを作るだけなので一瞬で終了します。これまで毎日のバックアップは同一ディスク上にダンプしていた関係で夜中に3時間ぐらいかかってましたから、この差は果てしなく大きいです。
ただ、欠点は同一ディスクに差分を保存する形式なので、だんだん使用可能領域が減ってくること。というか、大きいファイルを消しても残容量がちっとも増えないという点はある意味で衝撃的かも(笑)。もちろんスナップショットを削除すれば残容量は増えます。
バックアップ機のHDDを接続して運用再開するという離れ業ができます。実際にはメイン機はミラーリングしてるので同時に死亡するのは考え難いのと、バックアップ機のATA133-HDDはメイン機のSATAポートにそのままでは接続できない(^^)のであんまり現実的ではないですが、理論上可能であることは面白いです。
という感じで、パフォーマンスの低下は感じられないので今のところメリットづくしです。ひとつだけ困ったのは、うちではタイマー録画用Windows機のディレクトリを mount_smbfs でマウントしていますが、「Windows機が電源OFFだと zfs rename や set に非常に時間がかかる」こと。電源を入れたり umount しちゃえば問題ないのですが、これまでは df で時間がかかるぐらいしか弊害が無かったので今後は運用方法を少し変更する必要がありそうです。
(おまけ) 別のPCにZFSでバックアップするシェルスクリプト
#!/bin/sh
ping -c 1 toriyu10
if [ $? -eq 0 ]; then
(df ; zfs list -t filesystem) | ssh -c blowfish toriyu10 "cat >/backup/df.txt"
zfs snapshot -r tank@now
FS=`zfs list -t filesystem | awk '/tank\// { print $1 }' `
for i in $FS
do
echo "Sending $i"
ssh toriyu10 "zfs list $i@old " 2>/dev/null
if [ $? -eq 0 ]; then
echo "incremental backup"
zfs send -i old $i@now | ssh -c blowfish toriyu10 "zfs receive -F $i"
if [ $? -ne 0 ]; then
echo "incremental backup failed. trying full backup"
ssh toriyu10 "zfs destroy -r $i" 2>/dev/null
zfs send $i@now | ssh -c blowfish toriyu10 "zfs receive $i@old"
else
ssh toriyu10 "zfs destroy $i@old" 2>/dev/null
fi
ssh toriyu10 "zfs rename $i@now old"
else
echo "full backup"
ssh toriyu10 "zfs destroy -r $i" 2>/dev/null
zfs send $i@now | ssh -c blowfish toriyu10 "zfs receive $i@old"
fi
zfs destroy $i@old 2>/dev/null
zfs rename $i@now old
done
zfs destroy tank@now
fi
zfs rename に -f オプションがあったらあらかじめ destroy しなくても良くなるのでもっとスマートに書けるのだろうなーと思います。転送元で間違って 'zfs destroy -r tank' なんかやっちゃうと一巻の終わり(笑)なわけで、コマンドラインで destroy を使うのは極力避けたいものです。
□ 関連記事