#foltia

foltia anime lockerでは、録画した番組をストリーミング再生することができる。しかしストリーミング再生の場合、mp4をそのままではなくトランスコードしてクライアントへ転送するため、マシンに負荷がかかる。複数チャンネル同時録画中にストリーミングすると、HDDの速度が追いつかなくなって、dropが発生する原因ともなりかねない。しかし視聴しなければ録画している意味がない。さらにスマホで視聴する場合、モバイルネットワークでストリーミングすると、あっという間に通信量が7GBを超えてしまう。

これを解決する一つの方法がfolcastである。folcastはfoltia+podcastを合成したもので、要するに録画した番組をpodcastで転送できる機能である。スマホのpodcast機能に、folcastのURLを登録すれば、圧縮の終わったmp4ファイルを全自動でスマホにダウンロードしてくれるようになるのである。

また、最近のPC向けメディアプレーヤーにはだいたいpodcast機能がついているので、スマホでなくてもfolcastは便利である。foltiaALはブラウザからしか視聴できないので、大画面に接続したリビングパソコンで視聴するときは操作しにくい。よく見る番組をメディアプレーヤーのpodcastに登録しておけば、少し使いやすくなる。このあたりはプレーヤーの種類にもよるが。

folcastを利用するには、ブラウザからfoltiaにアクセスし、folcastのURLを拾う必要がある。

キーワード録画した番組の場合、録画一覧＞キーワード録画に入って、リストから目的のキーワードを選択する。

図示した部分に「このキーワードのfolcast」という項目がある。ここを左クリックしてもxmlファイルがダウンロードされるだけなので左クリックしないように。右クリックして出てきたコンテキストメニューから「リンクのURLをコピー」。

これをメディアプレーヤーのURL入力ボックスにペーストして、登録完了。自分の場合はWalkmanを使っているため、MediaGoを利用している。

ちなみにアニメ自動録画の場合は以下のようになる。

録画一覧＞アニメ自動録画から、番組名を選択する。サブタイトルではないので注意。

キーワード録画のときと同じように「この番組のfolcast」を右クリックし、コンテキストメニューから「リンクのURLをコピー」。あとは同じ。

一つ注意すべきなのは、MediaGoなどのPC用メディアプレーヤーのpodcast機能を使う場合、自動ダウンロード機能は切っておいたほうがよいということ。なぜなら、これらのメディアプレーヤーは、複数アクセスが来ても大丈夫な業務用podcastサーバからダウンロードすることを前提に作られている。このため、自動ダウンロードを可にすると、10エピソードくらいを同時にダウンロードしようとしてしまう。しかしfoltiaを入れるマシンは（ほとんどの場合）普通のPCであり、しかも録画と圧縮を同時にやっているので、10エピソードも同時にダウンロードしようとすると、録画のdropが発生しやすくなったり、圧縮が極端に遅くなったりしてしまうのだ。よって、自動ダウンロードは避け、見たいものだけ1つずつダウンロードしたほうがよい。同時ダウンロード数を制御できるメディアプレーヤーなら自動ダウンロードでもいいだろうが。

スマホでも基本は同じである。あえて言うなら、foltiaALはスマホ用のページを作ってくれないので、同じ作業を小さい画面でチマチマやらないといけないのが面倒くさいくらいか。ただ、一度登録してしまえばかなり快適になる。

スマホでpodcastのクライアントとして使うプレーヤーは数多くあるが、自分はpodcast addictを使っている。保存先としてSDカードを選択できるので内部ストレージを圧迫しない。自動ダウンロードの条件をWi-Fi接続時のみとすれば、通信量制限も関係ない。自動ダウンロードの開始時間や間隔も自由に設定できる。PC用のメディアプレーヤーと違って、１エピソードずつしかダウンロードしないので、サーバへの負担はあまり心配しなくてよい。朝起きたら前日の番組が自動的にダウンロードされているという素敵仕様である。

