本日は母校大阪大学キャンパスへ

本日はもっとも忙しい月曜日でしたが、公用で大阪大学医学部先端医療イノベーション・センターに出かけました

ぎりぎり 11:30AMまで外来診療し、それから暑い日差しの中、そして海からの強い暑い南風にに逆らって一生懸命自転車で自宅に戻り、それから着替えて、実は普段「短パン+T-shirts」なのですが、この格好では流石に公的な会合には出席できませんので、いちおう半袖シャツと、スラックスに履き替えたのです そして 12:00には自宅近くまである会社のお迎えがあり、そのタクシーに乗り込み、新横浜駅までの道すがら色々な打ち合わせを行いました

そして、13:09新横浜発の「のぞみ」に乗り込み、一人で大阪大学吹田メインキャンパスまで向かったのです やはりこのあたりは学生時代の思い出が残る場所です それは何と 1969年から1975年の間でした あの頃は僕の可能性は  360度拡がり、世界は自分の手の中にありました しかし年齢を重ねるにつれ、自分の可能性の世界はどんどん狭まり、今やそうですねたった一度だけの可能性の拡がりしか残っていません 寂しい 自分がそのようにして社会の中から忘れられていくのでしょう 寂しい あがないたい、でも難しいでしょう

新大阪駅で下車し、少し時間に余裕があったので、北大阪急行 これは地下鉄御堂筋線の延長です それに乗り換え、終点の千里中央駅に行きました 学生時代から何度この駅を使ったことでしょう 妙に感傷的になります

そして、これは生涯で初めてと思うのですが、大阪モノレールに乗り換え、かつての大阪万博跡地の大阪万博公園の周りを回って大阪大学医学部付属病院駅で降りました まだ時間に余裕があったため、病院内の Subwayには入、アイスコーヒーを飲みました そう言えば最近は大阪でもアイスコーヒーのことをアイスコーヒーと言いますね でも僕が学生の頃は、大阪の喫茶店で「アイスコーヒー」と言っても店員さんは「何?」と全く理解できませんでした 大阪では正統派的呼び名は「レイコー」か、うーん忘れてしまいましたが、もう一つ呼び名があったような・・・ もちろんレイコーというのは、冷コーヒーのことなのです

まあ、今はアイスコーヒーで大阪じゅう通用しますし、大阪の若い人たちも レイコーという言葉は知らないかも知れませんね

それで、会議は 17:00よりその先端なんとかの7階で開催されました それはそれはお偉い先生方がお集まりとなり、僕は小さくなっていました そして会は 18:40頃まで続き終了しました 戻りは再び一人でモノレール – 地下鉄 と乗り継ぎ、そして現在は新幹線「のぞみ」で途中駅名古屋に停車中です

あー疲れた 自宅に到着は 23:00は軽く回るでしょう 明朝はまた 7:00AMには病院に到着してそれからTAVIと MitraClipです 大変ですね

それはそうと本日午後はこの kamakuraheart.orgのサーバーがダウンして全く通じませんでした これも大変でしたよ

障害は立て続けに起こる

さてさて、MacOS High Sierraに 9月末に upgradeの報が流れました 暫く様子見ていたのですが、あまり悪い噂も聞こえませんでしたので、思い切って昨夜 download – installしたのです

快調に動いていました しかし しかし 大きな問題発生です 仮想Web Serverを立ち上げている XAMPPの componentの中で Apache Web Serverが立ち上がらなくなったのです これはある程度予想はしていました High Sierraの securityがきつくなっているからです

そこで、最新の XAMPPを downloadしたのですが、今度はこの中に htdocsなどがありません 一体全体どうやって phpmyadminを立ち上げたり、DocumentRootをどうやって設定すれば良いのか さっぱり分かりません Webで検索しても未だHigh Sierraが新しいからでしょうか 検索にヒットしません

そこで、もう一つのやり方である MAMPを download installしたのです 今度は DocumentRootの設定もあるし、htdocsもあり、さらには phpmyadminもOKです

これで解決と思ったらば、それでもWeb pageが作動しないのです

そうこうしている内に、何と www.kamakuralive.netのトップページが動作していないことに気づきました 突然の如くです多分ここ一日以内のことです

何でぇ~ です 何も悪いことしていないのにー です

