FreeNASをVMware上で実験してみた

普段、自宅ファイルサーバとして利用しているFreeNASですが、正常系は問題なく動作しているものの、トラブルが起きた場合の処置についてはこれまで調べてきませんでした。
そこで、今回ちょっと調べてみたいと思います。

まず、VMware上にFreeNAS9.1の32bit版をインストールしました。ホストシステムが32bit+PAEカーネルのLinuxMint13なので、FreeNASも32bit版を選択しました。
起動用のHDDは10GB、データ用のHDDはSCSIで10GB×2(それぞれのディスクに1A,1Bという名前を付けました)としました。

インストール自体は特に問題ありません。ホスト名などは適当にvmFreeNASとしました。

インストール後、パスワードを設定し、10GBのディスク2本で暗号化ありのZFSボリュームをミラーで作成しました。

これをCIFSで共有するわけですが、いつものことながら、今ひとつよくわかりません。設定してからLinux側から見えるようになるまで時間がかかるためでしょうか。
まあ、今回の目的は暗号化関連なのでよしとします。

適当なファイルをvmFreeNAS側に置いた状態で、今度は暗号化ZFSボリュームにパスフレーズをつけてみます。これまでは暗号化していてもパスフレーズもなしで運用してきました。

実験1:ディスクのみ持ち出した場合にどうなるのか?

仮想FreeNASサーバを2台動かして、1台目のディスク2台(ミラーなので)をコピーして、そのうちのディスク1台をFreeNASサーバ2台目に付けてみます。

普通にボリュームを作成しようとすると、中身のあるディスクとしては認識されず、初期化しようとします。つまり、ディスクを持ち出しても読み出せそうにありません。

001

しかし、「ボリュームの自動インポート」を行うと、暗号化ボリュームをインポートするか聞いてきます。

002

ここでYesを選んでOKを押すと、

003

暗号化キーを確認してきます。ここで、元のFreeNASサーバからエクスポートした暗号化キーのファイルを指定してやると・・・ボリュームも指定しろ、とエラーがでました。(下記)

004

とにかく、両方指定してやると、

005

元のボリューム名を確認してきます。そこでOKを押すと、

006

無事にインポートされました。シェルで中のファイルを見ると、確かに存在していそうです。ミラーしたディスクの片方しかマウントしていないので、DEGRADEになっていますが、とにかくファイルの救出はできそうな感じです。

なお、ミラーを構成する2つのディスクを接続してからボリュームの自動インポートを行い、ディスクを指定する際に2つとも指定してやるとミラーであることを認識してミラーディスクとしてインポートされました。
一度でも片方だけでインポートすると、一旦ボリュームをデタッチしてもミラーとしてはインポートされなくなるようです。(当然といえば当然な気がしますが・・)

実験1をまとめると、暗号化キーとミラーディスクの片方があればデータは復旧可能。

実験2:パスフレーズをつけたディスクは起動時にどうなるのか?

もう一つ気になっていたことがあります。暗号化キーにパスフレーズをつけた場合に、起動時に入力が必要なのかどうかです。これまでは起動時に入力するのは面倒なので、パスフレーズをつけずに運用していました。
一方で、考えようによってはパスフレーズを入力しなければ決して中身の見えないサーバとして運用することもできるかもしれないわけです。

というわけで、実験してみました。

先に2台のディスクのコピーを持ち込んだらHEALTHYに復帰した2台目の方で、パスフレーズをつけて再起動してみました。

007

起動後、ボリュームはロックされた状態になりました。

008

ロックされたボリュームを選択して、下の方のUnlockをクリックします。

009

パスフレーズを入力して「OK」をクリックします。

010

無事にアクセスできるようになりました。(正確にはCIFSでアクセスできるかは確認していません。例によって、見えたり見えなかったりが不安定なので。シェルでディレクトリやファイルの存在を確認しただけです。)

実験2のまとめ:パスフレーズを設定すると、起動後にパスフレーズを入力するまではアクセスできない。

“FreeNASをVMware上で実験してみた” への8件の返信

  1. 私のfreenasが調子悪いので再セットアップしたのですが
    import volumeの最中にリセットがかかり
    インポートが終了しません
    どうすればいいのですか?

    1. うーん、自分がImportVolumeしたときには特に問題が起きたことがないのでわからないですね。
      ただ、何をするにしてもデータ消失が一番恐ろしいので、バックアップはこれでもかというくらい取っています。(ちょっとやりすぎだとは思いますが・・・)

  2. FreeNAS(Ver.9.3)からRsyncを利用して、NETGEAR ReadyNAS 102(Ver.6.4.2)にSSHを使用せずバックアップしようとしていますが、どうにもうまくいきません。
    FreeNAS側で何が悪いのかLOGが見られれば良いのですが…
    何かコツがあるのでしょうか?

    ReadyNASには、adminのアカウントを作成してみたり、rootのアカウントで送信してみたりしていますが、手塞がりです。
    もしコツとかあればご教授いただけると幸いです。

    1. 返信が遅くなってすみません。
      NETGEARについては知識がないので一般論になりますが、
      ・rsyncの相手側でrsyncdが動いているか?
      ・rsyncd側でポートが開いているか?
      ・双方のログはどうなっているか?
      といった話がまず基本かと思います。
      ・・・が、そんなものはとっくにできるだけチェックされているでしょうから、なんとも言えないところです。
      自分だったら次にどうするかというと、たぶん10MのダムHUBかまして別のPCからWiresharkでパケットキャプチャして、RFCみながらプロトコルを追いかけるでしょうね。一番間違いのない情報になりますので・・。

      1. ご連絡ありがとうございます。
        NETGEAR側のrsyncdは動いていてポートも開いています。
        ただ、FreeNAS側のRsyncの通信LOGがどこにあるのかわからないため確認ができません。
        LOGはどこにあるかご教示いただけませんでしょうか?

        Wiresharkでキャプチャ…そんなスキルはございません(笑)

        1. 自分はFreeNAS9.1.5(だったかな?)からアップデートしてないのですが、/var/log/message の中に rsync が吐いているものが含まれてるみたいですよ。
          見るにはシェルを開くか、SSHでログインするかが必要ですが・・。

          1. ありがとうございます。
            にわかに忙しくなったのと、NETGEARのNASを初期化したためとで、しばらくは着手できそうにありません。
            手が空きましたら、NASを再セットアップしてRsyncのLOGを確認してみようと思います。

  3. ご無沙汰しております。
    時間ができたので、NETGEARのNASを再設定しrsyncをパラメータを変更しながら何度か試しましたところ、NETGEAR側の共有フォルダのrsync設定にある『パスワード保護』を無効にしたところバックアップできました。
    FreeNASとNETGEARとでパスワードを設定し直しても「パスワード保護」を有効にするとバックアップできません。
    FreeNASのlogには
    「FreeNAS rsync: Password: @ERROR: auth failed on module backup
    「FreeNAS rsync: rsync error: error starting client-server protocol (code 5) at main.c(1636)」
    と怒られました。
    原因はわかりませんが、取り敢えずはパスワード無しでのバックアップができましたのでご報告させていただきました。
    ご教示ありがとうございました。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)