Back up of dcm4chee-arc-light (non-container)

[Jonathan Brooks]

Hi,

I'm trying to put together a sensible back up plan for our DICOM server (not a containerised version) and wondered if anyone has any advice on how to achieve the following:

(Q1) what to backup to allow rebuilding DICOM server in the event of catastrophic failure?

Is a tarball of the dcm4chee-arc-light, wildfly and keycloak folders, plus OpenLDAP and MySQL sufficient?

(Q2) what to backup on a daily/weekly basis to allow recreation of the database in the event of a _less_ catastrophic failure? E.g. say I installed new version of MySQL and it broke something, and now I want to go back to the previous version.

(Q3) Of course the most important of all is the DICOM data itself! I want to arrange a system around ONLINE, NEARLINE, but am a little unsure of how to configure this...

 

E.g. our archive is configured to use as dcmStorageID : "fs1", as soon as data lands there I would like to it be mirrored to another dcmStorageID : "nearline". 

This is described here, so I can see how to create a new storage location e.g. "nearline", but I'm not sure how I would trigger the copy of existing data to nearline?

(Q4) What steps are required to have the data be retained on "fs1" for 6 months, and then after that time, be only retained on "nearline" - to be retrieved as necessary? Does one of the storage areas (fs1) need to be identified as CACHE?

Best wishes,

Jon

 

[Jonathan Brooks]

Some more digging exposed my confusion! And answered some of the questions (2nd part of Q3 and Q4)

Cheers, Jon

On Friday, July 1, 2022 at 5:47:04 PM UTC+1 Jonathan Brooks wrote:

Hi,

I'm trying to put together a sensible back up plan for our DICOM server (not a containerised version) and wondered if anyone has any advice on how to achieve the following:

(Q1) what to backup to allow rebuilding DICOM server in the event of catastrophic failure?

Is a tarball of the dcm4chee-arc-light, wildfly and keycloak folders, plus OpenLDAP and MySQL sufficient?

(Q2) what to backup on a daily/weekly basis to allow recreation of the database in the event of a _less_ catastrophic failure? E.g. say I installed new version of MySQL and it broke something, and now I want to go back to the previous version.

(Q3) Of course the most important of all is the DICOM data itself! I want to arrange a system around ONLINE, NEARLINE, but am a little unsure of how to configure this...

This source refers to the use of LDAP to import configuration into archive. 

  version: 1
  dn: dcmStorageID=nearline,dicomDeviceName=dcm4chee-arc,cn=Devices,cn=DICOM Configuration,dc=dcm4che,dc=org
  dcmInstanceAvailability: NEARLINE
  dcmProperty: pathFormat={now,date,yyyy/MM/dd}/{0020000D,hash}/{0020000E,hash}/{00080018,hash}
  dcmProperty: checkMountFile=NO_MOUNT
  objectClass: dcmStorage
  dcmStorageID: nearline
  dcmURI: ${jboss.server.data.url}/nearline/

OK: CREATES a new dcmStorageID/dcmURI

  dn: dcmExporterID=CopyToNearlineStorage,dicomDeviceName=dcm4chee-arc,cn=Devices,cn=DICOM Configuration,dc=dcm4che,dc=org
  dcmExporterID: CopyToNearlineStorage
  dicomDescription: Copy to NEARLINE Storage
  dcmQueueName: Export5
  objectClass: dcmExporter
  dicomAETitle: DCM4CHEE
  dcmURI: storage:nearline

??: CREATES a new QUEUE that targets the nearline storage??

  dn: cn=Copy to NEARLINE Storage,dicomDeviceName=dcm4chee-arc,cn=Devices,cn=DICOM Configuration,dc=dcm4che,dc=org
  dcmExporterID: CopyToNearlineStorage
  dcmDuration: PT1M
  dcmEntity: Series
  dcmProperty: SendingApplicationEntityTitle=NEARLINE
  objectClass: dcmExportRule
  cn: Copy to NEARLINE Storage

??: CREATES a new copy ?method? for copying data to nearline??

Slightly lower on that page is a section that talks about creating another QUEUE (for archive > 5.24.0) - still using LDAP

    dn: dcmQueueName=Nearline Storage Export,dicomDeviceName=dcm4chee-arc,cn=Devices,cn=DICOM Configuration,dc=dcm4che,dc=org
    dcmPurgeQueueMessageCompletedDelay: P1D
    dcmRetryDelay: PT30S
    dcmMaxRetries: 10
    dicomDescription: Nearline Storage Export Tasks
    dcmQueueName: Nearline Storage Export
    objectClass: dcmQueue
    dcmRetryDelayMultiplier: 200
    dcmMaxRetryDelay: PT10M

Is this intended to replace/supplement the queue section in the section above (in BOLD)??

 

E.g. our archive is configured to use as dcmStorageID : "fs1", as soon as data lands there I would like to it be mirrored to another dcmStorageID : "nearline". 

This is described here, so I can see how to create a new storage location e.g. "nearline", but I'm not sure how I would trigger the copy of existing data to nearline?

Think this is probably answered here

 

(Q4) What steps are required to have the data be retained on "fs1" for 6 months, and then after that time, be only retained on "nearline" - to be retrieved as necessary? Does one of the storage areas (fs1) need to be identified as CACHE?

Think this is probably answered here 

Best wishes,

Jon