現在、検査・内視鏡・病理のデータは 2 つの ubuntu に同じものが別々に記録されており、どちらかのサーバーがダウンしても別のサーバーを使ってデータを閲覧することができます。
サーバーがクラッシュ・ダウンすることは想定されることであり、クラッシュすればサーバーが一つだけではデータを閲覧することができなくなり、かなり不自由な思いをすることになります。
そのためには全く同じ内容のデータベースとアプリケーションが動いているサーバーが少なくとも 2 台は必要です。
2 台あれば 1 台がクラッシュした場合は、なるべく早く 2 台に戻すようにすれば、データを全く閲覧できなくなる可能性をかなり低減できます。
現在の ubunt server
現在、ubuntu server は検査・内視鏡・病理のデータを保存しています。
データベースは sqlite3 です。
現在、mysql に移行中です。
それぞれの ubuntu は独自にデータを集めるようになっており、それぞれ深夜の 23:30 と 24 :00 に synology NAS に向けて、すべてのデータベースをアップロードするようになっています。
dcm4chee も複数設定
dcm4chee も複数設定するのは可能かと思います。
現在、病院にあるのは QNAP の NAS と Synology の NAS ですが、これらを rsync することは可能だと思います。
問題はデータベースです。
mysql のレプリケーションは、以前実験したところではとても不安定でした。
理論的には、mysql のエクスポートをしてダンプファイルをコピーし、コピー先でインポートすればいいのですが、dcm4chee のデータベースがかなり大きくなるので、それなりに時間がかかると思います。
ダンプファイルがどれくらいの大きさになるのかわかりませんが、巨大であればリアルタイムのデータベースのアップデートは諦めて、深夜帯を使ってデータベースの同期をすればいいのではないかと思います。
そうすれば、少なくとも 1 日前までは戻れます。
dicom ファイルの保存先である NAS も ubuntu server 上のデータベース（pacsdb と arrdb）も 2 台あれば、より安定した dicom サーバーが提供できると思います。
dcm4chee のバックアップを諦める
私は dcm4chee の大きなダンプファイルは作成したことがないのですが、実際にバックを実行しているレントゲン技師さんの話では 100 MB もないような大きさでも、数十分かかったそうです。
今ではその 10 倍にもなり、これは今後増えていくことを考えると、バックアップしてインポートというのは無理と思いました。
dcm4chee は多分無駄に大きすぎます。
別の方法を考える必要があります。
