投稿

ラベル(ディスクユーティリティ)が付いた投稿を表示しています

メールサーバの移行

イメージ
 自前のメールサーバを停止 これまで、自ドメインのメールサーバはVPS上に構築していた。 ・Ubuntu Server ・Postfix ・Dovecot ・spamAssassinと、BlackListの利用 Spam対策を行ってきたし、サーバ上でメールをトリガーにして各種プログラムを動かしたりしてきた。 メールサーバのメンテナンスは結構面倒くさくて、  ・Disk容量のチェック  ・不正アクセスのチェック  ・各種セキュリティパッチの適用 など、手間がかかる。 そこで、外部のサーバを利用することに…。 結構安くて使い勝手の良さそうなのが、「さくらのメールボックス」 3年契約で、3070円とな…。  メールアドレスは自分のだけなので、20GBまで利用可能!  (Gmailより大きいねぇ) ということで、早速契約。 アカウント設定を行って、既存のDNSを書き換える。WHOISも書き換えて完了。 SMTPとIMAPが利用できればOK。 ちょうど、GoogleがSPF設定していないと受信しないし、DKIMおよびDMARCに対応していないメールを弾くようになったので、対応しているのを確認。 さくらサーバ自体は、これまでお客さんのサーバとして何件も利用しているので、利用方法も難しくはない。  Webメールにも対応しているので、いざという場合にもありがたい。 ということで、各メールソフトの設定を変更。  PC(常時使用する3台)とタブレット、スマートフォンと台数は多いがそれ程手間はかからない。 問題は、旧サーバで送受信したメールの履歴だけれど、これはThunderbrdを使ってローカルに保存することで回避。  本当は、サーバtoサーバでMailboxに残そうとも考えたんだけど、古いメールはそれ程必要ないし、ローカルにバックアップしてあれば凌げるので、良しとする。 移行時にDNSの反映で若干時間がかかったものの、問題なく送受信できるのを確認して、作業完了。  これでメンテナンスの手間が減るので、安いもんです。

iMacの調子が悪くなった(修復完了)

イメージ
やっと動くようになった 土曜の夜に、仕事でskypeを2時間ほど行って、ミーティング終わってからの調子がすこぶる悪くなった。 でもって、 リカバリーモードで、ディスクのチェックを掛けた のが、昨日。 しかも、昨日のブログは、携帯で書いているので、今見ると読みにくいわ…。 昨日、仕事から戻ると、バックアップディスクのチェックは完了していて、問題なし。 OK。 これで安心して、本体のHDDが触れる。 続いて本体のHDDをチェックする。 しばらく待つと、エラーが出ます。修復かけます。直りません。 これを、数回繰り返したが、結局、起動することは出来ず。 ディスク自体が逝っているのか、理論的に逝っているのか現時点では分からない。 S.M.A.R.T.情報でもすぐに見られれば、良いのだが…。 最悪、HDDの交換かマシンの買い替えも視野に入れつつ、作業をすすめる。 まずは、フォーマットをかけてみる。 この時点で、ダメならHDDを諦める。→問題なし。 念のため、クイックなフォーマットではなく、実際に0埋めをさせてみる。 これは多少時間がかかるだろうと思いつつ、実行→問題なし。 ならばと、TimeMachineのバックデータを元に書き戻しを実行。 ぐはぁっ、14時間かよ…。 ということで、放置しつつ他のWindowsマシンで仕事して寝た。 修復完了 朝起きたら、まだ4時間かかると出ていたので、もう少し放置。 で、9時半頃に完了。本当に10時間以上掛かっているゎ。 やっと、ログイン画面を拝むことが出来た。 動作確認を兼ねて、ブログ書き中。 今のところ、正常に動作している感じ。 ただ、key_chainなどが消えているっぽくて、やたらとパスワードを入力させられる。 バックアップ対象に入れていないDownloadフォルダは、すっかり空だけどまあいいや。 と思って確認していたら…。 仮想マシンのイメージが消えていた orz あまりに容量がでかいので、対象から外していた。 少しやばい。 Windows用の開発ソースが、残っていないかも。 殆どはOneDriveに移行していたんだけど、その前のものが残っているかな。 別のWindo

タイムマシンのディスクがおかしい

イメージ
母艦に戻ってみたら 先のブログを書いて、風呂に入って、メインマシンのiMacに戻ってみると、エラーらしき表示が出ている。 「正しく取り出し操作を行わなかった…」とかなんとか。 って、ずっと繋ぎっぱなしだし、そもそも母艦であるiMacを操作していないのに…。 よく見ると、すでにディスクはunmountされていて、見えていない。 仕方なく繋ぎ直して、認識させる。 ひょっとして、壊れているとバックアップの意味が無いので、確認しておく。 「ユーティリティ」→「ディスクユーティリティ」を選択。 まずは検証を行ってみる。 一部、異常があるようだ。 カタログファイルがおかしいらしい。 完了するまでに、1時間18分となっているが、これを書いている間に、予想時間が2時間になっている。 こりゃ、いつになったら終わるかわからない事態。 とりあえず、朝まで放置しておくか。 検証を中止して、修復に入ることにする。すでにエラーが有るわけだし、どうせ検証が終わってから修復するわけなので…。 修復を開始→予想時間:18分って…。 この予想はまったくもってあてにならないですな。 もうこのまま放置して、今日は寝る。

バックアップが上手くいかない

イメージ
MacのTime Machineは秀逸 MacOSユーザなら、一度は聞いたことがある有名なバックアップソフトが「Time Machine」ですね。 標準で持っている、お利口なバックアップソフトです。 機能としては、差分バックアップを随時取ってくれて、過去の特定の時点のデータを取り出すことができるものです。 pdumpfs+GUIといった感じです。 pdumpfsはrubyで書かれたバックアップ用スクリプトで、ハードリンクを使ってファイルをコピーバックアップするツールです。windowsでも動作します バックアップ用のHDDを接続して、そのディスクにバックアップを取るよう設定すれば作業完了。 初回だけフルバックアップになるので、少々時間がかかりますが、あとはチョロチョロ動いて、それ程邪魔になりませんし、 イザという時の保険としては安心な機能です。 これまでに、何度も助けられています。 もちろん、OSの入れなおしだとか、Updateの失敗なんて時も、簡単に復旧できるので必須ツールです。 まだ、使っていない人は、早めに導入すべきですね〜。 急にエラーを吐いた 突然、Time Machineがエラーを吐いてきたので少々慌てました。 朝見ると、バックアップが完了できなかったというじゃないですか…。 ディスクフルな場合は古いものから、順次消していくはずなので、ディスクが一杯ということはないはず。 思い当たる節がない。 Time Machineの環境設定を確認すると確かに「!」マークが表示されている。 0:04分で失敗していることには変わりがない。 この状態では安心して、ファイルの変更など行えない。 特に仕事のデータなども、結構な頻度で書き換えを行っているので、元に戻せないのはもの凄く不便だ。 放置しておくわけにもいかないので、正常に動作するように直すしか無い。 「ユーティリティ」→「ディスクユーティリティ」を開き、該当のHDDを選択。 「ディスクを検証」を行えば、状況が分かるはず。 ポチッとな…。約20分かかるらしい。 1TBあると、それなりに時間がかかりますね。 同階層のリンクが正しくありません スレッドレコードの数が正しくありませ