ダウンロードした番組を自動的にプレイリストに追加し、視聴が終わったら自動的に削除させることもできる。また未視聴の番組が溜まって困る場合、一定期間を過ぎたら同時に消す機能もあるし、最新のエピソードを残して自動的に古いものを削除するような設定もできる。残す数も１、３、５、１０などから選択できる。これらの設定は、番組ごとに設定することも可能だ。

カテゴリ分けもできる。

視聴済みのエピソードは削除し、リストからも見えなくする設定ができる。

ウィジェットもある。至れり尽くせりだ。

思うように動かそうとすると細かい設定が必要だが、デフォルトのままでも十分便利だと思う。

自分はスマホで視聴するのは通勤中の車内だけである。運転中にアニメやドラマを見るのは危ないので、ニュースだけにして音だけBluetooth接続で聞いている。ステアリングリモコンが対応しているか不安だったが、ステアリングリモコンの左右が30秒スキップに対応しているため、CMスキップにちょうどいい。プレイリストを有効にしておけば、いちいち操作しなくても次のエピソードに移動してくれるので便利である。

録画鯖で録画した番組が正常に再生できないことが頻発する。foltiaAL公式サイトではこういう場合、元のtsファイルを参照せよとしているが、元のtsファイル自体が再生できないこともある。こうなると面倒だが、原因によっては再生できることがある。以下に原因と対処法をメモする。

①そもそも録画ができていない

ファイル情報を見て、ファイルサイズが極端に小さい場合、そもそも録画できていない可能性が高い。録画できなかった番組は諦めざるを得ないが、今後のために予防策は必要だ。原因としてはチューナーより上流での異常が最も疑われる。まずはアンテナやケーブル、チューナーカードの接続などハードウェア面を確認すること。これらが問題ないのにC/N（アンテナ感度）が低い場合、電波状態が悪いか、ノイズが入ってきているか、チューナー自身に問題がある可能性がある。電波が弱いのであればブースターをかませれば改善する見込みがある。ノイズが乗っているのであれば、ケーブルを整理したり、シールドの施されたケーブルや分波器、分配器に交換する。同一条件の他の機器で視聴できるのであれば、チューナーの故障を疑うことになる。

②復号化に失敗している

ファイルサイズは大きいのに全く再生できない場合、あるいは途中から再生できない場合、復号化に失敗している可能性がある。復号化にはB-CASカードが必要であるから、B-CASに何らかの問題がある可能性がある。単純にカードの接触が悪い、向きが間違っているなどのケアレスミスもあるが、マザーボードの省電力機能でカードリーダーが動いていない場合や、デバイスドライバの不具合も考えられる。マザーボードの省電力機能は原則としてすべてオフにしたほうがよいが、デバイスドライバの不具合の場合、対策はない。

復号漏れが発生してしまったファイルは、記録自体はできているので、再生できるようにすることは可能である。まず、復号漏れが疑われるファイルを別のPC（ここではWindows環境を想定している）にコピーし、Multi2Decというツール（開発者に感謝）でTSエラーチェックを行うと、復号漏れの箇所をカウントしてくれる。これで復号漏れが確認できたら、PCに接続したICカードリーダーにB-CASカードを突っ込んで、スクランブル解除を実行する。カードがないと解除できないので、適当に使っていないカードを別途持ってくること。

自分の場合、原因は特定できていないが、長時間電源を入れっぱなしで使っていると復号漏れが発生しやすいようなので、１日１回は再起動するようにし ている。正直面倒くさいので他の対策が欲しいところ。もしかすると内蔵のICカードリーダーを使ったことが問題だったのかもしれない。定番のNTTのカー ドリーダーにしておけばよかったか。復号漏れの解除のためにNTTのカードリーダーを買ったので、将来的にはカードリーダーを入れ替えてみるつもり。

③dropの発生が多い

途中まで再生できており、ファイルサイズもそれなりにあるにもかかわらず、途中から再生できなくなっている場合、録画時の記録ミス＝dropが発生している可能性もある。foltiaALのログでもdropは確認できるが、上記のMulti2DecのTSエラーチェックでdropの確認もできる。復号漏れと同様の症状になることが多いため、視聴できないファイルはすべてMulti2DecでTSエラーチェックをかけたほうが手間が省ける。

