「foltia ANIME LOCKER」はその製品名どおり、アニメ録画において最強の環境であると同時に、PT3などに代表される、いわゆる「TS抜き」環境でのもっとも導入・運用が容易な録画・再生環境といえるでしょう。
それ故に、foltiaマシンにはついついハードワークを強いることとなり、録画データの蓄積も多くなってきます。
そうなってくると、もしfoltiaマシンのHDDが壊れたら?という状況をいよいよ想定して対策を取っておきたいもの、というわけで、転ばぬ先の杖、または転びかけた場合の緊急対策、のバックアップです。
■実は私のfoltiaマシンは瀕死の状態だった。
気がつけばVer.2.0から3年以上休まず稼働を続けるfoltia ANIME LOCKERですが、ディスク不良による動作障害が起こり始めました。
録画中にディスク障害部分を踏むと録画エラーになるだけでなく、PostgeSQLが異常停止する事態にもなり、これは再構築が緊急の状態、ということに。
まずは再起動すればサーバが稼働できているウチにバックアップをとりましょう。
■オンラインマニュアル
メーカーサイトでは以下のページにバックアップ&レストアの記載があります。
foltia ANIME LOCKER : バックアップとレストア
基本はこちらを参考にしつつ、できるだけお手軽に出来る方法で対応します。
■バックアップ先は「低価格NAS」を利用
もちろん、USBの外付けHDDなどで通常は全く問題ないのですが、私の場合は以前から持っていた低価格NASをバックアップ先に使用しました。
利用したのはNETGEARの「ReayNAS RN102」というHDDレスのモデル。
これに3TBのHDDを2基取り付けてあります。
こちらのモデル、別に高速なCPUを搭載している訳でも目立った機能があるわけでもありませんがひと通りのことができて価格も1万円台前半で購入できるため大変お手頃です。またfoltiaのバックアップ先として考える場合、共有方法で「NFS」が使用できるのも有り難いところです。
これに価格の下がっている3TBのHDDを組み合わせることで大変コストパフォーマンスの高いNASを作ることができます。
なお、HDDを2基搭載した場合、自動的にミラーリング(RAID1)の構成になりますが、どうせバックアップ専用で使うつもりなので容量重視でストライピング(RAID0)で再構成し3TB+3TBの容量を確保する設定にしています。
またバックアップ用の共有フォルダは通常のSMB(Windos用)以外にNFSも設定します。
NFSの設定ではfoltiaサーバのIPアドレス(私の場合172.19.2.30)にRead/Write権限をわりあてます。
NETGEARの場合、NFSのパスは NASのIPアドレス:ストレージ名/共有名(たとえば今回の場合「172.19.2.15:backupdisk/backup」)となります。
■foltiaでの設定。rsyncによるバックアップ
作業はfoltiaマシンのコンソールで行います。もちろん、SSHでログインしても問題ありませんが、今回はバックアップを直接実行するためあえて本体にキーボードとモニタを接続して作業を行いました。
コンソール上でrootでログインします(ユーザー名 root、パスワード foltiaroot)。SSHの場合はまずfoltiaユーザでログインしてsuする必要があります(オンラインマニュアル参照)。
今回は /mnt の下に backupというディレクトリを作成し、ここへNASの共有フォルダをマウントします。
login: rootPassword: foltiaroot ←非表示[root@foltia foltia]# mkdir /mnt/backup[root@foltia foltia]# mount -t nfs 172.19.2.15:/backupdisk/backup /mnt/backup[root@foltia foltia]#
また、あらかじめPostgreSQLのダンプをNASに書き出しておきます。
[root@foltia foltia]# sudo -u foltia pg_dump -Fc foltia > /mnt/backup/db/foltia-DB-Dump.dat.MP4[root@foltia foltia]#
そのうえで、foltia上の録画データをNASへバックアップを行います。
私はM2TS形式の録画データはバックアップから除外することにしました。
あらかじめ、foltiaの画面上でM2TSデータをすべて削除していても作業中のものなど「.m2t」形式のファイルが残っている場合があり、これらの有無でバックアップの時間にも大きく影響するため、コマンドで.m2t形式を除外することにします。
バックアップにはいくつかの手法が考えられますが、今回はrsyncコマンドを使用します。
[root@foltia foltia]#[root@foltia foltia]# rsync -av --exclude='.m2t' /home/foltia/php/tv/ /mnt/backup/tv/sending incremental file list./0x1653650_isotmp3127-268-20151116-2200.aac3127-268-20151116-2200.aac-AGQR.MP4-1.localized/img/-1.localized/img/-1--20151116-2330-23/-1.localized/img/-1--20151116-2330-23/00000001.jpg-1.localized/img/-1--20151116-2330-23/00000002.jpg-1.localized/img/-1--20151116-2330-23/00000003.jpg.....~~~~mita/mita/3127-268-20151116-2200.aac.flvsent 3633374612 bytes received 44449 bytes 1683307.42 bytes/sectotal size is 2417800195363 speedup is 665.43rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1039) [sender=3.0.6][root@foltia foltia]#
私の場合、foltiaのデータ領域に使用していた3台のHDDのうち、1台に障害が起きており、いくつかの録画ファイルが壊れている状態でしたので、上記のように、コピーできなかったファイルがある場合はエラーログが残ります。 通常であれば問題なくコピーできると思います。
またrsyncでバックアップを取る場合はバックアップ元およびバックアップ先のディレクトリ指定で最後に「/」を付けるのを忘れないようにします。この「/」を付けることで「指定したディレクトリ以下をすべて」同期させるという意味になります。
ちなみに初回のバックアップ容量が多い場合、バックアップに1日以上の時間がかかる場合があります。
マシンに余力があれば、rsyncによるバックアップを取りながらでも通常どおり録画・MP4エンコードを行うことが可能です。
ただその場合、rsync稼働中に録画したデータはバックアップが取れていないため、初回バックアップ終了後に増分を取る必要があります。また同様にPostgreSQLのダンプも再取得します。
増分はrsyncのオプションに「u」を追加し、「-auv」とすることだけです。
[root@foltia foltia]# sudo -u foltia pg_dump -Fc foltia > /mnt/backup/db/foltia-DB-Dump.dat.MP4[root@foltia foltia]# rsync -auv --exclude='.m2t' /home/foltia/php/tv/ /mnt/backup/tv/
日常的にバックアップを取る場合は上記の増分を都度手動で取るか、cronに設定することで定期的に自動で実行するように指定することで対応できます。
rsyncではフォルダ構造ごとバックアップ元と同期をとりますので、バックアップをNASにした場合、SMB共有でPCからバックアップ先を参照するとができます。またレストアする際もrsyncを逆に走らせればいいわけですが、こちらは続きで記載します。