バックアップは大切
2008 / 06 / 09 ( Mon )
過去のノートを眺めていたら、1年ほど前にテープの記憶容量をまとめたメモが出てきたので、若干古い情報ですが、後半の方にまとめておきます。
最近は、USB接続のドライブやLTO4（圧縮時:1.6TB）とかも出てきて、テープの規格はまだまだ進化し続けるのかなと思います。ストレージの大容量化に伴い、安価で構成できるディスク装置へのバックアップを導入される所が多くなりましたが、やはり信頼性の面ではテープへのバックアップにはかなわないと思います。もちろん、バックアップ管理をちゃんとした上での話しですが…。
テープへのバックアップにしろ、ディスクへのバックアップにしろ、ストレージの肥大化に伴いバックアップの重要性を改めて考えさせられます。
最近は、USB接続のドライブやLTO4（圧縮時:1.6TB）とかも出てきて、テープの規格はまだまだ進化し続けるのかなと思います。ストレージの大容量化に伴い、安価で構成できるディスク装置へのバックアップを導入される所が多くなりましたが、やはり信頼性の面ではテープへのバックアップにはかなわないと思います。もちろん、バックアップ管理をちゃんとした上での話しですが…。
テープへのバックアップにしろ、ディスクへのバックアップにしろ、ストレージの肥大化に伴いバックアップの重要性を改めて考えさせられます。
今でもRAIDとバックアップを同等に考える人が稀にいます。RAIDにしているからバックアップは必要ないなんて事は絶対にありません。
RAID構成にしているからといって、その中に入っているデータは絶対に無くならないということはありません。それは、RAID1でもRAID6でもRAID5でも同じです。
RAID1でディスクが2台一気に壊れないという保証はありません。RAID5でディスクが1台壊れてリビルド中に2台目が壊れるなんてしょっちゅうです。RAID6でディスクが3台同時に壊れる可能性だって0ではありません。
同一筐体にRAIDグループを2つ構成して、1つをメイン、1つをバックアップ用に確保する人もいますが、これもバックアップと呼ぶには不十分な構成です。
例えば、こんな感じで、1つのコントローラで2つのRAIDグループを構成し、rsyncのようなコピーツールを使用してRAIDグループ1からRAIDグループ2に定期的にコピーするような構成です。
確かに、RAIDグループ1のHDD1とHDD2が同時に壊れて、RAIDグループ1のデータがすっ飛んだときには、RAIDグループ2からデータを取り出すことが可能となりますが、RAIDコントローラが壊れたときや不具合が発生したとき、装置の電源が壊れたときには、どうしようもありません。運の悪いときには、2つのRAIDグループのRAID情報が吹っ飛んでデータが1も2もきれいになくなっちゃったなんて事にもなりかねません。
Disk to Diskのバックアップ目的で、バックアップ用ストレージを用意する場合は、筐体はメインデータ用とバックアップデータ用に必ず分けるようにしましょう。
データが消えたら、本当に悲惨です。バックアップを考える際には慎重に。
わざわざ表にまとめて載せましたが、この↓ページの方がちゃんと書いてあります。(^^;
http://www.maxell.co.jp/products/care_comtape/proper/proper4.html
サーバー構築・運用に関わるプロフェッショナルの方々の体験談や解説がいっぱい集まった、
こちら↓のページも合わせてご参照ください。
RAID構成にしているからといって、その中に入っているデータは絶対に無くならないということはありません。それは、RAID1でもRAID6でもRAID5でも同じです。
RAID1でディスクが2台一気に壊れないという保証はありません。RAID5でディスクが1台壊れてリビルド中に2台目が壊れるなんてしょっちゅうです。RAID6でディスクが3台同時に壊れる可能性だって0ではありません。
同一筐体にRAIDグループを2つ構成して、1つをメイン、1つをバックアップ用に確保する人もいますが、これもバックアップと呼ぶには不十分な構成です。
例えば、こんな感じで、1つのコントローラで2つのRAIDグループを構成し、rsyncのようなコピーツールを使用してRAIDグループ1からRAIDグループ2に定期的にコピーするような構成です。
確かに、RAIDグループ1のHDD1とHDD2が同時に壊れて、RAIDグループ1のデータがすっ飛んだときには、RAIDグループ2からデータを取り出すことが可能となりますが、RAIDコントローラが壊れたときや不具合が発生したとき、装置の電源が壊れたときには、どうしようもありません。運の悪いときには、2つのRAIDグループのRAID情報が吹っ飛んでデータが1も2もきれいになくなっちゃったなんて事にもなりかねません。
Disk to Diskのバックアップ目的で、バックアップ用ストレージを用意する場合は、筐体はメインデータ用とバックアップデータ用に必ず分けるようにしましょう。
データが消えたら、本当に悲惨です。バックアップを考える際には慎重に。
| 種類 | 記憶容量 (非圧縮時) | 記憶容量 (圧縮時) | 互換性 |
|---|---|---|---|
| Travan40 | 20GB | 40GB | Travan NS20(R) |
| DDS4 | 20GB | 40GB | DDS2(RW) DDS3(RW) |
| DAT72 | 36GB | 72GB | DDS2(RW) DDS3(RW) DDS4(RW) |
| DLT VS80 | 40GB | 80GB | DLT4000(R) |
| DLT VS160 | 80GB | 160GB | DLT1(R) DLT VS80(R) |
| Super DLT | 160GB | 320GB | DLT8000(R) DLT7000(R) DLT4000(R) DLT1(R) DLT VS80(R) |
| LTO1 | 100GB | 200GB | |
| LTO2 | 200GB | 400GB | LTO1(RW) |
| LTO3 | 400GB | 800GB | LTO1(R) LTO2(RW) |
わざわざ表にまとめて載せましたが、この↓ページの方がちゃんと書いてあります。(^^;
http://www.maxell.co.jp/products/care_comtape/proper/proper4.html
こちら↓のページも合わせてご参照ください。
大容量になるとバックアップが時間内に終わらないケースも増えてきます。
そうした場合は、筐体間でレプリケーション。そのお金が用意できない場合は、筐体内で複数世代のボリュームコピーを持つ構成でもいいのかな（仕方ないかな）と思っています。
EMC SnapViewだと8世代持てるので、毎日異なるボリュームと同期取る構成も可能です。
＃ ストレージベンダーのレプリはライセンス費用も構築費用も高いんですよね。1000万〜みたいな。
＃ NetAppくらい簡単だと提案も採用もしやすいんですけど
そうした場合は、筐体間でレプリケーション。そのお金が用意できない場合は、筐体内で複数世代のボリュームコピーを持つ構成でもいいのかな（仕方ないかな）と思っています。
EMC SnapViewだと8世代持てるので、毎日異なるボリュームと同期取る構成も可能です。
＃ ストレージベンダーのレプリはライセンス費用も構築費用も高いんですよね。1000万〜みたいな。
＃ NetAppくらい簡単だと提案も採用もしやすいんですけど
by: miz * 2008/08/23 11:34 * URL [ 編集] | page top↑
| ホーム |