予防策として、dropの原因としては電波状態の不良からHDDの記録が間に合わないなどの原因が考えられる（CPUやメモリはあまり関係なさそう）。まずは①と同様、ケーブルの整理やシールド、ブースターなどの電波改善を考える。それでもdropがあるようなら、記録部分での問題がある可能性がある。SATAケーブルが規格に則ったものか確認したほうがよい。また、複数チャンネル同時録画する場合には、高速なストレージでないと記録が間に合わなくなることが多いらしい。自分の場合はストレージの問題よりは電波の問題のほうが大きいようだが。

dropしてしまったファイルは途中から再生できないことがあるが、VLCplayerなどの一部のプレーヤーであれば強引に再生させることができる。 他のプレーヤーで再生したい場合は、VLCplayerの変換機能で素通しエンコードをすれば、他のプレーヤーで再生できるようになる。ただし、drop したフレームは修復できないので、数が多いと視聴に堪えないものになってしまう。

④ワンセグ画質になってしまう

ファイルサイズがそれなりに大きく、フルセグが記録できているはずなのに、視聴しようとするとワンセグ画質になってしまうことがある。地デジを録画すると、フルセグとワンセグ両方の映像ストリームが記録され、通常はファイルを開くとフルセグのストリームが自動的に選択されて再生される。しかし、たまに自動選択がうまく働かずにワンセグが再生されてしまうことがある。この場合、映像ストリームを分離できるTSSplitterというツールを使う（開発者に感謝）。『HD画質を残す』だけを選択して変換すれば、ワンセグのストリームを捨ててフルセグのみを出力できる。あとは視聴も変換も問題なくできるはずだ。予防策として、foltiaALのコンフィグで『HDスプリットを行うか』をYesにするという方法があるが、これをやると必要なストリームを捨ててしまう可能性もあって、実用性には疑問符がつく。もう少し調査してみるつもりだが。

今のところ、自分が遭遇しているエラーは上記がほとんどである。復号漏れ、drop、ワンセグの問題を合算すると、少なく見積もっても1/4以上で発生している。復号漏れは一度発生するとその後続けて発生するので、適当なタイミングで再起動をかけつつ、漏れたファイルをメインマシンに移して復号化してスプリットしてエンコードしてfoltiaに戻して、とやっているとかなり手間がかかり、完全自動には程遠い。自動化を前提とするならば、録画先としてNASをマウントし、これを別マシンで強制復号化→HDスプリット→エンコード→ストリーミングサーバに転送、とするしかない。要するにエンコ鯖とストリーミング鯖を別に用意しなければならないので、知識も技術も金もかかる。また自動化すると、5.1chなどの音声ストリームを捨てられてしまう可能性もあり、それはそれで痛い。

ここまでやってみると、nasneの安定性を強く実感する。まあ、どっちもどっちなので、結局は使い分けるしかないということなのだろう。

他にネットで見つけたエラーも参考までに挙げておく。

○mpeg-tsのプロファイル切り替えができていない

プロファイルがCMから本編の間で切り替わっているのに、録画されたtsファイルではプロファイルが正常に記録されていないことがある。冒頭のCMカットで対処できることがある。

○タイムコードが壊れている

安定してきたと思った録画鯖だが、何故か地デジだけ映らなくなった。視聴も録画もできない。BS/CSは視聴も録画も可能である。チューナーのC/Nを確認したところ、BS/CSは16～17で感度良好であるのに対して、地デジは当初26程度あったのが6程度まで落ち込んでいる。

チューナーカードを挿し直してもだめ。アンテナケーブルを挿し直してもだめ。ケーブルを変えてみてもだめ。再起動してもだめ。再インストールしてもだめ。

カードリーダーの不具合も考えられるが、BS/CSが映っている時点で除外していいだろう。B-CASカードも認識されている。また当初は映っていたのだから相性の問題というわけでもなさそうである。

