Transfer of active Dicom Server to new Windows Server

    Hi Marcel

    I search for a way to delete mag devices from the SQL-Database (mySQL) of a daily working Conquest Dicom Server (1.4.17d) .

    This server uses 15 Mag device folders on 6 SAN disks. The data has to be transfered to an new Windows server.

    The idea is

    1. unplug the disk with the eldest data (since 2006)
    2. plug it to the new Windows server. There is a new installation 1.4.19d1 with SQL-Lite
    3. create the entries in the new database with the button "regen single device"
    4. on the old server delete the database entries linked to the unplugged data
    5. delete the entry for the deleted mag device in dicom.ini
    6. repeat from step 1 until the last disk is transfered

    In forum searches I found 6 threads with simular solutions, but no solution for deleting only database entries linked to a specific mag device.
    Has anyone an idea for step 4?

    Thank you

    Hi,


    This would likely work and you can script step 4 in Lua (using dicomdelete using the internal DICOM tag for MagDevice). How many images do you have and is SqLite good enough - a power failure may corrupt the database; so I would not use it for such a large production system.


    I would probably backup the database and restore in the new server using mySQL or MariaDB.


    Can you map the SAN disks on the old server to the new one and vice-versa?


    Then you can just play with the MAG locoations in dicom.ini in the new server to first pointing to the old server and then to the new. You can also use MIRROR devices in case you have multiple copies of some of the data or to help the old server find the data in the new server whike migrating.


    I assume the old server must remain live? Is it being written in while migrating?


    Marcel

    Hi Marcel,

    thank you for your prompt answer and primarily for this great project.

    The planned transfer is a chance to reduce the database size of the new and the old dicom server.

    Since a couple of years Exportconverters send all input to PACS and some modality to other dicom ports. Members in the group have file access with reading authorization to the Mag Devices.

    The directory format is structured in dicom.ini: PatientID/Modality/Date+Sender/.....

    So it is possible to get all old data without dicom transfer.

    That means: before every repeat of my steps (1. to 6.) I want to shift the just produced directory to separate SAN Disks (again with read access to the outsourced files) and then to clear the new dicom server. At last only Mag0 and the newest mag for nightly move will be used in the new Dicom server (1.5.0) - then likely with MariaDB or MySQL.


    Answers to your Questions:

    • Can you map the SAN disks on the old server to the new one and vice-versa?
      • It should be possible for our IT.
    • I assume the old server must remain live? Is it being written in while migrating?
      • Yes, it's a distributing system together with the pacs. When the data of both conquest systems are nearly synchronous it will be possible to connect the senders to the new server or directly to pacs step by step.

    Ok,


    then you could connect the two servers and setup MIRROR disks e.g.


    S1

    MAG0=data (on S1)

    MIRROR0=S2\data

    ..


    S2

    MAG0=data (on S2)

    MIRROR0=S1\data

    ..


    That avoids having to clear the old database at all, the old server will just find the disks you moved on the new server on the mirror. In the mean time you can regen parts of the new server to built the new database.


    I assume you have something like:


    ImportConverter0 = STORAGE MAG7


    to make sure new data is not stored on old disks.


    Marcel

    It's new for me that I can prevent storing on old MAG with

    ImportConverter0 = STORAGE MAG7.

    So I have to add a line in dicom.ini (old server):

    ImportConverter2 = STORAGE MAG14.

    As I understand it then new data will be written to MAG0 and nightly move will be stored only on MAG14 or higher.

    Is this correct?

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login