「BitTorrent Sync」で「Owncloud」を置き換え

同期が遅いOwncloud 、なんとかならんか・・・

以前からDropboxに変わる環境としてOwncloudを自宅サーバに構築し、デスクトップPCとノートPCの「ドキュメント」フォルダを同期させたりなどなど、主に複数端末のフォルダの同期を目的に使ってきました。

やはり、Dropboxのような人様のサーバに大事なファイルを置くことに不安・抵抗があり、Owncloudであれば、それに対しては多少なりとも安心感があります。

ところが、Owncloudは同期が遅い。大変に遅いです。

ファイルやりとりに「webdav」を利用しており、ファイル一個を同期するたびにセッションを起こしているらしく。

1分間に5個くらいしか進みません。同期にかかる時間は、ファイルの容量ではなくファイル数で効いてきます。

例えば先日、訳あって、マイドキュメントのフォルダを再同期する必要があり、Owncloud上のデータを削除し、ローカルPCから再度同期をかけました。なんと、これに要した時間、丸三日以上です。

  • ファイル数 : 18331
  • フォルダ数 : 3586
  • 容量 : 18.5GB
  • Owncloudサーバとの同期時間 : 丸三日以上

もう一つ、私は「紙copi」というHPの取り込みソフトを使っています。これはHPをローカルのHDに綺麗に取り込んでくれるソフトですが、保存先のフォルダをOwncloudで共有しています。(→参考記事:紙copiが復活。紙copi 3。Evernoteから紙copiへの移行にトライしてみた。
ところがHPによっては、1枚で細かい部品含め100個近くのファイルで構成されることもあり、その場合owncloud同期に10分くらいかかってしまうことがあります。

これだけ遅いと、複数同時に更新をかけた場合のコンフリクトも起こりやすくなりますし、ちょっと、実用上厳しいな~と思っていました。

これ、もちろん、LAN(Gigabit Ether) 接続の話です。

 

BitTorrent Sync というソフトがあった! ファイル同期が超高速

そんな折、ネットサーフィンをしていると、BitTorrent Syncなるソフトを発見しました。

サーバ不要で、インターネットに接続さえしていれば、ピアツーピア(P2P)で特定フォルダのファイル同期が簡単にできてしまうというソフトです。

複数の端末で共有することも可能です。

フリーで公開されていましたので、早速試したところ、

  • 導入超簡単!
  • マルチプラットフォーム対応 (Windows、Mac、iPhone、Android、WindowsPhone、Linux)
  • 同期、転送が超高速 (Owncloud比)

前出のドキュメントフォルダをLAN内で同期したところ、数十分で同期が完了しました。
これは、「たまらん」くらい魅力的な速さです。
開発者も転送速度含めて同期の速度にはこだわって開発しているようです。

Owncloudは、デバイス間のファイル同期の機能もありますが、webアクセス(ブラウザ)のインターフェースもあり、全く同じ機能というわけではありませんが、私の利用目的がデバイス間のファイル同期であることを考えると、Owncloudからの「乗り換え」を考えるに十分です。

このソフト、昨年前半にはいろんなところで紹介されていたんですね。全く知りませんでした。

 

BitTorrent Syncとは

BitTorrent Syncとは、特定のユーザ間のみでファイル共有できるソフトなんですが、これをBitTorrentの技術を使って実現しています。

詳しくはこちら→ メインページ動作のしくみ技術仕様

参考記事: GigaZine 「PC同士を直接同期し巨大ファイルも高速転送できるソフト「BitTorrent Sync」」

ポイントを簡単に。

  • サーバが不要です。P2Pで共有・同期します。
  • 同期対象のデバイスは2台に限らず、何台でもOK。
  • アカウント管理も不要(というか、無い)。フォルダ毎に共通秘密鍵を設定し、それを各デバイスに設定するだけ。
  • キーは、「読み取り専用キー」「読み書き可能キー」の2種類です。いずれも20文字。
    • 読み取り専用は「片方向」、読み書き可能は「双方向」、の同期と理解できます。
  • 同期時には、その端末同士が同時にネットに接続している必要があります。
  • HTTPプロトコルを使用するので、ルータからは通常のwebアクセスに見えます。UPnPを使用するので、(UPnPが有効なら)FWの設定変更は不要です。
  • マルチプラットフォーム対応 (Windows、Mac、iPhone、Android、WindowsPhone、Linux)

Owncloudでは、同期させたいフォルダをサーバ上に全て設置し、必要に応じてデバイス側から同期したいフォルダを選択し、サーバに接続して同期をしていました。

BitTorrentSyncでは、そもそもサーバの概念がなく、同期をしたいフォルダ・ファイルを持っているデバイスから、同期が必要なデバイスへ直接同期をかけることになります。

デバイス同士で直接、です。

デバイス間のファイル同期を目的としている私としては、Owncloudの置き換え可能なツールとなります。

 

Owncloudと置き換えは可能か?

Owncloudにあって、BitTorrent Syncに無いものを挙げます。

共有フォルダへのwebアクセス画面

OwncloudにはDropbox同様、webアクセスのUIが用意されています。

OwncloudのWeb画面

OwncloudのWeb画面

ファイルをサーバに置いたまま、必要なファイルを探して閲覧したり、サーバ上に置いたまま編集したりと、シンクライアント的な使い方ができます。

プラグインを追加すれば、pdfやMS-Officeのファイルを閲覧・編集したり、ブラウザベースで何でもできてしまう環境を指向できます。

住所録、カレンダー、ニュース等

他にも、以下のようなサービスもあります。

Owncloudの提供サービス。総合ポータルを指向してる?

Owncloudの提供サービス。Dropboxだけでなく、Googleのサービスの置き換えを指向してる?

Googleの各種サービスの置き換えを意識しているようにも思います。

これらの機能は、Owncloudを使うユーザアカウントの存在がベースにあるので、共有・同期機能に特化したBitTorrent Syncにはありません。

 

結論:ファイル同期機能しか使っていないので、置き換え可能(私の場合)

Owncloudを置き換えた場合、上記の機能が使えなくなります。

私自身は、webアクセスのUIを使うことはほとんど無く、もっぱらファイル同期機能しか使っていませんので、十分置き換え可能です。

ただし、OwncloudのwebUIの可能性の検証は続けたいので、何らかの形で共存する方法も考えてみます。

 

常時同期をさせるには、常時ONの「サーバ」はあった方がよい

BitTorrent Syncはサーバ不要ですが、同期するデバイスが同時にネットにアクセスできないと同期ができないため、すれ違いでファイル同期ができない場合があります。常時ネットに接続しているデバイスがあれば、このすれ違いは回避できます。

ですので、置き換えにあたっては、サーバ的に振る舞う、常時接続・常時電源ONのデバイスを一個設けることにします。

Linux用のBitTorrent Syncアプリ(btsync)がありますので、これを自宅サーバ上で常時起動させればOKです。

WebUIを持っていますので、他のWindowsPCと同様の操作感で操作できます。WebUI用のTCPポート(デフォルト8888)はFWを空けておく必要があります。

Linux版BitTorrent SyncのwebUI画面。Windows版と変わりません。

Linux版BitTorrent SyncのwebUI画面。Windows版と変わりません。

btsyncの常時起動にあたっては、起動権限を一般ユーザにするなど、Linux的な一般的なセキュリティ条件は考慮が必要です。

 

導入

Owncloudのクライアントソフトを起動しないか、同期停止にする

いきなり、Owncloudで共有対象にしているフォルダの置き換えをトライしましたので、Owncloudのクライアントは停止させました。BitTorrent Syncとowncloudの2系統で同期をすれば、当然混乱すると思います。

各デバイスにBitTorrent Syncをインストール

私の場合、これまでowncloudで同期を取っていたデバイスは、デスクトップPC、ノートPC、スマートフォン、自宅サーバ上のitunes専用サーバ、eye-fi連動サーバの5台でしたので、各デバイスにBittorrent Syncアプリをインストールします。

また、前述のとおり、常時起動サーバ(Linux)にもインストールします。

各デバイスにおいて、自動起動するよう、適宜設定します。Linux版以外は、アプリの設定項目の中に「自動起動」のチェックがありますので、それでOK。
Linux版は、init.dに起動スクリプトを書くなど、多少手間が必要です。

共有対象のフォルダのキーを、適宜交換する

共有する対象のフォルダごとに、キーを発行し、共有先のデバイスに設定します。

最初のオリジナルのフォルダのあるデバイスを決め、そこで共有フォルダを設定し、そこで出てくるキーを、うまいこと各デバイスに送って貼り付けることになります。

スマホの場合は画面に出てくる2次元バーコードをBitTorrentSyncで写真に撮ると、キーを取り込んでくれます。詳しくは他の紹介記事に譲ります。

完了、同期開始

ということで、同期を開始したところ、数MB/sの速度で転送が始まりました。数時間後、同期が完了。

極めてあっさりと、owncloudで構築していたファイル同期環境を置き換えることができました。

1万個以上のファイルを持ったフォルダが2,3ありましたが、2,3時間後には全て同期が完了していました。

ファイル数をチェックしましたが、全て揃っていました。

 

各デバイスのBitTorrentSync管理画面を開いて目視した状態で、あるデバイスのフォルダにファイルを新規作成してみました。

作成直後、各デバイスの管理画面に送受信の印が現れ、あっという間に全デバイスに伝達されました。なんか、いかにもP2Pという風情です。

 

※注意点: 最初の同期設定時、同期先フォルダは空っぽがよいようです。

キーをコピーして共有設定する先のフォルダに、オリジナルと同名のファイルがある場合、最初の同期がいつまでも終わらない場合がありました。一部のファイルについて、アップロードとダウンロードを延々と繰り返してしまいます。

最初に共有設定する場合は、共有先のフォルダはまずは空っぽにしておいた方がよいようです。同期先にしか無いファイルがある場合は、いったん待避しておいて、初期同期が完了して落ち着いた後に、同期フォルダに放り込むのがよいと思います。

 

OwncloudのwebUIを活かす(BitTorrent SyncとOwncloudの連動)

半日で、Owncloud環境の置き換えが完了してしまいました。が、OwnlcoudのwebUIから見れると便利なフォルダがあるにはあるため、owncloudとの共存を考えます。

Owncloudのコンテンツディレクトリを直接覗くのはムズい

Owncloudの共有フォルダの実体は、webサーバのコンテンツディレクトリ内にあります。

パーミッションがwebサーバ用に合わせてあることと、暗号化していれば直接アクセスしても中身が見えないこと、仕組みはよく理解していませんが、MySQL等DBMSとも連動しているため、btsyncから直接覗いてファイルをいじるには、少しハードルが高いようです。

Owncloudの外部ストレージ共有機能を使う

Ownlcoudには、外部ストレージをマウントする機能があり、Sambaもサポートしています。こいつを使います。

btsyncの共有フォルダを、直接Sambaで共有
  ↓
Owncloud外部ストレージ機能でマウント

OwncloudのwebUIで閲覧

常時起動のbtsyncを起動しているLinuxサーバに、sambaを導入するわけです。

 

これを実行したところ、あっさり連動できました。

私の場合はOwncloud側からは閲覧専用としたかったため、sambaの共有を読み取り専用にしてOwncloudからアクセスさせました。

sambaの設定を「読み書き許可」にすれば、Owncloud側からの追加・変更・削除もできるようになると思います。

 

今回はこんなところで。

2014年8月の当ブログへのアクセス状況

今月も順調に伸びました

右肩上がり。中旬の不正アクセス対策でアクセス数が減りましたが、それでも純増でした。

右肩上がり。中旬の不正アクセス対策でアクセス数が減りましたが、それでも純増でした。

前月比で、訪問者数で3割増、訪問数とページビューで2割増でした。

コツはわかりません。(笑) 自分のペースで記事を書き続けているだけです。時々サボります。

8月中旬頃に、不正アクセス対策としてchaina unicomのIPアドレスをブロックした結果、アクセス数が3割は減ったのですが、それでもトータルで純増でした。

 

ところで、8/10と11に特異的にピークが現れています。

この日は、台風襲来で日本の多くの地域で風が強かった日です。

アクセスが増えたのは、当ブログの特定ページへのアクセスばかりでした。このページです。

みなさん、お困りだったようですね。^^

 

対策を打った不正アクセス

毎月このページばかり異様にアクセスが集中していて、ブログ内でのアクセス数トップでした。どのアクセスも、滞在時間は30秒以下。

大量のスパムコメント書き込みも、このページに集中していました。

スパムコメントのIPアドレスを調べ上げたところ、ほとんどが

36.248.*.*~36.251.*.*

の範囲でした。whoisで調べたところオーナーはChina Unicomでした。

他のページへのこのアドレス帯からのアクセスはほとんど無かったので、思い切ってこのアドレスからのアクセスを遮断したところ、そのページへのアクセスとスパムコメントがぴたりと止まりました。

実はもともと、google analyticsでは、このページへの異様なアクセスが記録されて折らず、手元のログと乖離がありました。この対策でこの乖離幅がグッと縮まりました。

 

対策に使ったのはWordPressプラグインの、

All In One WP Security

です。こいつの「Blacklist Manager」を利用しました。

ついでに、不正なログインを監視したり、様々な対策も同時に打つことができました。これはお勧めです。

 

webサーバがapacheの場合、httpd.conf内で

AllowOverride All

としておかないと、うまく動きません。

私のサーバではAllowOverride Noneとしていたため、プラグイン設定適用後にwebサーバが止まってしまい、めちゃめちゃ焦ってしまいました。

ご注意を。

紙copiが復活。紙copi 3。Evernoteから紙copiへの移行にトライしてみた。

紙copiは優れたHPスクラップ、資料管理ソフト。Evernoteより直感的。

復活という表現が正しいかどうかわかりませんが、10年以上アップデートのなかった紙copiが、先月アップデートされていました。

今回のアップデートは、取り込み機能の強化、Dropbox連携機能追加というところのようです。

記事 : 「紙copi」5年ぶりメジャーアップデート Dropbox連携、Windows 8.1対応

 

たしか最初の登場は前世紀だったと思いますが、ほぼ登場時期からずっと愛用していたHPのスクラップソフトです。

大変お世話になったソフトなので、復活は嬉しいニュースです。Evernoteなんぞに負けず、日本のソフトパワーを見せつけてほしいものです。

12022c334c73987394414e8daa9160e3

紙ラボ。無料お試し30日です。

東京新聞をキャプチャしたところ

東京新聞をキャプチャしたところ

スクラップの正確さがすばらしかった。ほとんどのページを崩れることなく取り込んでくれました。

スクラップしたHPを「紙」として、また、それらを「箱」という概念で分類して管理するコンセプトがユニークで、私には直感的に理解できました。

テキストファイルのメモも作成できます。いちいち「新規作成」とか「ファイル名をつける」などという回りくどい行為なしに、いきなりメモを起こせるのです。

作成したテキストファイルも「紙」として管理できます。

他にも、pdf、ppt等のビューワも内蔵しています。

私自身は、類似機能をもつEvernoteのノート管理より、直感的でわかりやすいと思います。

詳しくはこちら。

紙copiがネットやスマホへの対応が不十分なまま、発展が止まってしまったために、私は数年前にEvernoteに乗り換えてしまいました。

2014年7月の当ブログへのアクセス状況

右肩上がりです

先月、平成26年(2014年)7月のアクセス状況です。

201407

おかげさまで、7月はアクセス数が大幅増でした。

過去も波打ちながらも右肩上がりです。ほんとに、こんな風に増えてくるとブログを続けてよかったなと思います。
(3,4ヶ月サボった時期もありましたが)

自宅サーバに仕掛けているアクセス解析ソフトAwstatsによると、
ブログを開始した昨年9月は、1ヶ月の訪問者数が235人。先月7月は7462人でした。11ヶ月で30倍となりました。

GoogleAnalyticsではそれぞれ、26人、3529人です。スパム的アクセスにフィルタが掛かっているっぽいです。(GoogleAnalyticsは複雑すぎて全部を理解できていません)

検索キーワードによってはgoogle検索結果の1位、2位に上がる記事もチラホラ出始めました。

当時は、ここまで読んでくださる方が増えるとは思っていませんでした。

なんというか、ますますブログを続ける意欲が沸いてきます。

というわけで、以上、不定期のアクセス状況報告でした。

最近(2014年5月)の当ブログのアクセス傾向

2014年5月の1ヶ月間で15839ページビュー

昨年2013年9月8日にこのブログを開始してから9ヶ月半が経過しました。

この間、ホントにマイペースで記事を更新してきました。こんなんでどれくらいの人が読んでくれるのかと自問自答しながら。

本業で頭がいっぱいで、何ヶ月かサボっていた時期もありました。

ですが、このブログを読んでくださる方は着実に増えてきておりました。
いままでお越しいただいたみなさん、ありがとうございます。嬉しいです。

過去のアクセス数推移の数値を一部ご紹介します。

画面は、フリーのアクセス解析ソフト「Awstats」です。

201405_awstats

2014年1月以降のアクセス数推移。 右肩上がりです。6月は横ばいになりそうですが。

201312_awstats

2013年中のアクセス数推移。2014年と比べて、グラフスケールが小さい(虫眼鏡で拡大しているようなもの)ですのでご注意を。

前回のアクセス数報告記事

ロボットのアクセス、LAN内からのアクセスは除いています。

ご覧の通り、

  • 2013年中は3ヶ月ほど横ばい
  • 2014年中は右肩上がり
  • 2014年3月から増加が加速
  • といっても、まだまだ絶対量が少ない

こんな傾向です。

3月、4月ころに、どの記事にアクセスがあったかを見てみたところ、「v6プラス」というインターネットプロバイダの特殊なサービスを紹介した記事へのアクセスが急増していました。

「v6プラス」は、普通にインターネットを使うだけの人にとってみれば、かなりマイナーかつマニアックなサービスです。こんな記事読む人そんなにいないだろうなー、と思いつつも、ネット上に情報が少なく私も苦労したので、知り得た情報を意識して少し多めに記事に上げていました。

今年の4月に、BIGLOBEが同サービスに対応することがプレスリリースされ、それ以降、この記事へのアクセス数がグンと増えたようです。

こういう、ネット上の情報が少ないネタの記事を上げておくと、突然アクセス数が増えるってことがあるんですね。

GoogleAdsenseの収益も、ほんの少しだけ増えています。といってもトータルで1000円少々ですが。(笑)

また最近は嬉しいことに、結構このブログが検索上位に上がって出てくるケースが増えてきました。最初の3ヶ月は全くほとんど鳴かず飛ばずでしたが・・・

ブログって、継続することが大事なのかも知れませんね。

Eye-Fi(デジカメ)から自宅サーバのOwncloudへ自動転送する

Eye-Fiはものすごく便利なのだけど

Eye-FiはカメラにSDカードとして装着したまま、Wi-Fi経由で写真を自動で転送してくれる、大変便利なアイテムです。
写真を撮影したあと、SDカードをいちいち抜き差ししなくても、気づいたらPCのフォルダの中にその写真ファイルが入っているという、何とも快適なものです。

自宅サーバに立ち上げているOwncloudにEye-Fiから自動転送できると、さらによいのですが、後述する理由から叶いません。Owncloudは、簡単に言うと自前版Dropboxです。無償で自宅サーバにインストールして構築できます。
Dropboxが使用容量が増えるごとに料金が増えるのに比べ、自前のサーバのHDDの容量が許す限り無制限に好きなように使うことができます。(テラバイト使っても料金不要!)

自宅サーバにOwncloud環境を整えてからは、Dropboxから完全移行し、自前のストレージをデスクトップPCやスマホから利用しています。

実際便利なEye-Fiですが、サービス上の制限がいくつかあります。

  • デジカメから写真を転送する場合、必ずEye-Fiの用意したサーバに一度吸い上げ、ここを経由して手元のPCかオンラインサービスに転送される
    (転送先はEye-Fiの裁量で決められてしまうってことです)
  • 転送先のPCは、Eye-Fiマネージャが動作しているものに限られる(windowsかmac)
  • 転送先のPCは、1台だけ
  • PCを転送先に設定するときに、そのPCのUSBポートに、Eye-Fiカードを挿しておかなければならない
  • Eye-Fiサーバの転送先にオンラインサービスを選べるが、多くが有償サービス。Owncloudは無い。

今の環境では、WindowsのデスクトップPCにEye-Fiマネージャをインストールしていて、ここにデジカメの写真が転送されてきます。転送されてきた写真は、さらにOwncloudクライアントからOwncloudサーバに自動で転送されます。

ですが、このデスクトップPCの電源が入っていないときは、Owncloudに反映されません。

eye-fi

手元PCの電源On/Offに関わらず、「写真撮影→即、Owncloudに反映」する環境を整えるのが今回の目標です。

自宅サーバ メール配送遅延・不達問題(後に解決)

システム用のHDDにトラブルが出て対処中にもかかわらず、新たなトラブルが出ました。

ある日突然、自宅サーバからいくつかのドメインに、メールを配送できなくなりました。

心当たり不明。スパム対策(S25Rなど)も行っているので、なぜそんなことに・・・

 #2013/10/23追記:

大変初歩的なミスが原因とわかりました。メールサーバはドメインのマスターのネームサーバも兼ねているのですが、ネームサーバのIPアドレスが変わったにもかかわらず、レジストラのネームサーバIPアドレスを変更し忘れていました。

タイミングによっては、違うIPアドレスでありながら、勝手にマスターサーバを名乗って詐称していたことになっていたわけです。そんなサーバからの接続、拒否されても当然です。

固定IPアドレスをそれほど頻繁に変えるわけではないために、その作業をすることを忘れていました・・・

レジストラの登録情報を変更したあと、メールを拒否される事象は発生していません。

 

とりあえず、ブラックリストに登録されていないか調べてみた

Blacklistalert.org

自宅のメールサーバはブラックリストには登録されて無さそう

自宅のメールサーバはブラックリストには登録されて無さそう

見たところ、ブラックリストの線はシロのようです。

他に、rbl.jpでも検索しましたが、シロでした。

キューが溜まってないか見てみた

mailqでメールの配送待ちがないか見てみたところ(mailq)、通常、溜まっているメールなんてないのに、「9通も!」溜まっていました。

溜まっている原因はどれも、

  • conversation timed out
  • lost connection while EHLO handshake
  • refused to talk to me

のどれかでした。相手サーバから「拒否」されたか、「シカト」されたってことのようです。

postfix flush

で、溜まったキューの強制配送をしてログを監視していましたが、案の定、2通は上記3つのメッセージのオンパレードでした。
2通は受け付けてくれて送れたみたいです。

 

拒否されている相手は、携帯3社(docomo.ne.jp,softbank.jp,ezweb.ne.jp)、複数のプロバイダのドメインのメールサーバでした。

同時に拒否されるってことは、これらプロバイダや携帯キャリアが共通に参照しているDBがあって、そこに登録されてしまった可能性が高いと思いますが・・・それがなんなのか、見つけられませんでした。

結局、グローバルIPアドレスを変更した。回復した。

結局、最後の策としてあまりやりたくありませんでしたが、自宅サーバに割り当てられているグローバルIPアドレスを変更してみることにしました。

現在利用しているプロバイダと(固定IPを安価に提供していて、申込み即日接続可)、追加の接続契約を結んで、新たなIPアドレスの払い出しを受けることにしました。並行運用期間を終えたら、現在の契約は解除することになります。1ヶ月程度の二重課金を覚悟しての対策です。

申込みはすんなり完了し、フレッツPPPoE用の新接続IDとともに、新IPアドレスが届きました。

HGWに新セッション情報を登録し、自宅サーバが新セッションからインターネットに出るよう設定し、新セッションと旧セッション両方からの通信が受信できるようIPマスカレードの設定を行いました。

 

この状態まで持って行ったところで、メールキューを強制配信(postfix flush)をしたところ、全部一気に配信が完了しました。便○解消!って感じ。

やっぱり、何かのきっかけでスパムサーバ扱いされていたのだと思います。
IPアドレスを変更しただけで回復したことから、スパム登録の対象はIPアドレスのみで、ドメイン名は拒否対象ではなかったようです。

結局なぜこんなことになったのか、理由はよくわかりませんが、この後メールサーバのスパム対策を強化(taRgrey)しました。結構いい感じになりましたが、これはまた後日。

2013年9月のアクセス数推移

9月8日にブログを立ち上げ。9月のアクセス件数は927。

このブログ、9/8にブログを立ち上げましたが、このコンテンツでそれほどアクセスが伸びるとも思っていませんでした。

9/20を過ぎてポツポツとアクセスが記録されるようになりました。日別の推移はこんな感じ。

9/22以前のログはないけども、限りなく0でした。 ほんとに、これだけアクセスがあったことが信じられません。

9/22以前のログはないけども、限りなくゼロでした。
ほんとに、これだけアクセスがあったことが信じられません。

9/22に、apacheのログ設定をcommonからconbinedに変更しまし、より多くの情報を記録するよう変更しました。

commonでは情報が不足しており、一部ログ解析ソフトが対応していなかったため、9/22より前のcommonのログは解析対象から外しています。

当然ながら、LAN内のアクセスも除外しています。

アクセスしていただいた皆さま、ありがとうございました。

アクセス数が上がったこと自体、驚きではありますが、少ないことには変わりなく、まだまだ、ビジュアルも手直ししていきますし、揃えるべきコンテンツももう少し考えて変えていこうと思っています。

しばらくは、何をどうしたら、反応がどう変わるか、いろいろと試してみたいと思っています。

visitorsのツリーも置いときます。サイト内をどんな経路で移動されたかの記録です。

visitorsのツリー。 ほとんどのアクセスが検索サイトを経由していません。

visitorsのツリー。
ほとんどのアクセスが検索サイトを経由していません。

WordPressのバックアップの設定(MySQLのバックアップ)

WordPressの更新通知が来た

一昨日あたりかな? WordPressのダッシュボードにログインすると、更新通知が。

ダッシュボードにWordPressの更新通知が

ダッシュボードにWordPressの更新通知が

さっそく、アップデートしようとしたところ、


重要:
アップグレードの前に データベースとファイルをバックアップしてください。アップグレードについてヘルプが必要な際はWordPress のアップグレード Codex ページをご覧ください。

と警告が。ま、おっしゃるとおりです。
ブログのバックアップを取る仕組みを入れていませんでした。これから記事をため込んでいこうとしているのに、これは大事なことです。

更新時だけとはいわず、定期バックアップの仕組みを作り込もうと思います。
想像するにバックアップ復旧が必要なシーンを考えると、

  • サーバを再インストールするとき
  • ブログを移設するとき
  • ブログをうっかりミスで消してしまったとき
  • HDDが壊れてしまったとき

でしょうか。
HDDの回転音が異常になったり、bad sectorができたり、まったく読めなくなったり、というのは経験上、割と発生します。
1~3点目は、どこにバックアップを残しておこうが問題になりませんが、4点目を考慮すると、DBが入っているのとは物理的に別のHDDにバックアップを取っておいた方がよいと言えます。

また、ブログの更新頻度は多くても一日一回程度ですので、バックアップ頻度も一日一回程度とします。

他にも、遠隔サーバにバックアップしたり、ミラーサイトを作ったり、いろいろと方法はあるかと思いますが、今回は自宅サーバ内の別ディスクに、一日一回、バックアップを残すことを目指します。

さっそく公式サイトのlinkをたどった。

 

WordPressのバックアップの方法。

webアプリは使わずより低レベルなcronでやっとこう。

WordPressはMySQLにブログ記事を含めたサイトのデータを格納していますので、DBレベルのバックアップが必要です。(ファイル丸ごとコピーでは、DB壊れるかもしれません)

バックアップ対象はDB以外にもあります。phpの設定ファイルなどは、ファイルレベルのバックアップが必要です。私の環境ではすでに全ファイル日時バックアップを組み込んでいるのでそのまま利用します

ファイルのバックアップについては詳しくは書きませんが、バックアップはcron rsync の組み合わせでやっています。サーバ筐体内に物理的に別のHDDを追加し、一日一回、rsyncで丸ごとバックアップをとっています。

公式サイトのバックアップの説明サイトのリンクをたどったところ・・・

wordpressのバックアップ

公式サイトのwordpressのバックアップの説明

phpMyAdminというwebアプリ経由でのバックアップの説明がありました。

これ、インストールしていないです。また、これを使うとバックアップしたり、復旧したりするときに、このwebアプリが必要になると考えた方がよいのでしょう。(そうでない方法もあるかも知れませんが)

バックアップの復旧は低レベルの操作でできるに越したことはないし、何でもできる自宅サーバですので、cronで直接DBをバックアップする方法を取りたいと思います。

 

採用したMySQLのバックアップ方法と自動化設定

MySQLのバックアップをするためのコマンドは、mysqldumpです。これを使います。

以下の手順でバックアップを設定しました。

  • MySQL バックアップ専用ユーザ作成、権限設定
  • バックアップコマンドと動作確認
  • シェルスクリプト作成
  • cronへの組み込み

以下、手順詳細。

バックアップ専用ユーザ作成 (ユーザ名 backup)
[root@]# mysql -u root -p
mysql> grant select,file,lock tables,show view,event on *.* to backup@’localhost’ IDENTIFIED BY ‘パスワード’;
Query OK, 0 rows affected (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
※SQLは大文字で書くらしいです。上は混ざっています。

コマンドラインでDBバックアップしてみる。(バックアップ先はmysql-all-db.sql)

[root@]# mysqldump -u backup -pパスワード –all-database –events > ./mysql-all-db.sql

スクリプト作成

バックアップ先のパス:/Backup/mysql_backup/
バックアップファイル名:mysql-all-db.tar.gz
としています。

バックアップ先(/Backup)は物理的に別のディスクをマウントしています。/Backupの権限は700。
lvmも使っていません。lvmを使っていると復旧が大変になる場合があります。

mysqldumpでバックアップを作成した後、tarで圧縮をかけて保存するようにしています。

—mysql_backup.sh—

#!/bin/sh
USER=”backup”
BPATH=”/Backup/mysql_backup/”
BFILE=”mysql-all-db.tar.gz”
PW=”パスワード”
mysqldump -u $USER -p$PW –all-database –events> $BPATHmysql.sql
mkdir -p $BPATH
tar cvzfP $BPATH$BFILE $BPATHmysql.sql >/var/log/mysql_backup.log
rm $BPATHmysql.sql
chmod 600 /var/log/mysql_backup.log

—mysql_backup.sh—

crontab登録

[root@]#crontab -e
30 12 * * * /パス/mysql_backup.sh
毎日12:30に起動します。

おわりに

これで、一日一回、別の物理ドライブにSQLのDBすべてをバックアップする環境が整いました。

実際には、テストDBなどを用いてバックアップからの復旧ができるか、確認をしておいた方がよいと思います。

参照サイト

参考にさせていただきました。ありがとうございます!