foltia anime lockerは自動でmp4へのエンコードをやってくれるが、これをどう運用するかは環境や考え方によって異なると思う。今回は、foltiaALのエンコード能力をテストした上で、運用方法についてまとめてみる。とくにハードウェアの構成によって大きく変わってくるエンコード時間、画質、ファイルサイズに注目した。

まずはエンコード時間。foltiaALはHD画質のmp4へのエンコードとSD画質のmp4へのエンコードができる。このうちHD画質のmp4については、720pと1080pが選択できる。当然1080pのほうが高画質だが、エンコードにかかる時間はおおよそ2倍と言われている。自分の環境(i5 4460)では720pが実時間の75%程度、1080pが実時間の150%程度である（おそらくi7 4790Kを使えば720pで60%程度、1080pで120%程度であろう）。デフォルトでは720pだが、自分は1080pとしている。１日２４時間エンコードしつづけたとすれば、理論的には１日１６時間分の番組をエンコードできることになる。つまりHD画質でエンコードする番組の総時間が１日１６時間を超えると、エンコードより録画の速度が速くなり、エンコード待ちが溜まっていってしまう。よってHD画質でエンコードする番組はこれ以下にしなければならない。調子に乗って録画予約していると１６時間はあっという間なので、HD画質でのエンコードは絞り込む必要がある。

次に画質。これについては画像で比較したほうがいいと思うので、以下に貼っておく。

まずはtsから。

次にmp4。

キャプチャしたものをtumblrにアップロードしたものなので、サイズが縮小されている。このため正確な比較ではないものの、tsとmp4の違いがなんとなくわかると思う。tsでは客席のディティールがわかるのに対して、mp4では客席の奥のほうが潰れており、ブロックノイズが目立つ。mp4は人によってはアーカイブとしては使えないと考えるかもしれない。一方で明るい部分のディティールは保たれており、日常的な視聴には耐えうるレベルだ。ただし前述のように、実時間の1.5倍かけてエンコードしたものを「見たら消す」というのはちょっと抵抗がある。

ファイルサイズについては、NHKBSプレミアムの「クラシック倶楽部」で実験した。実時間55分40秒の番組を録画したところ、tsファイルでは約7.7GBであるのに対して、HD画質のmp4が1.2GBまで圧縮できていた。実時間より時間がかかっているだけあって、優秀な圧縮率である。ただ、番組によってはここまで圧縮できないこともあり、1/3程度の圧縮に留まるケースもあった。それでもnasneの3倍モードに匹敵するファイルサイズと画質なので、まあ満足できるレベルだろう。これらを踏まえて、以下のような運用が考えられる。

①「見たら消す」番組はSD画質のmp4、アーカイブ用にはHD画質のmp4を使う。

これはCPUパワーがある程度必要だが、そこそこの画質でファイルを圧縮することができ、HDDも食い過ぎず、バランスがとれた運用である。

②「見たら消す」番組はSD画質のmp4、アーカイブ用にはtsファイルを使う。

これは非力なCPUを使っている時に取る運用である。CPUがatomなどの場合、エンコードが厳しくなってくる。よってHD画質mp4へのエンコードをすっぱり諦めてtsファイルをそのまま残すというものだ。ただし、当然のことながらHDDをバカ食いするので、「CPUには金を出せないがHDDには金を出せる」という特殊なパターンである。

③「見たら消す」番組はSD画質のmp4、アーカイブ用にはtsファイルを別マシンに移してエンコードする。

これは録画鯖を安く抑えて、別に高性能マシンを用意する場合の運用である。実際にはエンコードを自動で行うことになるだろうから、Linuxでエンコ鯖を作るだけの知識と技術が必要になってくる。このレベルの人は、そもそもfoltiaALを使わないような気もする。

④「見たら消す」番組もアーカイブ用もHD画質のmp4を使う。

これはCPUパワーが有り余っている場合の運用である。ただ、多数の番組をすべてHD画質のmp4へエンコードしようと思うと、Xeonを使ってもかなり厳しいと思う。

⑤「見たら消す」番組はHD画質のmp4、アーカイブ用にはtsファイルを使う。

