OsiriXを用いたPACSバックアップシステム(4)
簡単なしかけで構築できるのはよいんだけど、やはり最大の問題はデータ量があふれた場合です。勿論50GB単位でzipを分割すればいいんだけど、運用上週に一回しかメディア交換に行かないとなると2枚に分かれるとその週だけ2回行か […]
OsiriXを用いたPACSバックアップシステム(3)
さてあとはデータをまとめてBD-Rに書き出すだけである。WIindowsではBDドライブについてきたPowerBackupというソフトにスケジューラがあったのでこのスケジューラを利用して書き出しを行っていた。この点Macの方が簡単である。Cronで前エントリのディレクトリ切り替えを行いこれに引き続いて書き出し処理をすればいいだけだからだ。問題は…Windowsでもそうだったのだけど、コマンドラインでBD-Rに書き出す方法である。検索してみるとhdiutilというコマンドがあるらしい。これでディスクイメージの制作もできるのでディスクイメージの作成と焼き付けを行う。
もしこのメディアをMacでしか扱わないのであればdmg形式で作成すればよい。自動的に圧縮がかかるのでBDRをドライブに入れれば(反応はおそいものの)OsiriXでそのままアクセスできる。
ウチの場合、このメディアが必要になるときと言うのは何らかの原因でメインサーバが壊れたりストレージが消失した状況で、相当に混乱している可能性がある。なんだかんだといってもMacが多数転がっているわけではないので必ず読めることを優先してiso形式にした。またメディア不良で書き込みエラーの可能性もあるので手動作業でもできるように引数でデータベースディレクトリを選択できるようにした。圧縮にはzipを使っているがこの一時ファイルはすぐに削除。デイスク
#!/bin/csh#引数処理ルーチン
switch ($#argv)
case 0:
set source="DICOM2"
echo "DICOM2 is the sourcefile"
breaksw
case 1:
switch ($1)
case 1:
set source ="DICOM"
breaksw
case 2:
set source="DICOM2"
breaksw
case 3: set source = "DICOM3"
breaksw
case 4:
set source = "DICOM4"
breaksw
case 5:
set source = "DICOM5"
breaksw
default :
set source = "DICOM2"
breaksw
endsw
breaksw
default :
set source="DICOM2"
breaksw
endsw
set workdirectory = "/Volumes/DATA"
cd $workdirectory
set currentdate = ` date +'%Y%m%d%H%M%S'`
set targetname = $currentdate".iso"
set targetzip = ${workdirectory}"/temp/"${currentdate}".zip"
if ( ! -d ./temp ) mkdir temp
set targettar = ${workdirectory}"/temp/"${targettar}
echo $targetzip "を作成します"
zip -qr9 $targetzip $source
##making iso image
hdiutil makehybrid -o $targetname temp -iso -udf -udf-volume-name $currentdate
set devicename = `hdiutil burn -list | grep "USB" | tail -n 1 | sed -e "s/^.//"`
echo $targetname "をBD-Rに書き込みます"
#echo "BD-Rは"$devicename"です”
#hdiutil burn -device "${devicename}" $targetname
drutil burn $targetname
echo "BD-R 書き込み終了しました。"
@ isonumber=`ls *.iso |wc -l `
echo "ISO file count=" $isonumber
ls -la *.iso
while ($isonumber >5)
set deletefilename = ` ls *.iso |sort | head -n 1`
echo "delete file name is " $deletefilename
rm $deletefilename
echo $deletefilename"を削除しました"
@ isonumber = $isonumber - 1
end
echo "テンポラリファイルを削除します"
rm -drf ./temp
drutil tray close
実際の焼き付けにはデバイス指定がhdiutilではかなり複雑なのだけどdrutilを使うと簡単なのでこちらを使うように変更した。
あとは2つのスクリプトをweeklyとでも名付けたスクリプトにまとめてcrontabに登録すればよい。
OsiriXを用いたPACSバックアップシステム(2)
さて従来使ってきたConquestであるが、そもそもこれを採用した理由は複雑なDBを用いずに特定のディレクトリにデータを蓄積してくれるからである。これは1週間ごとにデータをまとめるのに都合がよい。データディレクトリのひな形を作っておいてこれをコピーしてやればすぐにデータが空の状態に戻る。つまり1週間ごとにデータディレクトリの名前の変更をOSレベルでおこなえばアプリケーションは切り替えのタイミングで一時停止するだけでよい。いつデータが転送されてくるかわからないPACSでは停止期間は可能な限り短くしなければいけないからだ。
OsiriXもローカルファイルでデータベース管理しているので全く同じ方法が使える。
受信データフォルダをDICOMとすると、 #!/bin/cshcd /Volumes/DATA
# 全体のデータディレクトリ
#-----------------------
#rotate data directories
# 一番古いものを削除
if (-d DICOM5) rm -drf DICOM5
# Stop Osirix
set ospid=`ps axu | grep "/Applications/OsiriX.app/Contents/MacOS/OsiriX" | grep -v "grep" | awk '{print $2}' `
if ( ${ospid} != "") kill $ospid
#rename directories
if ( ! -d DICOM5) mv -f DICOM4 DICOM5
if ( ! -d DICOM4) mv -f DICOM3 DICOM4
if (! -d DICOM3 ) mv -f DICOM2 DICOM3
if (! -d DICOM2 ) mv -f DICOM DICOM2
#ひな形の空のデータディレクトリをコピー
if (! -d DICOM ) cp -R DICOM.org DICOM
#---------------------------
#restart Osirix
/Applications/OsiriX.app/Contents/MacOS/OsiriX &
これで先週はDICOM2、先々週はDICOM3… と週ごとのデータベースに分かれるのだ。あくまでこれはデータ送信のタイミングに依存しているので厳密には検査日時と一致しない。後処理に時間がかかるものや持ち込みデータの登録などタイミングがずれるものもあり得る。したがってQ/Rの結果とは違うことを理解しておく必要がある。
OsiriXを用いたPACSバックアップシステム(1)
今時はフィルムレスは当たり前、PACSがなければ仕事にならない。10年前とすっかり状況は変わってしまった。
そして今日的なPACSはすべてHDDベースで動いている。その昔はMOチェンジャーやCD-Rチェンジャーでデータ保管されていたが今はすべてがハードディスクである。HDDは壊れるものであるから当然のごとくRAIDシステムが組まれデータの冗長化がされている。どの程度冗長化すれば安全か、これには答えがない。結局のところコストとの兼ね合いでしかないのだから。そもそもハードウエアによらずとも人為的なミスでもデータ消失は起こりうる。むしろこちらの方が危険かもしれない。
いずれにせよハードディスクは高速大容量で比較的安価で便利な代物であるがデータを失うときは一瞬である。
現在ではフィルムレスであるが故にデータが失われてしまうと診療に多大な影響がでるので何らかのバックアップシステムが必要である。
サーバ・ストレージの冗長化、オフラインメディアへの保管あるいは今時であればクラウドを用いた保管なども考えられる。
ブルーレイメディアを利用した安価なバックアップシステムは、実際の故障確率の低さを考えれば万が一の保険としての価値があろうと思われる。
まぁ、実際のところ5年ほどConquestベースのシステムで運用してきて、これが必要になったことはないので、まさしく万が一の保険というものであろう。
今回、全く別の要因でConquestベースのシステムに不調を来したので一念発起してOsiriXベースにシステムを作り直した。
必要なハードはMac-mini(256SSD+750HDD)とUSB外付けのBD-Rドライブのみ。ソフトウエアはOsiriXと自作スクリプトのみなので安価といって差し支えないだろう。
従来からのConquestベースのシステムでも運用方法は同じである。1週間分のPACSデータをメインサーバからfowardして週末にこれをまとめてBD-Rに書き出す。週明けに技師がメディアを交換して書き込まれたメディアはファイルに保管する。
ウチの病院では1週間のデータ発生量は非圧縮で50-70GB程度であるので(年々増えつつある)適当に圧縮してやれば二層のBD-Rに収まるという寸法である。
と前置きが長くなった。
参考にしようという方もおられるかもしれないので記録をかねて残しておきます。詳細は次のエントリで。
07/22のツイートまとめ
- kosukesakurai
読影終了。なんだか1件転送漏れがあるみたいだけど、もうやめる。
07-22 20:59この時間はネットが重いなぁ。
07-22 18:46車両情報で警察の情報ってことはNシステムのことなんだろうか。これの漏洩だとしたら結構深刻。
07-22 18:21売れるのか。あれが。まずいと思うけど(個人的感想です)いろんな人の意見では「飲めないこともない」という人もそれなりにいた。熱狂的愛好者は昔からいる。
07-22 13:50Now browsing: アニメ・ゲーム登場商品に見る経済効果-「ドクペ」出荷は飛躍的増加に - アキバ経済新聞 http://t.co/sAwZEnco
07-22 13:48
xfyBlogEditor
いったい何周遅れなんだかよくわからないけど。
ようやく今頃になってXFYで簡単に画像のアップロードができるのがわかった。
こうしてみると結構良くできたブログエディタだ。今頃評価しても遅すぎるんだけど。
ジャストシステムがユーザに個人用無料で提供してくれているブログエディター。オフラインでも書けるので通勤電車の中で書いたりできそうで試しにちょこちょこ使っている。でも通勤電車の中では、ちょっと正確を期すために調べたいな、とかいうときに調べることができない。WILLCOMでは遅くてイライラするし、そもそも地下鉄では駅近くしか通信不可。使い方がまだよくわかっていないところもあったりするし。サーバへの登録を忘れ..
xfyBlogEditor
07/20のツイートまとめ
- kosukesakurai
結局ZIPの圧縮パラメータ調整では0.1GB程度しか差が出ないことが判明。いろいろ考えたが、OsiriXで受信時にロスレス圧縮をかけるように変更した。どうせメインサーバでもロスレス圧縮してるし。データ領域と作成したディスクイメージの履歴で5週程度置くためには必要。
07-20 09:40
07/20のツイートまとめ
- kosukesakurai
結局ZIPの圧縮パラメータ調整では0.1GB程度しか差が出ないことが判明。いろいろ考えたが、OsiriXで受信時にロスレス圧縮をかけるように変更した。どうせメインサーバでもロスレス圧縮してるし。データ領域と作成したディスクイメージの履歴で5週程度置くためには必要。
07-20 09:40