2014年4月アーカイブ

2006年の8月からずっと使っていた、TeraStationがついに最期を迎えた。
最初は、HUBのlink ledがつかなくて、TeraStationのLCDにも何かエラーが出ている状態で、その後TeraStationを再起動したら、LCDにはエラーが出ずに起動するんだけど、pingには応答するけどサービス(web/smb)には接続できない状態に。
今まで2回くらい玉を変えてだましだまし使ってきていたけれど、このへんが潮時だと思われた。
TeraStationの使用用途は、家庭内用のNASとして、過去の写真、動画、音楽(iTunesのライブラリ)、後は確定申告等のデータなどを置いていた。
過去の写真などはなくなると困るので、同じメーカーのLinkStationを購入し、週次でバックアップを取っていた。
TeraStationの復旧を諦めるとして、代替の手段を検討する必要がある。

1. TeraStationのようなNAS専用機を買う
2. TimeCapsuleにUSBでHDDを増設して、そこを使う
3. FreeBSDにHDDを増設して、そこを使う

3番目が一番柔軟にできるのだが、FreeBSDが死んだ時の影響が大きくなってしまう。
そこで、今回も1番目のNAS専用機を購入することに決定。
ヨドバシを覗いたら、I-O DATAのHDL2-A4.0と言うのが安くなっていたので、早速購入。
自宅に帰ってLANに繋いで起動してみると、起動に3分くらいかかる。これにはびっくり。
早速バックアップが入っているLinkStationを起動して、データのコピーを始めて見たが、途中で読み出せないファイルがいくつも出てきた。
どうも、Macから書いたファイルの一部が、読み込みできないらしい。
LinkStationの場合、ゲストユーザでNASに書き込むと、adminと言うユーザがオーナーになるようなのだが、バックアップ機能でバックアップしたファイルについてはオーナーがrootになるらしい。
さらに、今回読み出せなかったファイルは、ファイルのパーミッションが rw-rw--w- みたいになっていて、otherの read パーミッションがない状態になっているようだ。(ftpで繋いでlsで確認)
LinkStationを開けて中のhddを取り出して、ext2が読めるマシンに繋げばサルベージできそうではあったけれど、開けるのが面倒そうなので当面ほっておくことに。

バックアップから新しいNASへのコピーが終わったら、次は新しいバックアップ体制をどうするか決めないといけない。
良く調べないで安い方を選んだのがいけないのだけれど、BuffaloとI-O DATAではバックアップの考え方(考え方だけじゃなく方式も違うけど)が違うらしく、Buffaloはバックアップのソース側が主体になってバックアップ先にファイルを送るのに対し、I-O DATAはバックアップ先の方が主体になってバックアップ元に取りに行く形式らしい。
なので、今までどおりメインのNASからLinkStationにバックアップを取ると言うのは不可能になってしまった。
そこで、LAN DISKにUSBでHDDを繋いで、LAN DISKのバックアップ機能でバックアップすることに。
ここでも良く調べないで、適当に安そうだったWestern DigitalのWDBFJK0040HBK-SESNと言うのを買ってみた。
が、こいつをLAN DISKに繋いでみてもmountに失敗する。フォーマットにも失敗する。MacやWindowsにつなぐと認識するので、そっちでフォーマットしてみても同じ。(GPT/NTFS/4Tとか、MBR/FAT32/2Tとか試してみたけど駄目)
これはハズレを引いちゃったかな〜と思いながら、FreeBSDに繋いでufsで4Tフォーマットしてみた。
TeraStationは、root奪取ができたので、自分でrsync使えるようにしたり、snmpdを入れてみたり、apcupsdを入れてみたりして快適に使えていたんだけど、LAN DISKは今のところそこら辺を試してみれていないので、手軽にFreeBSDに繋いだhddにバックアップする方法が思いつかない。

こんなことなら、案3を採用して、SATAのHDDを2台買った方が良かったな〜とため息しきりなのです。

前回の続き。
お亡くなりになったTeraStationの代わりに購入したLAN DISKと、合わせて買った USB HDDでバックアップが取れないことがわかったので、USB HDDをFreeBSDに繋いでなんとかLAN DISKのバックアップが取れないかと検討した結果、mount_smbfsとrsyncで普通に行けるんじゃないの?と言うことになったのでその記録。

まず、USB HDDをFreeBSDに繋いだら、dmesgでどのように認識されたか見てみる。

# dmesg
ugen0.2: <Western Digital> at usbus0
umass1: <Western Digital My Book 1230, class 0/0, rev 3.00/10.50, addr 1> on usbus0
umass1:  SCSI over Bulk-Only; quirks = 0x4001
umass1:5:1:-1: Attached to scbus5
da5 at umass-sim1 bus 1 scbus5 target 0 lun 0
da5: <WD My Book 1230 1050> Fixed Direct Access SCSI-6 device
da5: Serial Number xxxxxxxxxxxxxxxxxxxxxxxxxxxx
da5: 400.000MB/s transfers
da5: 3815415MB (976746240 4096 byte sectors: 255H 63S/T 60799C)
da5: quirks=0x2<NO_6_BYTE>
ses0 at umass-sim1 bus 1 scbus5 target 0 lun 1
ses0: <WD SES Device 1050> Fixed Enclosure Services SCSI-6 device
ses0: Serial Number xxxxxxxxxxxxxxxxxxxxxxxxxxxx
ses0: 400.000MB/s transfers
ses0: SCSI-3 ENC Device
GEOM: da5: the primary GPT table is corrupt or invalid.
GEOM: da5: using the secondary instead -- recovery strongly advised.