これはある意味贅沢な運用である。高画質ではあるが、CPUパワーもHDD容量も潤沢に使える場合に限られるだろう。

⑥「見たら消す」番組はHD画質のmp4、アーカイブ用にはtsファイルを別マシンに移してエンコードする。

これはfoltiaALにもそれなりのCPUパワーが必要で、かつエンコ鯖まで必要という、金も知識も必要な構成だ。画質を優先しつつ容量を抑えるにはこの方法になる。

⑦「見たら消す」番組はtsファイルのままにする。アーカイブ用にはHD画質のmp4を使う。

これはHDDが限られているときの運用。「見たら消す」番組はさっさと見てすぐ消してしまうのでHDDが小さくてもなんとかなる。ただし、見る側がかなりマメに視聴して消していかなければならないので、見られるだけの時間が必要になる。しかもビットレートが高いため、ネット経由での視聴には難があり、自宅でしか視聴できない。自宅に長くいる人にしか使えない。

⑧「見たら消す」番組もアーカイブ用もtsファイルのまま。

これは最もHDDを食う運用である。エンコードを一切しないので、CPUはATOMなどの安価なもので十分だが、HDDは大量に必要になる。またネット経由での視聴は事実上不可能である。録画マニアはこの運用になると思う。

⑨「見たら消す」番組もアーカイブ用もtsファイルを別マシンに移してエンコードする。

これもエンコ鯖を別に作る場合の運用である。世の中には録画鯖とエンコ鯖とメディア鯖を個別に作る強者もいるが、エンコードマニアはこの運用をとるだろう。

とりあえず９パターンを挙げたが、これらはあくまで一例に過ぎない。実際にはもっと選択肢がある。例えば「HDでエンコードしたmp4とtsファイルを両方保存する」という人もいて、この運用だとCPUパワーもHDDもかなり必要になるが、高画質のアーカイブとストリーミングを両立できることになる。ただここまでいくと廃人レベルだが。

さて、自分がどの運用を取るかだが、マシンパワーとHDD容量とコストのバランスを考えれば①になるだろう。mp4にすると画質は多少落ちるが、よく見れば元のtsファイルもそれなりにブロックノイズが発生しているので、tsファイルが完全というわけでもなく、当然ながらパッケージメディアには敵わない。だからアーカイブ用にはHD画質のmp4を残して、気に入った作品はパッケージで購入すればいいと思う。このあたりは割り切りが必要だ。

というわけで、録画鯖のSSDやHDD負荷を。

[foltia@foltia ~]$ iostat -m 1                                                                                   Linux 2.6.32-573.18.1.el6.x86_64 (foltia.local)         03/29/2016      _x86_64_        (4 CPU) avg-cpu:  %user   %nice %system %iowait  %steal   %idle 0.00    8.21    9.95   35.07    0.00   46.77 Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn sda             519.00         9.21       102.48          9        102 sdb               0.00         0.00         0.00          0          0 dm-0            511.00         8.98       103.23          8        103 avg-cpu:  %user   %nice %system %iowait  %steal   %idle 0.00   11.50   10.25   19.00    0.00   59.25 Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn sda             597.00        10.98       119.12         10        119 sdb               0.00         0.00         0.00          0          0 dm-0            509.00        10.98        77.79         10         77

負荷の高そうな部分だけを抜粋した。１番組録画、HDエンコード、HDストリーミングをしながらでもiowiatは20%程度でおさまってくれている。体感でも、HDストリーミング視聴時のもたつきが全く感じられなくなった。やはりHDDがボトルネックになっていたらしい。今まではネットで見るものはSD+HDの両方エンコードしていたが、今後はHDだけでもよさそうだ。とはいえCPU負荷やエンコード時間を考えるとすべてHDというわけにもいかないので、ニュースはSDにしておくつもり。

ちょっとわからないのは、変換中でもSSDの読み書きがほとんどないこと。変換などの一時ファイルはSSDにできるだろうと思って、HDDへの負荷を減らすことも考えてSSDを食わせたのだが、どうも変換時の一時ファイルもHDDに書き込んでいるのかもしれない。うーん、せっかく買ったんだのに。まあ起動が早くなったからいいんですけどね。

