emptypage.jp blog

「作者さんがまだWZを使われてるのかわからないので〜」とか書きかけたのはここだけのひみつです。

というわけで、

「連番見出しプラグイン」勝手に不具合修正パッチを公開します。

「『さくらのレンタルサーバ』で Python 外部モジュールを使う」というドキュメントを書きました。自分で調べたことをわかった範囲内で書いただけですが、人によっては参考になるんじゃないでしょうか……。

追記: 最初に公開してから一部書き直しをしてたのですが、アップロードし忘れてました（汗）。最初に公開してから時間がたってるので、念のためそのことを書きとめておきます。（2005-07-02）

バックアップについて

最近の自分のバックアップ環境の報告もかねて、殴り書きメモ（読みにくいです）。最近、confidentialな情報も扱いだしたので、ノートPCでのセキュリティとバックアップについてまたいろいろ考えているところです。そのうちまとめ記事みたいなページも作るかも。

結局のところは、もしシステム全体を簡単に短時間でばしばし（世代ごとに）バックアップできるようなら、それがいちばんいいわけですよね。ドキュメントとシステムとでバックアップのやり方を変えてみたり、ミラーリングと使い分けてみたりというのは、利便性を追求してというよりも、「まともにやるとバックアップに手間と時間をとられすぎる」というところでのトレードオフの結果としてそうなっているという面が大きかったりします。

ちょっと前までは、ntbackup.exeとWSHでせこせこドキュメントを格納しているフォルダだけバックアップしていたのですが、先日からSymantec LiveState Recoveryを使うことにしました。この製品はV2i Protectorの後継。最近はオープンソースなソフトをよく探すようになっていたので、パッケージでアプリケーションを購入したのは久しぶり。仕事の役に立つのなら、フリーだからとか悪しきプロプライエタリのビジネスがどうのだからとか言ったりはしませんよ。使えるものを使うべき。

競合製品としてはAcronis True Imageがありますが、双方の体験版を試して比較した上で前者に。最大の決定理由が、増分バックアップの時間が短いことでした。

というか、LiveState Recoveryの増分バックアップ時間の短さは桁違いです。過去に、やはりバックアップ・ユーティリティの候補としてIBM Rescue and Recovery with Rapid Restore（現IBM Rescue and Recovery ）も使ってみたことがありますが、増分バックアップ開始時にバックアップ対象を調べるのにファイルをスキャンする時間がファイル数が多くなるほど長くなり、これはちょっと耐え難いと感じたので常用するには至りませんでした（当時のバージョンでの話です）。バックアップ対象のファイル数が増えるとバックアップ時間が長くなるのはntbackupもTrue Imageも同様。たとえば、僕の環境（80GBのHDDでうち約50GB使用）ではTrue Imageで増分バックアップを作成するのに、ファイルのスキャンだけで1時間以上かかってました。が、LiveState Recoveryはそれがほぼ数秒、ネットワーク先のHDDにイメージを保存して作業が完了するまででも数分という速さです。これだと朝出かける前のメールチェックのついででもバックアップができます。

Symantec LiveState Recoveryの増分バックアップは速い。

これはたぶん、HDDのI/Oに割り込み、常にHDDの使用状況をロギングすることで実現してるんだと思いますが（V2iのときはそういう技術的な解説がサイトの売り文句にもあったんですけど、Symantecになってからなくなっちゃいました）、ライバル（？）True Imageも当然そんな感じだろうと思ってたので、この点については試用してみたら律儀に毎回ドライブをかりかりスキャンしてたので意外でした。スケジューリングの柔軟性とかは若干True Imageのほうに軍配が上がるけど、バックアップ時間にここまで差があるとちょっとそっちには食指が動かなくなってしまう。

というわけなので、大切なメールボックスをロストされた方など、もしまだ試されてなければご参考までに。

おまけ。バックアップ・ユーティリティは他にもいろいろありますが、今回は、以下の要求を満たしていることを前提に候補を選定してました。導入することで変に気を使わなきゃいけなくなるのは面倒ですからね。

• NTFSのファイル属性（というか主に暗号化属性）をきちんとバックアップ／復元できる。
• ファイル名やフォルダ名にasciiやシフトJISの範囲外の文字があっても当然バックアップできる。
• バックアップイメージ自体を暗号化できる。

これを満たすのはなかなか多くないんですよ。

それはそれとして

やはりmbx共有というのは危ないからやめたほうがいいのではないかと、心の老婆が申しております……。

ITmedia PCUPdate：私は如何にして“収納”するのを止めて“捨てる”技術を身につけたか。 (1/3)

http://www.itmedia.co.jp/pcupdate/articles/0506/14/news001.html

こうして私は、あふれるモノたちのデジタライズを始めた。

最初は音楽CDから。アップルコンピュータの「iTunes」を使い、ビットレート192Kbps以上の高音質モードで音楽CDをリッピング。クラシックやジャズはCDクオリティのまま変換できる可逆圧縮のアップル・ロスレス・エンコーダ方式を使用した。約40Gバイトのハードディスク容量と引き替えに、200枚以上あった音楽CDを捨てる自由を手に入れた。

……。

と、書くと著作権の話かと思われるかもしれないけど、そうじゃなくて、それとはまたべつの違和感が……（ちなみに、これはべつに違法じゃない）。個人的には、「音楽CDを捨てる」ってのはなかなかショッキングで……。書籍や音楽CDとかは作られる数が決まってる（そしてじつにあっけなく廃刊・廃盤になる）ので、自分にとっていらなくなったものでも塵に帰することはしないで、可能なかぎりなんらかの形でこの世に残しておくべきだというのが僕の考えなので。これは「もったいない」というのとはちょっと違うんですが……。

ホットスポット検索サイト、dokoyo.jpのau版 (http://dokoyo.jp/a/) がひじょうに便利……。auの携帯電話にはGPS機能があるので、「現在位置情報送信→最寄のホットスポットを検索して表示→適当なとこを選ぶ→そこの地図を表示→（必要であれば）ルート案内開始」とじつにスムーズにことが運んでいきます。きわめて実用的。すばらしい。これで街をうろうろして疲れ果てる頻度が激減！

近くにモスバーガーがあるかもしれないけどわかんないから仕方なくマクドナルドに入ってしまうというケースも激減！