C.a.T!

融通利かない娘たち。

録画サーバをfoltiaにしてはや3年運用していますが、構築当時ケチって安いディスクを使ったせいかエラーセクタが出てきて怪しい。というか、rsyncでデータ吸い出そうとしたら、リトライしまくってリードオンリーにされてしまう。更に、最近、放送の仕様が変更されたり、一部ラジオの録音が失敗したり、foltiaバージョン4を使っているが故の問題も起き始めた。バージョン4にしていたのは、バージョン4から５以降へのアップグレードは、オンラインでできなくて、再インストールしないといけない仕様になっていたことがネックでして。録画の隙間を縫ってメンテするのめんどい、と思いバージョン６まで放置してしまいました。ディスクも壊れそうなので、ようやく重い腰を上げたわけです。その時の移行ログを残して置こうと思います。

今回、ディスクが怪しいことと、公式には互換性を保証していないバージョン間でデータを移行するため、古いデータはそのままの形で残しておきたく、ディスクを新たに購入しました。古いディスクは安くて信頼性が低いというのもあります。今回は、WD REDにしておきました。

さて、まずどうやって現在の録画データを取り出すかです。幸いPOSTGRESデータベースのデータはダメージがないので、そっちは大丈夫。問題は録画データで、rsyncで取り出そうとしたものの、エラーでうまくいきません。途中で止まる。ddrescueだとエラー部分を避けてダンプしてくれるらしく使おうとしたけど、現在の録画を収めているパーティションサイズ以上のディスクがない。このために買うのもな、と思うので。そこで、foltiaではｘｆｓが使われているようだったので、xfsdumpを試して見ることにしたところ、うまくいきました。エラーの部分は諦めてダンプしてくれるようです。

コマンド的には以下のような感じ。

[code lang=”shell”]
xfsdump -l 0 -f /mnt/backup/backup.dump -L 20180630 -M FOLBACK -v verbose /home/foltia/php/tv
[/code]

/home/foltia/php/tv が、foltiaで決まってる録画データが入るディレクトリですね。これを、/mnt/backup/backup.dump ファイルにダンプするコマンドです。20180630はラベルで、同じダンプファイルに複数のバックアップを作るときに識別するよう。FOLBACKはメディア名らしい。まあ、これは適当に付けとけば問題ないです。-l オプションは世代数。xfsdumpは、差分バックアップを取れて、世代を指定して戻したりもできるのです。優秀。エラーがあるファイルのあたりで、リードが遅くなったりしてましたが、一応ダンプは正常終了しました。多分、エラー部分のファイルは使うことはできないと思う。

録画データが取れたらデータベースもバックアップしますが、その前に固定IPでサーバを運用しているときは、DHCPに設定しなおしてから以下のバックアップをとったほうがよいそうです。これは、マニュアルにそう書いてあったのに従っただけで、固定IPのままやるとどうなるのかは知らない。DHCPにして再起動したら、古いデータで必要そうなものをバックアップしておきます。

[code lang=”shell”]
pg_dump -Fc foltia > /mnt/backup/foltia-DB-Dump.dat.MP4
service postgresql stop
cd /var/lib/pgsql/
tar cvJf /mnt/backup/databasedir.tar.xz ./data/
[/code]

これで、前の環境からのバックアップは完了。念の為 /etc ディレクトリとかもバックアップしておきましたけど、これは保険なので。

この状態でディスクを載せ替えます。例によってホコリだらけで発狂しそうになる。でも、ディスクはケーブル抜き差しいらないタイプのマウンタなので、比較的楽。

さて、次は新しいfoltia環境をインストールします。インストールは、公式ページからダウンロードできるISOファイルをUSBディスクに焼いて、そいつからブートしセットアップします。このへんは、公式のマニュアルどおりです。普通に起動できるとこまでやりきります。

起動できるようになったら、foltiaにsshします。設定・管理にあるターミナルエミュレータでもいいですけど。まず、foltiaユーザとrootのパスワードは変えておきましょう。次に、データベースを戻します。ここが一番心配なところだったのですが、一応データは戻っている模様。データファイル毎戻す手順が公式ではデフォルトとして書かれていましたが、私はpg_restoreで戻しました。

[code lang=”shell”]
dropdb foltia
createdb -T template0 foltia
pg_restore -Fc -C -d foltia /mnt/backup/foltia-DB-Dump.dat.MP4
[/code]

あと、foltiaのバージョン情報も戻してしまってるので、そこは手動で更新。また、プロダクトキーもアップグレードライセンスのものにアップデートしておきます。

[code lang=”shell”]
psql foltia -c "UPDATE foltia_config set value = ‘6.0.9’ WHERE key = ‘firmwareversion’ "
psql foltia -c "UPDATE foltia_config set value = ‘XXXXXXXXXXXXXXXX’ WHERE key = ‘productkey’ "
[/code]

これで、再起動をかけてWebインタフェースにアクセスしてみると、一応古い録画データや予約リスト等は表示されるようになった。録画ファイルやキャプチャ画像がないので、当然、画像や録画リンクはNot Foundですが。

ここまでできたら、固定IPを使う場合は固定IPを設定して再起動。あとは、録画ファイルを戻して再起動。

最後に、録画ファイルを戻します。

[code lang=”shell”]
mv /home/foltia/php/tv/* /mnt/backup/newtv/
xfsrestore -f /mnt/backup/backup.dump -L 20180630 -v verbose /home/foltia/php/tv/
[/code]

あとは、次の録画時間が来るまでにリストアが終わることを祈って、数時間待つ。

リストアが終わったら、録画リストなどが正常に表示されるか確認。録画が再生できるかも確認します。無事再生できたら一応データ移行は問題なし。

それで、録画を試してみると、問題発生。どうも、MP4変換ができない。これは、昔あったパターンだ。ffmpegが落ちている。

[code lang=”shell”]
foltia kernel: ffmpeg[2456]: segfault at 0 ip 00000037a740a47c sp 00007ffffa38d8e8 error 6 in libswresample.so.0.18.100[37a7400000+16000]
[/code]

Oh…さて、どうするか。ここによると、ffmpegのアップデートに失敗するからとか書いてある。アップデートすればよいのか。といっても、yumでアップデートしても最新版のようだ。削除してインストールしなおしたら、なんか古いやつ入るし。やばい。ということで、リポジトリを選ばないとダメぽい。元々、atrpmsリポジトリとかから入れられたぽいが、繋がらないぞ。ということで、とりあえずNux Dextopから入れた。

[code lang=”shell”]
rpm –import http://li.nux.ro/download/nux/RPM-GPG-KEY-nux.ro
rpm -Uvh http://li.nux.ro/download/nux/dextop/el6/x86_64/nux-dextop-release-0-2.el6.nux.noarch.rpm
yum install ffmpeg
[/code]

とりあえず、MP4変換はうまくいっているようだ。ただ、後のfoltiaアップデートで、またおかしくなるかもしれないな。

とまあ、順調というわけには行きませんでしたが、意外とデータベースの移行は順調だったのでなんとかなりました。

—–