6TBのHDDを投入。5TB以上も問題なさそう。 冗長性を構築中は書き込み読み込み性能落ち過ぎで、エンコが全然終わらない。

↓変更前

[root@foltia drobo-utils]# ./drobom info --------------------------------------------------------- Drobo Name: Drobo disk pack Devices: /dev/sdb Time: Wed Sep 30 20:44:21 1970 --------------------------------------------------------- Configuration maxima: slots: 4, luns: 16, lunsize: 17 TB Capacity (in GB): used: 2851, free: 1436, total: 4287 protocol version: 0.11 SCSI emulation information: Vendor: TRUSTED Model: Mass Storage Revision: 2.00 /dev/sdb: bus=scsi4 channel=0 id=0 lun=0 (vendor=TRUSTED , version=30527) query slotinfo result: number of slots: 4 slot GB Model Status 0 2000 ST2000DM001-1CH164 green 1 320 WDC WD3200AAKS-00B3A0 green 2 4000 HGST HMS5C4040BLE640 green 3 2000 WDC WD20EZRX-00DC0B0 green Firmware: 1.4.2 Revision: 1.254 ( 50341 ) built: May 18 2012,16:01:50 Features: NO_AUTO_REBOOT,NO_FAT32_FORMAT,USED_CAPACITY_FROM_HOST,DISKPACKSTATUS,ENCRYPT_NOHEADER,CMD_STATUS_QUERIABLE,VARIABLE_LUN_SIZE_1_16,PARTITION_LUN_GPT_MBR,FAT32_FORMAT_VOLNAME,SUPPORTS_DROBOSHARE,SUPPORTS_NEW_LUNINFO2,feature x0800,feature x2000,feature x40000,leftovers (0x400000) /dev/sdb /home/foltia/php/tv Drobo disk pack 66% full - ([], 0) RedThreshold 95 YellowThreshold 85 lun size (GB) used PTFmt FStype: 0 17592 2851 GPT ['EXT3'] ---------------------------------------------------------

↓ 増設

[root@foltia drobo-utils]# ./drobom info ————————————————————————————- Drobo Name: Drobo disk pack Devices: /dev/sdb Time: Thu Oct 1 01:01:10 1970 ————————————————————————————- Configuration maxima: slots: 4, luns: 16, lunsize: 17 TB Capacity (in GB): used: 2880, free: 5086, total: 7967 protocol version: 0.11 SCSI emulation information: Vendor: TRUSTED Model: Mass Storage Revision: 2.00 /dev/sdb: bus=scsi4 channel=0 id=0 lun=0 (vendor=TRUSTED , version=30527) query slotinfo result: number of slots: 4 slot GB Model Status 0 2000 ST2000DM001-1CH164 red 1 6001 WDC WD60EZRX-00MVLB1 green 2 4000 HGST HMS5C4040BLE640 green 3 2000 WDC WD20EZRX-00DC0B0 green Firmware: 1.4.2 Revision: 1.254 ( 50341 ) built: May 18 2012,16:01:50 Features: NO_AUTO_REBOOT,NO_FAT32_FORMAT,USED_CAPACITY_FROM_HOST,DISKPACKSTATUS,ENCRYPT_NOHEADER,CMD_STATUS_QUERIABLE,VARIABLE_LUN_SIZE_1_16,PARTITION_LUN_GPT_MBR,FAT32_FORMAT_VOLNAME,SUPPORTS_DROBOSHARE,SUPPORTS_NEW_LUNINFO2,feature x0800,feature x2000,feature x40000,leftovers (0x400000) /dev/sdb /home/foltia/php/tv Drobo disk pack 36% full - ([‘No redundancy’], 0) RedThreshold 95 YellowThreshold 85 lun size (GB) used PTFmt FStype: 0 17592 2880 GPT [‘EXT3’] ————————————————————————————-

↓ 冗長性構築中

