WordPressをバックアップするサービスCodeGuard


WordPressのデータを毎日バックアップしてくれるというCodeGuardというサービスがあるらしい。

日本語でCodeGuardを検索すると旧ボーランド(現エンバカデロ)の開発ツールが出てきますが、それとは違います。

バックアップ手法としては2通り

・sftp/ftpでログインして丸コピー
・wordpressに専用プラグイン入れてコピー

wordpressの方はプラグインを入れるので、SQL側も調整して静止点を取れますが、sftp/ftpの方は、そのままだとちょっと微妙な状態になりかねないですね。

費用ですが、Plansを見ると3種類に見えますが、実は4種類あります。

Free:
・2GBまで使える
・週1回バックアップ
・サイトの監視。マルウェアがアップロードされていないかなど
・アクセスIPのログ機能なし
・履歴保存
Personal:
・5GBまで月5ドル
・容量追加は10GB(月10ドル増加)単位で可能。
・毎日日本時間13時開始のスケジュールバックアップ
・サイトの監視。マルウェアがアップロードされていないかなど
・監視の結果を受けて通知メール送付機能
・アクセスIPのログ機能なし
・履歴保存
Professional:
・125GBまで月99ドル
・25サイトまで無料で登録可能。
・複数サイト登録時にバックアップ順序の指定可能
・複数ユーザ登録可能、ユーザ向け解放も可能
・アクセスIPのログ機能あり
・携帯SMSを使った2段階認証も可能
・履歴保存
Enterprise:
・500GBまで月299ドル
・100サイトまで無料で登録可能。
・複数サイト登録時にバックアップ順序の指定可能
・複数ユーザ登録可能、ユーザ向け解放も可能
・アクセスIPのログ機能あり
・携帯SMSを使った2段階認証も可能
・履歴保存

現状が2GB以内で収まっているのであれば、とりあえず、Freeプランで登録してみてから始めるのがよさそうですね。

ちなみにデータの保存先は、Amazon S3/EC2のようです。
CodeGuard blog:How Safe is Your Website Backup?

また、サイトを高速化する、というサービスのCLOUDFLAREと提携しているようで、「CLOUDFLAREアプリ CodeGuard」という日本語の紹介ページもあります。

で・・・Free 2GBに登録してみました。

重要な注意点:
Freeプランは「アカウントのみ作成」のページからでないと登録できない。

注意点2:gmailで登録したら、「Welcome to CodeGuard!」というタイトルの登録完了通知が迷惑メール扱いされていました。メールが来ないようなら要確認。

アカウントを登録した後は、以下の選択が出てきます。

WordPressで使う場合は、「Is this a WordPress site?」の下ぐらいにあるリンクをクリックします。

そうすると次の画面で、Wordpress用プラグイン設定に必要なkeyが表示されますので、それをコピペします。

その次に、Wordpressにログインし、プラグインにて「Codeguard」で検索してプラグインをインストールします。
間違えて「Code guard」とスペースを入れてしまうと検索に出てこなかったので注意してください。

インストール後、keyを登録すると、Code GuardのDASHBOARDに以下の様な表示がでてきます。

登録したサイトをクリックすると、現在のプロセスが表示されます。

で・・・もうちょっと待つと

という感じで、Amazon EC2への転送完了待ち状態となります。

・・・・えぇ、まだ終わってないので、続きはまた今度の更新となります。

赤枠のところにあるように「11月14日完了予定」です。
完了したらメールで連絡が来るように緑枠のところの「Email me once the backup completes」にチェックを入れときましょう。


11/14とかいっといて、実際には11/12 21:43に終了メールが届きました。

ただ、ダッシュボードを確認すると、14時間の時差が・・・
timezoneはTokyoに設定しているんですが、謎です・・・

ApacheのFancyIndexと文字化け


Apacheのauto index機能を使って、「http://~/ディレクトリ/」を開いた時に、ファイル一覧を取得できるようにしようと考えた。

が・・・
日本語UTF-8のファイル名を置いたところ、文字化けが発生。

調べると、サーバが返すレスポンスが「Content-Type: text/html;charset=ISO-8859-1」となっている、ということが判明。

いろいろ、試した結果、最終的に、「apache の mod_autoindex が ISO-8859-1 になってカオス」の情報にたどり着きました。

つまり、設定ファイルに以下の様な形で、autoindexにキャラクタセットのオプションを指定してしまう、というのが解決策でした。

