投稿

ラベル(バックアップ)が付いた投稿を表示しています

メールサーバの移行

イメージ
 自前のメールサーバを停止 これまで、自ドメインのメールサーバは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の反映で若干時間がかかったものの、問題なく送受信できるのを確認して、作業完了。  これでメンテナンスの手間が減るので、安いもんです。

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

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

容量不足?

イメージ
久しぶりにiTunesを確認する Wi-Fiでの同期が可能になってから、有線で接続することもほとんどなく、iTunes自体も起動しっぱなしで、確認すらしていなかったのだけれども…。 久しぶりに確認してみると、どうもおかしい。 何がおかしいって、各デバイスの表示の下の方に、容量の利用状況が表示されるのだけれども、これが何故か全てその他に…。しかも容量不足と表示されている。 そんなはずはない。各デバイスで確認しても空き容量はある。 同期がうまくいっていないのか…。 有線で接続し、オプションなどを触ってみた。 写真の共有元をON/OFFしてみると、表示は少し変わり、なぜかAppのグリーンが表示される。 でも、容量不足はそのまま。 仕方ないので、同期してみる。 と、5秒後にはできませんでした…。って言われましても…。 やはり、おかしい。 さてどうするか…。 こんな時は、慌てずバックアップだ! ということで、「今すぐバックアップ」を実行。 そこで、試しに復元してみる。 時間はかかるものの、正常に表示されるようになった。 どうやら、iTunesのアップデートからおかしいのかもしれない。その前後で確認していなかったので、どの時点でおかしくなっているのか、現状では不明。 ちなみに、他のデバイスもチェックしてみると、iPhone4sが同様な症状。 こいつも、バックアップ→即復元で正常な表示に戻り、同期も可能になった。 なぜだろうか…。 ちょっと、気持ちが悪いけれど、とりあえず全てのデバイスが正常に認識されるようになった。 ふぅぅ~。

wikiのバックアップ

今日もバックアップねたで 個人的にメモやらアイデアなんかは、サクサクっと pukiwiki に記録する事が多い。 なにせ、マークダウンは書式が簡単だし、動きも軽くて使い勝手はなかなか良い。次々思いつくままに書いておけば、後で使いやすいと思うしね。 で、バックアップは簡単で、wikiフォルダ以下をコピーしておけばいい。 ただ、当初UNIXというかLinuxはEUCがメインだったこともあり、漢字を使用することから ページ名を16進表記に変換しているので、ファイル名を見ただけだと、何のページなのかが分からない点が少々残念。今は殆どがUTF環境なので、ファイル名を変換せずに使ってもいいかなぁと思う。 まぁ、そこはオープンソースなので、ソースを書き換えても良いのだけれど、使えない文字や過去のデータの扱いが厄介になるのは目に見えているので、思案しどころ。 単なるテキストデータなので、あっという間にバックアップ完了。ワードやエクセルなんかでは、味わえない心地よさを、みんなも知った方が良いのにと、心底思います。 最近はレンタルサーバでも、簡単に導入できるような所もあるので、使える環境なら使わなきゃ損だと思うよ…。 今夜は呑んだので、あまり難しい操作はせずに、これにて完了~。

facebookからメールが来た

イメージ
ダウンロードの準備ができました なんてタイトルのメールが届きました。手続きしてから、約1時間後です。すいている時間だったからこの程度ですんだのか、データが少ないからか…。その辺りは不明ですけど。 さて、メールに書かれたリンクを辿ると、ダウンロードのページに誘導。 アカウントの認証画面となり、パスワードを要求されます。少し慌てました。いつも、ブラウザに記憶させていてしばらく入力した覚えがないので。 まあ、無事通過です。すると本当のダウンロード画面が。 どんな形式なのかわくわくしながら、落とします。僕はあまりFacebookを多用していないので、サイズもそれほど大きくありませんでした。 ファイルはzip形式でした。とりあえず、解凍すると…。日付の記録されたReadme.txtと写真と、htmlファイル一式でした。 う〜む、これはこれで、意味はあるけど、facebook以外への利用は難しいし…。バックアップとして意味があるかと言えばどうなんでしょうねぇ。 htmlは当面利用できるものの、どうなんでしょうねぇ〜

SNSのバックアップ

イメージ
昨日は、ファーストサーバのシステムがいかれた話しから、自分のwikiやローカルマシンのバックアップについて、思う事をつらつらと書いたのだけれど、よくよく考えてみたらfacebookやblog、twitterのデータが消えてしまったと思うと、ちょっと寒気がする。 バックアップを取る そこで、SNS系のバックアップを取ってみる事にした。 今日は、facebookから。 ちゃんと、バックアップをダウンロードする仕組みが用意されてました。今まで、気にしていなかったから、見えてませんでしたゎ。 アカウント設定から「Facebookデータをダウンロード」を選択。 「アーカイブを設定」を押す。 すると、準備ができたらメールで連絡してくれるとな。 今の所「処理待ち」と表示されたままで、連絡が来るのを待つのみ。 ここまでの作業は、ほんの1分程度。 まずは、どんなデータ形式かも分からないので、連絡が来たらダウンロードして調べてみようと思う。あとは、ローカルのHDDに保存しておけば、一応は二重化できた事になるよね。差分で持って来れるのかどうかは、もう少し調べてみる必要がありそう。そうでないと、毎回大量のデータだったりしてちょっぴり困る。

ファーストサーバ障害に思う

IT関連ニュースを騒がす 20日に起きた、ファーストサーバの障害だが、利用していたユーザはとても面倒な状況に陥っている。しかも大手ときている…。 5万以上の顧客を抱え、うち8割が法人・官公庁関連というファーストサーバの大規模障害は、依然として被害の全容がつかめないままでいる。http://www.nikkei.com/article/DGXNASFK2600L_W2A620C1000000/  よく考えてみると、ユーザ数が多いからとか、法人・官公庁が8割とかいう一般の人が多分基準にするだろうという文言を説明に使う事が、如何に意味がないかという事を、証明してしまっている。 しかも内容を良く読むと、バックアップというよりはレプリケート(複製)しか取っていないんじゃないかと感じる。障害時の復旧に切り替えるための冗長システムであって、バックアップではないと思うだけど…。そうか、バックアップシステムを省略してるのか… まあ、詳しい解説やら状況は、おいおい出てくるとは思うけど、利用していた企業の担当者も慌てますわね。多少は…。 ところで何が問題か? まぁサーバがこけるなんて事は、別段珍しくもないし、ハードディスクがお亡くなりになる事も時々遭遇する訳で。システム管理者ってそのためにバックアップなり作業なりしていると思うんだよね…。 会社のWebを管理していれば、当然クライアントにコピーが存在しているのが普通だとは思うから、それを新たなサーバにコピーして復旧完了。これが本来の流れ。だから、大多数の法人は、面倒ではあるけれど、それほど慌てふためく内容とは思えない。 ただ、ここ最近、wikiをはじめとしてCMSが流行しているので、サーバ上で生成したデータをちゃんとバックアップしているかとなると、やや疑問なんだと思う。この点が、慌てる原因にもなっているはず。 個人でもwikiって便利だから利用するけれど、別メディアにバックアップ取るのは案外面倒だから放置しているというのも理解できる。ましてやブログのデータを定期的にバックアップしてるか?と問われると、「してません」となってしまう。 ただし、個人であれば…です。趣味の範疇ですから…。 給料貰って、仕事として作業していたら、それは、やっぱり問題な訳で。いま、この事件をきっかけに慌てているSEさんたちも、きっ