NASの主要要素がストレージであることはTurboNASがいくら多機能であろうとも変わらない。だが、そのストレージを構成するHDDは駆動部品を持つ精密機械であり、耐衝撃性は高くない。容量が増えれば増えるほど、その重要性は増していくが、同時に壊れやすさ、データを失ったときの被害も増す。HDDのトラブルに備えるのは必須だ。
だが、その対策も1つで済むわけではない。コストや運用形態、リカバリに必要な時間、許容される復元ポイントまでの時間などに応じて、いくつかの方法を組み合わせてリスク対策を行わなければならない。一般には「データバックアップの頻度が高いがデータロストの危険性も高いもの」と「データバックアップの頻度は低くなるがマスターと同時にデータロストする可能性が低いもの」を組み合わせて運用する。
まずはHDD単体でのトラブルに備えたディスクの冗長化、つまりRAIDだ。TurboNASでは搭載ベイ数、搭載CPUにもよるが、冗長性のあるボリューム構成としてRAID1/5/6/10に対応する。RAID5は搭載ドライブ数-1の利用可能容量を持ち、1台がクラッシュしてもデータが復元可能であるため、以前はCPUの処理速度が高速であればバランスのとれた構成だと目されていた。だが、クラッシュ後のリビルド中にもう1台がクラッシュしてデータがロストする場合があり、現在は利用効率が下がってもより冗長性の高いRAID1/6/10が選択されることが多いようだ。
なお、RAID 10はミラーリングであるRAID 1のボリュームでRAID 0(ストライピング)を組むという、冗長性と高速性の両方を目指したもので、最小構成の4台で構成した場合、組み合わせによっては2台クラッシュするとデータがロストしてしまう。RAID 6も最小構成4台、利用効率50%でRAID 10と同じではあるが、任意の2台のクラッシュに耐えることができる。その半面、処理が重くなるため書き込み速度は低下しやすい。
RAID構成はあくまで「ディスクボリュームの信頼性を上げ、故障率を下げる」ためのものだ。そこからどのようにデータ保全していくかを考えなければならない。そのための機能としてTurboNASに用意されているのがリモートレプリケーションだ。
要はrsyncによって差分更新を行うための機能で、スケジューリングされたタイミングに従って2台の間で同期を取ることができる。スケジュールは毎日、毎週、毎月1回で指定するが、例えば同じフォルダに対して毎日6時のジョブと毎日18時のジョブを設定すれば12時間ごとのバックアップも設定できる。
さらにファームウェア3.4以降であればRTRR(リアルタイムリモートレプリケーション)を利用することが可能だ。これはリアルタイムに同期をとるもので、rsyncとは別のサービスとなる。リモート側ではデータ圧縮やバイトレベルでのレプリケーションなど、詳細な機能を利用できるRTRRサーバを起動させておくが、ファームウェア3.4がリリースされていない旧モデルのTurboNASなどではFTPサーバで代用することもできる。
このようなTurboNAS間のバックアップによって、1台がクラッシュしてもデータは保持される。マスター側がクラッシュした場合、設定スケジュールによっては1日以上のロストが発生することになるものの、バックアップ側をマスターの代わりに使用することで業務の継続は可能だ。だが、災害の種類によっては同じオフィスに設置しているとマスター/バックアップの両方が物理的に破壊される場合もある。
そのような災害に対する対策としては、物理的に離れたところにバックアップを設置し、VPNやSSHなど通信経路を暗号化した上でリモートレプリケーションを行う。支社や支部がある場合は双方でバックアップを取り合うように運用すればよい。一方、SOHOや個人事業主、趣味でNASを導入している場合は、いっそのこと実家に置いてもらうというのも手だろう。もちろん、管理者権限を引き渡さず、1ユーザとしてのみの権限を付与する、バックアップフォルダは閲覧も許可しない、などのルールは必要だ。遠隔地にレプリケーションするということは情報流出のセキュリティリスクが2倍になるということも意識する必要がある。
そのほか、レプリケーション先にAmazon S3、ElephantDriveを利用することもできる。こちらは容量での従量課金なので、対象フォルダを必要最小限にしぼるなどの対応をしておかないと高額の請求となりかねないので注意したい。もし、企業でデータセンタとハウジング契約をしているのであればそこに設置するのも手だ。
Copyright © ITmedia, Inc. All Rights Reserved.