悪いことには、仮想 Web Serverが立ち上がらなくなっているので MacBook Proでプログラムのテストができないのです あーーーーー 呆然としました

そして、どのようにすれば復旧に近づけるのか? それを考えました

最初に試みたのは、MacOSの本来の Unixで Apache/MySQL/PHPを立ち上げることです そこで High Sierra/Apache/phpmyadminで検索したところ、最新のものとしてここに行き着きました

これを見てやりました かなりスキルが必要です しかし しかし それでも localに立ち上がらないのです もうどん底です

最後の手段として 外付け diskに backupしているファイルをコピーしてそこから操作開始、ようやく復旧しました

しかし、正直未だに原因が良く分からないのです 攻撃かも知れませんね

まだ、MacBook Proに local web serverを立ち上げることに成功していません

結局これで良いのでしょうか?

最近は Dockerを触ることもほとんど無くなりました まさしく飽きっぽい 本当に根気がない駄目人間ですねえ

ところで、自分はレンタルサーバーを用いて Webを運用しています 例の以前サーバー情報を運用の誤りで全部消してしまった FirstS*****のレンタルサーバーを用いています いやああの時は大変でした 何しろ全ての情報が消えてしまったのです この時の緊迫した状況をこのブログに書き留めていました しかし、このブログそのものも消失してしまったので、その事故以降の記録ではあります

まあその話は怒りと共に蘇りますが、今はその話ではありません 僕が使用しているレンタルサーバーは Linux上に、Apache Webe Server + PHP + MySQLがついている、というものです つまりいわゆる LAMP (= Linux, Apache, Mysql, Php)なのです しかし、自分には root権限は無く、例えば Rubyを走らせようとしてもそもそも Ruby Interpreterがインストールされていないので動かせません Root権限が無いので、自分でインストールすることもできません こんな環境なので、そもそも Dockerをインストールできないのです

ここまで色々勉強してみると、Dockerなどをインストールしてコンテナとして色々なことを試そうと思えば、どうしても Root権限のあるレンタルサーバーにせねばならないのでしょうね

しかしこの場合には、Portを潰したり、Updateをしたりも自分でせねばならなず そんなに知識が無い自分には不釣り合いです ここまで考察すれば、Dockerなどに手を出す資格が無い、そういうことでしょうかね 残念ですが能力不足なので仕方ありませんね

パリでは忙しくて、そして最後には辛くて

今年も恒例の EuroPCRという世界最大の心臓インターベンションに関するライブデモンストレーションおよび学会がパリ国際会議場で開催されました

僕はこの学会に日本人としては初めて招待者として招かれ、以来毎年20年間に渡り参加しています 以前は毎年のように僕はライブデモンストレーションを飛ばしていたのですが、ここ数年間はライブデモンストレーションを飛ばすことがなかば禁じられ、もっと若い世代がライブデモンストレーションを飛ばすようになっています

実際今回も冠動脈インターベンションのライブデモンストレーションをパネリストなどとして見る機会があったのですが、僕の目からすれば「うーん」というものばかりでした

今回は、5/14の土曜日にパリに入り、翌日5/15日曜日には Tokyo Valves 2017のための Preparatory meetingが 4時間に渡り開催され、その間ずっと日本、ヨーロッパの先生方と英語で討議したのです そして月曜日には Innovators’ dayという秘密会が開催され、そこにも顔を出しました

火曜日、水曜日には自分自身の発表、そしてmoderators、座長などがあり、その合間を縫って主として外国の会社の CEO達と打ち合わせがなされました 本当に忙しかったのです おまけに時差ボケです

自分の発表の模様は TCROSSというサイトに写真が掲載されていますので、画面コピーで貼り付けました

EuroPCR2016 presentation
EuroPCR2016 presentation
EuroPCR2016 presentation-2
EuroPCR2016 presentation-2

そう言えば昨年のこのEuroPCR 2015において僕は Kiemeneij先生と一緒に Ethica Awardという栄誉を受けたのです

それはそうなのですが、5/19の木曜日 3:00AM頃よりお腹が痛くなり、ついには 5:00AMになって激しい嘔吐、下痢そして多分発熱に見舞われたのです 明らかに何らかの食中毒です 潜伏期や食べた内容を考えても良く原因が分かりません 症状などはサルモネラ菌食中毒のように思います フランス料理レストランで食べたチーズに菌がついていたのかも知れませんが確証はありません その症状は結局 48時間後の今朝まで続きました 今はすっかり元気ですが、お蔭で皮膚もカラカラとなり、体重は大分落ちたように思います