Options ExecCGI Indexes
IndexOptions Charset=UTF-8

・・・マニュアルに書いていないオプションがあるとは・・・と思ったけど、探したら英語版マニュアルには書いてあった・・・

これだから日本語版マニュアルは・・・

microADを入れてやめた


microADという広告を7/23に導入してみた。

が・・・使い方に関するヘルプとか規約とかを確認しようにも見つからないし、ブログとかも更新されてないし、やる気が一切感じられないサイト構造(これらは公知情報ですよね)でげんなりしたところに、

致命的なのは、サイトの内容と全然関連性がない、どうしようもない広告ばかりが表示され、実際、効果は全くありませんでした。(これは、利用した感想であり、機密情報の漏洩ではありません)

2週間ほど使ってみましたが、正直、こういった技術系のサイトで使う価値はないようです。

perl CGI.pm 渡される引数の取り扱い


perlでCGI.pmを使ってCGIを作る際の話。
・CGIに渡されたパラメータは、別のサーバに対してのコンテンツ取得に使用する
・渡されるパラメータが何がどれくらいあるのかが特定できない
・こちらの内部管理用で不要なパラメータとして特定の文字列があるが、それは引き渡さない

こんな条件がある時に、どーやって、パラメータを取得するか、というところ。

use CGI;
my $q = new CGI;
# 不要なパラメータを消去
$q->delete('sessionid');
# 残ったパラメータを表示
foreach my $name ($q->param) {
    # $nameが持っている値が複数の場合もあるため
    # @_=$q->param($name)に格納して
    # それをforeachする
    foreach my $value ($q->param($name)){
        print "$name=$value <br>\n";
    }
}

perl LWPを使ってcookie必須のページへのPOSTアクセス


うちで主に携帯向けとして提供しているゲームコンテンツのゲートウェイサービスは、内部でHTTP::Liteを使用して、オフィシャルのコンテンツを取りに行っている。

いままでは、それで問題なく利用できていたのだが、今回の動作状況見直しの際に、1点問題となる場面が見つかった。

それは、以下の様に同じ名前のパラメータで値が異なるものを送らなければならないことがある、ということ。

&lt;input type="text" name="param" value="value1"&gt;
&lt;input type="text" name="param" value="value2"&gt;

HTTP::Liteは、POSTアクセス時のコンテンツのペイロードに連想配列を使うため、同じ名前のものを複数送ることができない。

そんなわけで、LWPを使うように仕様変更を試みた。


HTTP::Liteを使用するもの

use HTTP::Lite;
$http = new HTTP::Lite;
$url="http://~";
$http-&gt;add_req_header("Cookie", "cookiename=$cookie");
%vars = ( "param" =&gt; "value1");
$http-&gt;prepare_post(\%vars);
$req = $http-&gt;request("$url")
    or $flagerr=1;
$contents=$http-&gt;body;

LWP使用に変更したもの

use LWP::UserAgent;
use HTTP::Headers;
use HTTP::Request;
$lwpua = LWP::UserAgent-&gt;new;
$url="http://~";
$lwpreq = HTTP::Request-&gt;new(POST =&gt; $url);
$lwpreq-&gt;content_type('application/x-www-form-urlencoded');
$lwpreq-&gt;header("Cookie"=&gt;"cookiename=$cookie");
$lwpreq-&gt;content("param=value1&amp;param=value2");
$lwpres= $lwpua-&gt;request($lwpreq);
$contents=$lwpres-&gt;as_string;

細かい点はいくつかあるものの、こんな感じで移行はできた。

失敗した点

最初「$lwpreq = HTTP::Request->new(POST => $url);」を「$lwpreq = HTTP::Request->new(POST => ‘$url’);」としていた。
この場合、「400 URL must be absolute」というエラーメッセージが出力されていた。
$urlにつけていたシングルクォーテーションを外したところ、正常動作した。

参考にしたLWP cookbookのサンプルは固定URLであるので、シングルクォーテーションで良いが、変数を使う場合にシングルクォーテーションを使うと駄目、という基本を忘れていたために食らいました。

もう1点、サーバに対して、Cookieの値を送る方法がよくわからなかった。
HTTP::Liteの時の例とかを考え、headerにCookieという名前で値を追加すればいい、と思い当たったので、それでやってみたところ、期待通りに動作した。