RAID箱買いました ♪

HDL2-G のRAID崩壊から得られた教訓。

１．ファンレスな機器を暑いところに置かない

２．システム領域とデータ領域は分ける

３．データ領域単体でRAID1化しておく

というわけで、恥ずかしい名前のRAID箱を買ってしまいました（^^;）

センチュリー 裸族の二世帯住宅 CRNS35EU2

• 出版社/メーカー: センチュリー
• メディア: エレクトロニクス

USB接続とeSATA接続ができるすぐれっこです ♪

LAN接続できる子もいたのですが、やめておきました。

これなら、Time CapsuleにUSB接続してもいいですし、

Macに直接でもつなげられます。

と。

買ってから、eSATAを調べてみると、

すごいじゃないの！

USB 2.0の転送速度：480Mbps

に対して、

eSATA の転送速度：3Gbps

文字通り桁違いなeSATAにひとめぼれです（*^^*）

eSATAでつなぎたくなってきてしまいました。。

なにせ、高速なものに弱いので（^^;）

タグ：RAID1 eSATA 転送速度 高速

読めなくなったHDDの修復

さて、HDL2-Gから取り出したHDD ↓ ですが、

マウントしようとしても

Bad magic number in super-block while trying to open /dev/hdc6

などとおこられてしまいます。

magic number・・・さて、なんでしたっけ？（^^;）

よくわかりませんが、とにかく、super-blockに書き込まれている

magic numberが違ってるから、だめよーん。と言われているようです。

Webで検索してみると、fsckコマンドなどで、じみーちに修復するしか

なさそうです。

fsckを走らせたりしてみましたが、案の定だめです。

それもそのはずで、RAIDで構成されているので、無理もありません。

2010.4.28追記

当時はよく知らなかったのですが、これはLinuxでソフトウェアRAIDを構成した際に

変更されるsuper-blockのことだと思われます。

mdadmで再度RAIDを構成してあげてから、

mdadm --misc --zero-superblock /dev/sd[abcd]1

などとするとsuper-blockを初期化できます。。

もういちど、HDL2-G にもどして、起動してみます。

前回は、緑色のステータスランプが明滅して、システムが起動しませんでした。

が、なんということでしょう〜♪

赤ランプが明滅しています！

試しに、ブラウザからアクセスしてみます。

わっ！やった。つながりました。。

そして、、、

状態：崩壊

HDD1：接続済

HDD2：未接続

ですって。

RAID1を２台のHDDで構成している場合って、１台が故障しても

残りの１台でサービス継続されるのでは。。。？

ブラウザの管理画面にはつながるようになりましたが、

依然、ファイル共有サービスは復活しません（^^;）

HDD2が未接続ということは、故障していない同じ型番のHDDを

入れてあげれば、リカバリされるのでしょうか？？

とりいそぎ、Amazonで調達です。

Seagate 3.5インチ内蔵HDD 500GB 7200rpm S-ATA/300 32MB ST3500320AS

• 出版社/メーカー: Seagate
• メディア: エレクトロニクス

とおもいきや、欠品です。

ということで、型番で検索して、いちばん安いサイトから購入。

残念ながらHDDの修復とはならず、１台は故障が確定です（^^;）

もう１台は、購入したHDDとペアでRAIDを再構築するために、

大切にとっておきます ♪

タグ：linux HDL2-G Raid RAID1 RAID崩壊

MacBook Pro の高速化？への道のり の巻２

やっぱり起動時間がお気に召しません。。

というわけで、今度は、

「「移行アシスタント」からリストアする方法」

で、リカバリしてみたいと思います☆

例によって、例のごとく。

DVDからSnow Leopardのクリーンインストールです。

そんなににらまなくても、、（^^;）

Macにも大分慣れてきました。

Mac歴はちょうど１ヶ月ほどですが。。

はい、再インストールですが、約３０分でチンです。

ユーティリティーから「移行アシスタント」を起動します。

この時、初めて知ったのですが、設定情報だけではなく、

・インストール済みのアプリケーション

や

・保持していたファイル

など

一切合切移行してくれるようです。

Time Capsule上のディスクを選択します。

移行する項目を選択します。

□ユーザー

□アプリケーション

□設定

□ファイルとフォルダ

また、賢いところが、おそらく、現状とバックアップファイルとの

差分を計算した上で、移行するために必要なディスク容量を計算し、

提示してくれます。やさしいです ♪

全部移行で、約４４GB。約１時間かかりました。

さて、再起動。

ダウンロードは🎥こちら

こんなものですかねー。

と、しばらく使っていたところで、トラブル発生（^^;）

メールの送受信ができないのです。

調べてゆくと、どうも、パスワードが保存されていな模様。

パスワードは、キーチェーンアクセスなるところに保存されるべき模様。

しかしです。

メールのログインについてのキーチェーンの情報を見ると、

ちゃんと保存されているようです☆

ちょっと検索すると、パスワードの保存関係がおかしいときには、

１．キーチェーンアクセスの Keychain First Aidから修復を行う

２．ディスクユーティリティーからディスクのアクセス権の修復を行う

というコメントが多数見られましたので、両方ともに実行！

う〜ん。

実行しましたが、パスワードが保存されないようです。

ここで、

３．いったん、キーチェーンを削除し、再度キーチェーンを登録しなおします

で再度トライ。

キーチェーンアクセスの下にある「＋」ボタンをぽちっとやって、

キーチェーンの新規追加を行います。

なな。ところがです。

キーチェーンのアクセス制御にMail.appが登録できません！

正しくは、

「アクセスを許可する前に確認」で

「これらのアプリケーションによるアクセスを常に許可：」

のアプリケーションとして、Mail.appが登録できないのです。

他のアプリケーションはどれでも登録できるのですが、、

ここで、

「この項目の使用をすべてのアプリケーションに許可」と

すると、Mail.appのパスワード欄に●●●●●●●●●●●●が復活！

そして、メールの送受信もできるように。。

ですが、ちょっと、セキュリティ的に抵抗があります。。

海の向こうのサイトも含めて調べていると、どうやら、これは

Mail.appの古くからあるバグだとするご意見がみうけられ、

あきらめることに。。。。

どういう方向で、あきらめたかというと、、

ご想像のとおり、このリカバリ方法での使用をあきらめることに。。。

つまり、

そうです。

またクリーンインストールすることに。

つづく。

タグ：MAC MacBook キーチェーンアクセス リカバリ 再インストール Mail.app Snow Leopard クリーンインストール