phpMyBackupProによるSQL backup dataの文字化け

ついに見つけたツール phpMyBackupProは非常に優れたものです。完璧に SQLでバック・アップが可能なのです。本当に素晴らしいと思います。しかも、フリーでダウンロードできるのです。

ただ、日本語には対応していません。このため、backupしたデータの日本語が文字化けしてしまい、そのままでは使い物になりません。データベースには UTF-8の文字コードでデータが蓄積されているので、phpMyBackupProそのもののデータ読み書きを UTF-8にすれば良いわけです。少しプログラムを見ていくと、どうやら Latinという文字コードがdefaultとして設定されているのです。まあ、どうやらイギリスで開発されているプログラムなので、かの国ではそれが標準なのでしょう。しかし、日本語対応させようと思えば、SJISあるいはEUC-Jという文字コード、そして現在の流れとしては UTF-8に対応せねばなりません。

そもそも Latinという文字コードでは一文字が 1Byte = 8 bitsであらわされます。これに対して、UTF-8では基本的に 3Bytes = 24 bitsで一文字があらわされます。日本語では、文字の数が何万とあるので、情報量として3Bytes必要なのです。

phpMyBackupProで同様の悩みをかかえて、それを解決された方がおられるのでは? と探したところ、やはりありましたね。ここ(A)です

実は、もっと有望な解説も見つけました。それはここ(B)です。このサイトでは、何と日本語化した phpMyBackupProをダウンロードできるようにしていました。しかし、その versionが 2.1とあり、現在の version 2.3よりも古いのが少し気になります。

そこで、(A)を参考に、functions.inc.phpをエディタで開いて、その 636行目に以下の文を発見しました

        // select db
        @mysql_select_db($db);

ここに 2行を追加しました:

        // select db
        @mysql_select_db($db);
		$sql = "SET NAMES utf8";		// utf8に設定する
		$res= mysql_db_query($db,"$sql");

この簡単な追加により、見事に日本語データが文字化けせずにきちんと backupされ、downloadできるようになりました。もっとも、未だテスト段階ですので、このパソコンのローカルに設定した偽装インターネット環境での確認です。

そのようにしてダウンロードした SQL文を用いて、サーバー・データが破壊されても、再構築が完璧にできるか否かを検証したところ、問題がおこりました。

きちんと SQL文では日本語が文字化けせずにダウンロードできているのに、何故か SQL文を実行して再構築すると、データベース上のデータが文字化けするのです。これは変です。 SQL文を読んでもきちんと

DEFAULT CHARSET=utf8

と設定されているのです。そこで吐き出された SQL文を最初から見ると何とその最初に

# http://www.phpMyBackupPro.net

### used character set: Latin ###
set names Latin;

というのを発見しました。折角データをutf8で設定しているのに、肝心の書き込み段階で Latinに設定されているのです。これが原因でした。
それで、この部分の Latin -> utf8に変更したところ、見事に完全データ復旧ができるようになったのです。素晴らしいです。もう少しテストしてからサーバーに実際に uploadしてみます。何はともあれ、今度のサーバー障害により色々なことを学びました。失敗から多くを学び、発展させることができました。

ついに見つけたか

これまで PHP, MySQLを用いて Web上にデータベースを構築してきましたが、そのバック・アップには少し困っていました。

MySQL自体にバック・アップのためのコマンドを持っていますが、それを作動させるためには、コマンド・ラインから起動したりせねばなりません。つまり、まあだいたい LAMPでサーバーを構築していますから、L=Linux, A=Appache, M=MySQL, P=PHP or Perlなので、OSであるLinuxのシェルを直接起動できる権限を有していないとなりません。しかしながら、我々の用いているレンタル・サーバーでは当然のことながらこれは不可能です。
また、PHPより Sytem()コマンドなどで直接MySQLのコマンドを発行することもできますが、それも大概のレンタル・サーバーでは危険な命令語として、禁じられ、潰されています。
となると、最近のレンタル・サーバーには最初からインストールしてある、phpMyAdminという秀逸のツールを用い、その上でデータベースを選択し、エキスポート・コマンドによる SQL dumpを得る、それしか現実的な選択は無くなります。
もちろんこれでこれまでバック・アップしてきたのです。しかし、そこには問題があります。

  1. phpMyAdminを用いればデータベースの全てにアクセスできてしまうので、万が一操作を間違えば全てのデータベース消失という危険な事態になりかねない
  2. 従って、この操作権限を行使するためには、プログラミングについて相当の知識が無いといけない
  3. phpMyAdminの実行を自動スケジュールすることは困難である
  4. phpMyAdminの実行を自動化することも困難である