[root@foltia drobo-utils]# ./drobom info ————————————————————————————- Drobo Name: Drobo disk pack Devices: /dev/sdb Time: Thu Oct 1 09:53:59 1970 ————————————————————————————- Configuration maxima: slots: 4, luns: 16, lunsize: 17 TB Capacity (in GB): used: 2914, free: 5051, total: 7966 protocol version: 0.11 SCSI emulation information: Vendor: TRUSTED Model: Mass Storage Revision: 2.00 /dev/sdb: bus=scsi4 channel=0 id=0 lun=0 (vendor=TRUSTED , version=30527) query slotinfo result: number of slots: 4 slot GB Model Status 0 2000 ST2000DM001-1CH164 [‘red’, ‘green’] 1 6001 WDC WD60EZRX-00MVLB1 [‘red’, ‘green’] 2 4000 HGST HMS5C4040BLE640 [‘red’, ‘green’] 3 2000 WDC WD20EZRX-00DC0B0 [‘red’, ‘green’] Firmware: 1.4.2 Revision: 1.254 ( 50341 ) built: May 18 2012,16:01:50 Features: NO_AUTO_REBOOT,NO_FAT32_FORMAT,USED_CAPACITY_FROM_HOST,DISKPACKSTATUS,ENCRYPT_NOHEADER,CMD_STATUS_QUERIABLE,VARIABLE_LUN_SIZE_1_16,PARTITION_LUN_GPT_MBR,FAT32_FORMAT_VOLNAME,SUPPORTS_DROBOSHARE,SUPPORTS_NEW_LUNINFO2,feature x0800,feature x2000,feature x40000,leftovers (0x400000) /dev/sdb /home/foltia/php/tv Drobo disk pack 36% full - ([‘No redundancy’, ‘Relay out in progress’, ‘no estimate yet ‘], 677) RedThreshold 95 YellowThreshold 85 lun size (GB) used PTFmt FStype: 0 17592 2914 GPT [‘EXT3’] ————————————————————————————-

↓ 冗長性構築中

[root@foltia drobo-utils]# ./drobom info ————————————————————————————- Drobo Name: Drobo disk pack Devices: /dev/sdb Time: Fri Oct 2 08:26:54 1970 ————————————————————————————- Configuration maxima: slots: 4, luns: 16, lunsize: 17 TB Capacity (in GB): used: 3042, free: 4924, total: 7966 protocol version: 0.11 SCSI emulation information: Vendor: TRUSTED Model: Mass Storage Revision: 2.00 /dev/sdb: bus=scsi4 channel=0 id=0 lun=0 (vendor=TRUSTED , version=30527) query slotinfo result: number of slots: 4 slot GB Model Status 0 2000 ST2000DM001-1CH164 [‘red’, ‘green’] 1 6001 WDC WD60EZRX-00MVLB1 [‘red’, ‘green’] 2 4000 HGST HMS5C4040BLE640 [‘red’, ‘green’] 3 2000 WDC WD20EZRX-00DC0B0 [‘red’, ‘green’] Firmware: 1.4.2 Revision: 1.254 ( 50341 ) built: May 18 2012,16:01:50 Features: NO_AUTO_REBOOT,NO_FAT32_FORMAT,USED_CAPACITY_FROM_HOST,DISKPACKSTATUS,ENCRYPT_NOHEADER,CMD_STATUS_QUERIABLE,VARIABLE_LUN_SIZE_1_16,PARTITION_LUN_GPT_MBR,FAT32_FORMAT_VOLNAME,SUPPORTS_DROBOSHARE,SUPPORTS_NEW_LUNINFO2,feature x0800,feature x2000,feature x40000,leftovers (0x400000) /dev/sdb /home/foltia/php/tv Drobo disk pack 38% full - ([‘No redundancy’, ‘Relay out in progress’, ‘no estimate yet ‘], 97) RedThreshold 95 YellowThreshold 85 lun size (GB) used PTFmt FStype: 0 17592 3042 GPT [‘EXT3’] ————————————————————————————-

foltiaのHDD容量が限界に近づいていた為、再セットアップした忘備録。 foltiaの録画領域はLVMなので、容量を拡張するともできたが、今後の管理を考えて、データ領域をDroboSGに格納する。