ここからわかることは、HDDはusb mass storageとしてda5で認識されたこと、ses0とか言う名前でセキュリティデバイスっぽいものが認識されたこと、GEOMがGPTテーブルがおかしいよと報告していることがわかる。
GPTテーブルがおかしいのは、一度GPTでフォーマットした後にMBRで再フォーマットして、さらにLAN DISKがフォーマットに失敗しているから。
この状態で、一度GPTの情報を消去して、単一パーティションとしてフォーマットする。(zfsにするかufsにするか迷ったんだけど、zfsはメモリが潤沢なシステム向け、かつディスクの玉がたくさんある環境向け、と読んだ気がするので、ufsにする)

# gpart show da5
=>        6  976746229  da5  GPT  (3.7T) [CORRUPT]
          6      32768    1  ms-reserved  (128M)
      32774        250       - free -  (1M)
      33024  976712960    2  linux-data  (3.7T)
  976745984        251       - free -  (1M)
# gpart destroy -F da5
da5 destroyed
# gpart create -s GPT da5
da5 created
# gpart show da5
=>        6  976746229  da5  GPT  (3.7T)
          6  976746229       - free -  (3.7T)
# gpart add -t freebsd-ufs da5
da5p1 added
# gpart show da5
=>        6  976746229  da5  GPT  (3.7T)
          6  976746229    1  freebsd-ufs  (3.7T)
# newfs /dev/da5p1
# tunefs -n enable /dev/da5p1

ここまででufsのファイルシステムができたので、後は好きなところにマウントする。
バックアップ用に使うので、/backup2にマウントすることにした。(/backupは既に使っていたので)

# mkdir /backup2
# grep backup2 /etc/fstab
/dev/da5p1      /backup2        ufs     rw,noauto       0       0
# mount /backup2
# df -h /backup2
Filesystem              Size    Used   Avail Capacity  Mounted on
/dev/da5p1              3.5T    8.0k    3.2T     0%    /backup2

後は、どうにかこの新しい領域にLAN DISKのデータをバックアップすれば良いのである。
過去に試したのは、主にsmbclientを使った方法で、文字コードの問題でなかなかうまくいかなかった。
最近の動向はどうなっているのか調べがてら、mount_smbfs のマニュアルをつらつらと眺めていたら、文字コードの変換も-Eオプションとか言うのでなんとか行けそうに見える。
そこで、

# mkdir /mnt/disk
# mount_smbfs -E utf-8:cp932 //landisk/disk /mnt/disk

みたいにやってみたところ、マウントはできるが日本語のファイル名が化ける。(あ、localeはja_JP.UTF-8)
なんでだろ〜、と調べてみたところ、[FreeBSD-users-jp 92712] mount_smbfs で CP932 を UTF-8 として mount できないと言うスレッドを発見。
これは、RELENG_8だからFreeBSD8の頃の議論なのだけれど、「utf-8→UTF-8のaliasが動作しないのは、・・・」と言う一節を発見。

# mount_smbfs -E UTF-8:cp932 //landisk/disk /mnt/disk

に変えてみたところ、無事に日本語のファイル名が見られるようになった。
さらに、いつも困っていたパスワード周りの話も、/etc/nsmb.conf または ~/.nsmb.conf に書けることを発見。
早速/etc/nsmb.conf に以下を記述。

[LANDISK:USER]
password=$$1xxxxxxxxxx
charsets=UTF-8:CP932

はまりポイントとしては、以下。

• セクション[LANDISK:USER]は大文字で書く必要がある
• password=の値は、smbutilと言うコマンドがあるので、smbutil crypt で生成することができる
• mount_smbfs でマウントした場所のファイルのオーナーは、見かけ上マウントしたディレクトリのオーナーになる(上記の例の場合、/mnt/disk のマウント前のオーナーになる)。-u, -g オプションで上書き可能だが、smbfsの特性上サーバ側から見ると「samba maount した人」からのアクセスになるし、クライアントから見ると「samba mount した人に許可された操作」しかできないことになるので、こう言うことになるのだろう。

簡単な暗号化をかけるとは言ってもパスワードを書くファイルなので、/etc/nsmb.conf は root のみrwである。
ここまでくれば、後は普通にrsync で mount_smbfsしたディレクトリから、/backup2にバックアップしてやれば良いことになる。
家庭内だし、バックアップ目的なのでrootで全部やっても良いかなとは思ったんだけど、なんとなく一般ユーザでやるようにしてみた。(mountだけはrootでやらないといけない)
これで手動でのバックアップはできるようになったので、後は自動化するスクリプトを書けば良いんだけど、面倒だなあ・・・。