これらの問題点から 知らない人々からは「どうしてバック・アップを私たちにさせてくれないの?」 などという非難を浴びつつ、そんなこと説明するためにはどれだけたくさんの知識をあらかじめ教授せねばならないの? と、そんな非難を自分の中で噛み潰してきたのです。

次の解決法としては、PHPでデータベースにアクセスするプログラムを書き、データのみをテーブル毎にダンプして、それをバック・アップすることです。もちろんこのプログラム作成はそれ程大変な作業ではありません。しかし、問題点としては、データというものの概念の中に、データ同士の関係、という重要な意味がある、ということなのです。特に MySQLなどの SQLデータベースは、関係データベースと称されるように、個々のテーブルに蓄えられたデータの互いの関連が重要な意味を持っているのです。

このPHPによるデータ・バック・アップでは、個々のテーブルデータをダウンロードすることはできますが、関係そのものを記録することは困難です。そのためには、 SQLにより記述したデータベース構造が必要なのです。 phpMyAdminを用いれば、SQL dumpが可能ですので、個々のテーブルデータのみならず、SQLで記述したデータ構造をもダンプできるのです。従って、データベースから全てが消失してもデータベースの完全復旧が可能なのです。

先日の、サーバー・データ消失事件においても、僕がこの SQL dumpをしていたためにデータ復旧が可能だったのです。これに反して、”Where is Dr. Saito?”で用いていたデータベースでは、このバック・アップがされていなかったため、未だに復旧できていないのです。

前置きはさておいて、ついに見つけました。素晴らしいバック・アップ・ツールを しかも完全にフリーなのです。その名前は、phpMyBackupProです。試みにこれをダウンロードしてローカルにインストールしました。素晴らしい、の一言です。しかし、大きな問題が一つ、それは データの中の日本語が文字化けしているのです。

まあ、これはMySQLにアクセスする部分でUTF-8を指定するようにプログラムを書きなおせば済むでしょう。何しろ、この優れたツールは全て PHPで記述された膨大なプログラムなのです。ですから、その部分をエディタで探して、UTF-8指定を入れればいいでしょう。チャレンジしましょう。

サーバー再度の危機

TRI 20周年記念キャラバン初日、本来の予定では何も問題は起こらず、むしろ札幌の先生方とのTRIでの協調が促進され、素晴らしかったのです。

しかし、世の中そんなうまく行きません、それは07/02 17:15に起こりました。僕はこの札幌でメールを受け取りました。

「これまでのパスワードでログインできない」というクレームです。

そんな馬鹿な、そんなことあり得ない、と思いながら自分のパスワードでログインを試みましたが、確かにログインできないのです。

この時点で再び自分の頭の中は真っ白、「あーーーーー どうすれば」 「臨床試験データが無くなればどれだけの責めを負うか」など色々な思いが駆け巡りました。

既に時刻はこれからKiemeneij先生講演に向かう 18:30に近づいていました。それでも、瞬時に頭を巡らしました。「何が悪かったのが」、そして思い至りました。その直前、自分で書いたプログラムの改良のために、ある部分を uploadしていたのです。その中の configuration fileが現在の本当のパスワードでなく、昔の事故前のものになっていたのです。

それが原因でした。これに気が付き、すぐにそれこそ5分以内に修復したのです。危ない間違いでした。

やっぱりね

今 googleでニュースを見たところ、トップに今回のサーバー障害が掲載されいます。やはり非常に大規模な普通ではあり得ない障害だったようです。

詳細はこれを見て下さい。いや引用してしまいましょう。ヤフーの子会社だそうですね。ヤフーにとってもこれは痛手でしょう。きちんと対応しないと、これまで上り調子の Yahooの看板にも傷がつきそうですね。