USBメモリに最新版のfoltiaイメージを書き込み。

参照 :http://aniloc.foltia.com/manual/appendix-usbflash-recovery.html

DroboSGのセットアップ

ext4でも動くっぽいし、最新バージョンではLUNSIZE=16いけるっぽい。(たぶん大丈夫・・・)

$ su $ git clone git://drobo-utils.git.sourceforge.net/gitroot/drobo-utils/drobo-utils $ cd drobo-utils $ drobom set lunsize 16 PleaseEraseMyData WARNING: lun size > 2 TiB known not work in many cases under Linux You asked to set the lunsize to 16 WARNING: Ready to destroy all you data. Continue? (y/n) y set lunsize to 16 TiB Done... Drobo is likely now rebooting. In a few minutes, it will come back with the new LUN size.

% sudo parted /dev/sdb GNU Parted 1.8.9 Using /dev/sdb Welcome to GNU Parted! Type ‘help’ to view a list of commands. (parted) mklabel New disk label type? gpt (parted) mkpart ext3 0 100% (parted) quit Information: You may need to update /etc/fstab.

% sudo mkfs -t ext4 -j -i 262144 -L Drobo -m 0 -O sparse_super,^resize_inode /dev/sdb1 dev/sdb1 mke2fs 1.41.14 (22-Dec-2010) Filesystem label=Drobo OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 33554432 inodes, 2147483639 blocks 0 blocks (0.00%) reserved for the super user First data block=0 65536 block groups 32768 blocks per group, 32768 fragments per group 512 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848, 512000000, 550731776, 644972544, 1934917632 Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information:done This filesystem will be automatically checked every 38 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override.

参照:http://sd.pot.co.jp/2011/07/08/using-a-drobo-on-linux-j

とりあえずマウント

$ mkdir /mnt/drobo $ mount -t ext4 /deb/sdb1/ /mnt/drobo/

各種データのバックアップ

・バックアップ先の作成

$ mkdir /home/foltia/php/tv/backup

・データベースダンプ

$ pg_dump -Fc foltia > /home/foltia/php/tv/backup/DBDump.dat

・録画ファイルとバックアップデータのコピー

$ rsync -cav /home/foltia/php/tv/ /mnt/drobo/ » ./rsynclog

-cオプション付けて何度か繰り返すと、コピー失敗してても修復可能。 コピー中録画が始まったりするのでデータベースダンプとrsyncを何回か繰り返した…と言うか回した

#!/bin/bash while true do isAlive=ps -ef | grep " rsync " | grep -v grep | wc -l if [ $isAlive == 0 ]; then rsync -a -v -h --update /mnt/drobo/ /home/foltia/php/tv >> ./reverseLog& fi sleep 60 done

rsynclog見て変更なさそうだったら完了。

—ここまでは録画を止めずに実行出来るが、以降は録画と同時進行はできないので、録画スケジュールを確認して実行。

foltiaの再起動

元HDDを外し、作成したUSBメモリで再起動する。

セットアップウィザード

ブラウザで、 http://foltia.local/setupwizard/ にアクセスして、セットアップウィザードを行う。

参照:http://aniloc.foltia.com/manual/chapter3-1.html

droboのマウント

適当に追加

$ vi /etc/fstab #/dev/tank/tv /home/foltia/php/tv ext4 rw,suid,dev,exec,auto,user,async,noatime 1 1 /dev/sdb1 /home/foltia/php/tv ext4 defaults 0 0 $ mount -a

DB設定のリカバリ

$ dropdb foltia $ pg_restore -C -d postgres /home/foltia/php/tv/backup/DBDump.dat

ブラウザで切り替わり確認

個人的な復元メモ ・smb.conf ・hamachi ・iptables ・シェルスクリプト ・ユーザー/ルートのパスワード変更 ・.bashrc

トラブったときの切戻し

・基本的に、元のシステムは修正していないため、移行がうまくいかなかった場合、元のハードウェア構成に戻せば問題ないハズ。