(I think this is the best place to put the topic, but if not so please replace it)
I mentioned it earlier in some other topics and cannot stress the topic of backup enough. Especially when you are using the PacsOne system as we do in our institute.
Have you ever thought of how much of the data you can recover after a HD crash or a simple delete of a patient on the PacsOne system? Or when the MySQl tables get corrupt and cannot be repaired/recoverd? We did and came to the following setup.
In our institue we use the PacsOne server for a while in the freely downloadable trial version and really appreciate it. We therefore decided to buy the license.
In order to have a high up-time and redundacy when (parts of) the system fails (either hardware like harddisks or some of the software like MySQL it uses) we also take a good look at our configuration. We need this high up-time and redundancy because of the central position the machine has in our institute. All CT, MR,CR, PET and DICOM-RT will be received and stored by the PacsOne system for the upcoming years.
As the databases is stored in a MySQL table we started looking for ways of backing-up the data. Diving in to the MySQl manual we found the following entries that are related to this.
A few MySQL utilities that can be used:
- MySQL dump (MySQL manual section 8.8: http://dev.mysql.com/doc/mysql/en/mysqldump.html)
The mysqldump client can be used to dump a database or a collection of databases for backup or for transferring the data to another SQL server (not necessarily a MySQL server). The dump will contain SQL statements to create the table and/or populate the table.
MySQL hotcopy (MySQL manual section 8.9: http://dev.mysql.com/doc/mysql/en/mysqlhotcopy.html)
mysqlhotcopy is a Perl script that was originally written and contributed by Tim Bunce. It uses LOCK TABLES, FLUSH TABLES, and cp or scp to quickly make a backup of a database. It's the fastest way to make a backup of the database or single tables, but it can be run only on the same machine where the database directories are located. mysqlhotcopy works only for backing up MyISAM and ISAM tables.
Therefore we chose for a setup with replication. (MySQL manual section 14: http://dev.mysql.com/doc/mysql/en/Replication.html)
With this setup there is a master and at least one slave MySQL server. The master is the server that recieves the images and the slave is a seperate mysql server on another host. The master also holds the PacsOne executables and provides the web interface.
One of the benefits of replication is that it is ran from the slave side and not from the master side and therefore the master does not need to be locked in anyway. The master server keeps track of all the changes in its database using a so called binary log file (MySQL manual section 5.8.4: http://dev.mysql.com/doc/mysql/en/Binary_log.html).
The slave or replication MySQL server, which is actually a client of the master server, downloads this log file and executes the MySQL statements which are recorded there in its own database. (For testing one of the slaves even runs on my desktop PC which makes testing much easier).
A strong pro for this situation in my opinion is that when a sever system failure occurs on the master server which brings it offline for a long while it is not much effort to change the slave/replication server in to the master server. Just install the PacsOne server there (Be aware don't drop the tables... else all effort is worthless because all the data is removed anyhow! Why isn't this option switched off by default in the installation setup? It would be much saver to explicitly select the database to be droppped when installing the PacsOne server. Maybe some option to change in newer setup releases?)
Now all the data recieved is still available. Changing hostname (because of the server name being hardcoded in the license) and IP address to the vacant one of the master also enables it to recieve images from other DICOM modalities again without changing enything else on the clients.
The second advantage is that we can do the real backup (dumping the MySQl tables) of the data and therefore locking of tables/databases (which caues temporarily unaivalability of this slave/replication server) on the slave server keeping the master up. This server can be locked for a while because replication will pick up when the slave/replication server is ready again after we release the locks. Even if the backup failes and completely locks up or freezes the system the master is still up and receiving images. We than (just) need to find and fix the error)
For backing up my data we use the excellent and highly configurable backup script that can be found here (http://worldcommunity.com/opensource/ut ... ackup.html)
This script allows you to configure backups to be made in several ways, use compression of the backup, a rotation scheme and even make s it possible to email you the status report, including if you want the backup as attachement. It runs on Linux as well as on Windows (although you need to install Perl and some Unix utilities on windows systems). This is also nice because of the PacsOne being available for both systems, now you only need one solution for two platforms.
(The backup script is able to compress at a high ratio because of pure MySQL output being a text file whit a lot of repeated statements. The total amount of diskspace taken up by the tables is about 60MB, in .sql files this is about 150MB and compressed with tar and gzip a little bit under 4MB. Bare in mind that this is only the MySQL information and that the backup contains no DICOM images.)
The backup of the real DICOM data is taken care of in an other way, the recieved data is directly written to a storage unit with several TB's of storage facility (yes indeed we mention therabytes: 1 TB = 1000 GB = 1000000 MB). Data stored on this storgae system cannot be deleted for years to come so we have not to bother about losing our data only maintaining access to it.
This storage system archives the DICOM file and leaves a kind of shortcut in the DICOM storage direcotry which makes it possible to recover archived images.
All togehter it was not easy and took some time figuring out how to make it work. Going in to details here would go rather far but when you are interested and are trying to do it yourself feel free to ask. I might have time ot help/point you in the right direction. However with a good read/search of the MySQL manual and using Google you can come a long way I discoverd.
Our final implementation looks like this:
1 MASTER server (dedicated):
- Pacsone 2.1
MySQL 4.0.x (will be upgraded to 4.1.x soon)
PHP 4.3.x
Apache 2.x
Windows 2000 server
- MySQL version 4.0.18 (will be upgraded to 4.1.x soon)
ActivePerl 5.6.1.638
MySQL backup script 3.1
Windows 2000 server
- MySQL version 4.0.18
Windows XP SP2
- Commercially available storage unit
Jonathan
