Mercurial > hg > orthanc-book
view Sphinx/source/users/backup.rst @ 1013:ab270400aae1
python: overriding core API
author | Alain Mazy <am@osimis.io> |
---|---|
date | Tue, 09 Jan 2024 11:50:17 +0100 |
parents | c10fc0838f58 |
children |
line wrap: on
line source
.. _backup: Backup ====== The way to backup Orthanc depends on the database back-end that is used. In any case, you of course have to backup your :ref:`configuration file <configuration>`. SQLite ------ By default, Orthanc uses SQLite to store its database. In this case, all the DICOM files together with the SQLite index are stored directly in the filesystem. The backup procedure works as follows: 1. Stop Orthanc. 2. Copy the following 3 elements: * Your configuration file. * The DICOM files (by default, the subdirectories of the ``OrthancStorage`` folder next to the configuration file). * The SQLite index (by default, the ``OrthancStorage/index*`` files next to the configuration file). 3. Restart Orthanc. It is recommended to stop Orthanc, as the Orthanc core makes the assumption that it is the only process to access the SQLite database at any time. Karsten Hilbert provided us with a `sample backup script <https://github.com/jodogne/OrthancContributed/blob/master/Scripts/Backup/2014-01-31-KarstenHilbert.sh>`__ for the official Debian package of Orthanc that automates this backup procedure. Note that in this script, the call to the SQLite command-line tool is used to force the `WAL replay <https://www.sqlite.org/wal.html>`__. This manual replay should not be necessary for Orthanc >= 0.7.3. PostgreSQL and MySQL -------------------- The default SQLite engine is well adapted for DICOM routing or for image buffering tasks, but not for enterprise scenarios. In such cases, you are highly recommended to use the `PostgreSQL back-end <https://www.orthanc-server.com/static.php?page=postgresql>`__ or the `MySQL/MariaDB back-end <https://www.orthanc-server.com/static.php?page=mysql>`__. If using PostgreSQL, you can do hot backups (i.e. while Orthanc is running), and you benefit from all the flexibility of PostgreSQL backup. These procedures are out of the scope of this manual. Please check the `official backup and restore manual <https://www.postgresql.org/docs/devel/backup.html>`__. Similar backup procedures are available for MySQL and MariaDB as well. Please check the official manual about `database backup methods <https://dev.mysql.com/doc/refman/8.0/en/backup-methods.html>`__. Here are some contributed documents: * `Backup for Windows 10, Orthanc and PostgreSQL plugin <https://blog.goo.ne.jp/wakida_ortho/e/3eb557fd134cf6136d5ba66cf72fd85a>`__ (in Japanese, 2020-02-02). Restoring backups ----------------- You should always stop Orthanc while you restore the DB backup. You may run Orthanc while the storage (DICOM file) backup is being restored but you should expect to have some data unavailable. Data consistency ^^^^^^^^^^^^^^^^ If you are running backups on a running system, it is very likely that your DB backup won't happen exactly at the same time as your storage backup (the DICOM files). After you've restored your backup, you'll likely need to resend e.g. the last 24 hours data from the modalities to make sure the data that was not included in the backup is pushed to Orthanc again. When new data is pushed to Orthanc, it is recommended to have the ``OverwriteInstances`` set to ``true`` to force Orthanc rewrite files for instances that were in the DB backup and not on the storage backup. This kind of recovery might create orphan files in the DICOM storage (files that are not referenced by Orthanc anymore). As of 2023, there is no script/procedure available to delete these orphan files.