ヤフー子会社でレンタルサーバを手がけるファーストサーバの大規模障害で、同社は6月23日、
共有サーバサービスとクラウドサーバサービスについて「データ復旧を行うことは不可能と判断した」
と発表した。専用サーバサービスも短期間でのデータ復旧は不可能とし、仮に復旧できたとして
も部分的にとどまるという。

 データ復旧を断念したのは共有サーバ「ビズ」「ビズ2」と、EC向けクラウドサービスの「
EC-CUBEクラウドサーバ マネージドクラウド」。「弊社ならびに外部専門業者を交え、データ復旧を
試み続けて参りました。しかしながら、極めて遺憾ではございますが、データ復旧を行うことは不可能
と判断いたしました」という。再構築は顧客が持っているバックアップデータで行うよう求めている。

 専用サーバ「エントリービズ」「エンタープライズ3」についても「短期間でのデータ復旧は不可能」
として顧客のバックアップデータで再構築を行うよう要請。復旧できたとして部分的なものにとどまる
上、復旧既刊は数カ月以上必要という。

 今後サービス約款に従って損害賠償を行うが、時期、や手続き、方法などは検討中という。同社の
レンタルサーバサービス約款では「本サービスが本質的に情報の喪失、改変、破壊などの危険が内在
するインターネット通信網を介したサービスであることを理解した上で」顧客が自らの責任でデータ
バックアップを行うものとし、顧客がバックアップしなかったことによる損害について同社は何ら責任
を負わないとしている(16条)。

 障害は20日午後5時以降に発生。大阪市の水族館「海遊館」や小林製薬の製品情報サイトなど多数の
Webサイトがダウンし、サイト上にアップロードされたデータやメールデータが消失した。影響した
顧客数は約5000に上る。原因は「メンテナンス作業において用いる特定の管理プログラムのバグ」
という。

しかし、管理プログラムのバグなんて、許せないですよね。しかも一番重要な専用サーバーがやられたのです。共有レンタルサーバーには障害が発生しなかったのです。何と 5,000サイトですよ。とんでもないことですね。

サーバー・トラブルその後

さてサンパウロからロンドンに飛行機で 12時間飛んでいる間、つまり日本時刻 6/23 12:00頃から 6/24 0:00AM頃にかけて 彼のレンタルサーバー会社から二本のメールが届いていました。その一分を掲載しましょう まずは一本目

     インターネットサーバ 障害復旧のお知らせ

平素は格別のご高配を賜り厚く御礼申し上げます。6月20日に発生いたしましたWEB・メールなどデータ
が消失したインターネットサーバー障害にて、多大なるご迷惑をおかけし誠に申し訳ございません。

ご利用いただいておりますサーバーにおきまして、障害発生時に消失したデータを復元いたしましたが、
不具合があることが判明したため、一旦メール受信・FTPサービスを停止し、サーバー修復作業を実施
いたしました。
現在はメール受信・FTPサービスの復旧を確認いたしております。
ご迷惑をお掛けいたしましたこと、深くお詫び申し上げます。

記

■障害時間  2012年6月22日(金) 午後 9:30 頃から
■障害復旧  2012年6月23日(土) 午前 4:43 頃まで
■障害内容  上記時間内において、メール受信操作やFTPサーバーへアクセス
ができない状況でございました。また、WEBサーバーは正常に稼働しておりました。
■障害原因  リカバリーデータの不具合

■対応経緯
1) メール受信、FTPサーバー機能の停止を行いました。
2) 6月20日以前のリカバリーデータより復元した、各アカウントのメール
データのみ削除いたしました。6月21日の再設定完了以降、各アカウント宛
に届いたメールにつきましては問題ございませんでした。
3) 「RECOVERED_FILES」ディレクトリでご提供しておりました、リカバリー
データにつきまして、不具合を発見したため削除いたしました。
4) メール受信、FTPサーバー機能を再開し正常稼働を確認いたしました。

6月20日から発生している障害状況のご報告つきましては、改めてお知らせいた
します。

引き続きサーバー設定の見直しを含め安定稼働をめざし調整を行ってまいります。

以上

全く、こっちが必死でリカバーしたのに、それを台無しにするようなリカバーを勝手にするんじゃないよ!! そして二本目のメールはもっと腹立たしいものです

            専用サービスをお使いのお客様へのお願いとご案内

平素は格別のご高配を賜り厚く御礼申し上げます。

6月20日に発生いたしましたWEB・メールなどデータが消失したインターネット
サーバー障害にて、多大なるご迷惑をおかけし誠に申し訳ございません。

障害発生以来、弊社ならびに外部専門業者を交え、データ復旧を試み続けて参
りましたが、極めて遺憾ではございますが、短期間でのデータ復旧は不可能で
あることが判明いたしました。

データ復旧にかかる期間が長期に及ぶことが判明いたしましたので、今後はお
客様からのご要望を元にデータ復旧作業を行わせていただきたく存じます。

データ復旧をご希望のお客様はお手数ですが、以下の内容を本メールの返信に
てお知らせください。あらためて詳細なご案内を差し上げます。

 -----------------------------------------------------------------
  契約番号 :
  契約者名 :
  ご担当者名:
  ドメイン名:
  連絡先電話番号:
 -----------------------------------------------------------------

※ご留意事項
  データを完全に復旧することは技術的に不可能であり、仮に復旧できた場
  合でも復旧データの精度、量は相当部分的なものにとどまるものと想定さ
  れ、復旧に要します期間につきましては数ヶ月以上要します。

お手数ではございますが、以下サイトにて詳細な情報をご案内しておりますの
でご確認ください。

どう思いますか? これではまるで脅しメールのようではありませんか
まあ、この会社もとんでもないことが起こってしまい、大変混乱しているのでしょう。だって今後大規模な損害賠償請求訴訟が当然起こるでしょうから・・・

サーバー復旧作業その後

何とかサーバー復旧しました。ひどい話です。突然全てのデータが完全に消失したのです。全てのデータとは

  1. ホームベージのデータ これにはhtml, css, Javascript, jQuery, cgiなどのデータやプログラムが含まれます
  2. 膨大なプログラム群 これにはPHP, Javascript, jQuery, SQLなどで書かれたプログラムがあります
  3. データベースに蓄えられたデータそのもの これはDatabase MySQLの中に格納されたデータです
  4. サーバーの各種設定 これにはデータベース接続、メール、FTPなどのユーザーネームとパスワードがあります

これら全てが一瞬にして無くなったのです。まずは4番から設定に入りました。そして、次に MySQLを開始させました。MySQLといえどもLinux Server上で走るプログラムの一つですのでまず走らせねばなりません。一旦走らせたらば、永久に走り続けるのです。そして、その MySQL上にバックアップしてあった 2012-05-23までのデータを含んだ SQL文を転送し、そしてSQLを実行しました。これでひとまずデータベースがその時点まで復旧しました。3の部分の復旧です。

次に行ったのは、2番です。膨大な主にPHPで書かれたプログラムを uploadしました。もともとサーバー側では PHPの実行プログラム (インタープリーター)が走っていますので、それでもう書いたプログラムが走り始めました。

最後にしたのは 1番です。これでブラウザからアクセス可能となりました。

ここまでの作業は正直それ程時間がかかる作業ではなく、主に uploadにかかる時間に依存します。つまり回線速度に依存しました。だいたい 1時間ぐらいでした。

問題はそれからでした。5-24から6-20までに登録されたデータがあります。この中で重要なものは、無作為割付を含んだ症例です。幸いプログラムが、登録があれば、あるメルアドに「登録がありました」という情報を送るようにしてありました。もちろん個人を同定できる情報は含まれません。このメールは消去せず蓄積していましたので、そのデータを用いて症例登録をすることにしました。

ただ、このためにはデータベースの色々なテーブルを参照しながらデータを作成せねばなりません。とても手作業でできる仕事ではありませんので、そのように PHPでプログラムを書かねばなりませんでした。時差ボケの中、しかもインターネット接続が不安定の中、大変な作業であり、効率の悪いものでしたので、これに 10時間ぐらいがかかってしまったのです。

そしてようやく出来る範囲最大限のデータ復活を成し遂げました。次に行ったのは、それらのデータが復活したことを、登録して頂いた先生方にメールで知らせることでした。これも手作業でできる仕事ではありませんので、プログラムを書かねばなりませんでした。自動的にメールを発信するプログラムは結構難しいのです。それでも2時間ぐらいで完成し、走らせました。

もう少しチューニングが必要かも知れません。何れにしても大変な経験をしました。バックアップを毎日のように取る必要があるかも知れませんね。