Hello Mercedes,
If you wish to replicate all relevant data from one AtoM installation to another, here the 3 primary elements you will want to consider copying over to the new instance:
- The database: this is the primary data source
- The uploads directory: this is where any uploaded digital objects, as well as institution logos and banners are stored
- The downloads directory: this is where any uploaded or generated finding aids, as well as cached XML, is stored
There are also some additional considerations, such as:
- The default installation culture: this value is stored in apps/qubit/config/settings.yml. Make sure it is the same between the two instances!
- Custom themes and images: If you have a custom theme plugin, you will need to copy it over as well. Additionally, if you have added images to your server for use in the home page or other static pages, you will need copies of those on the new server as well, so your static pages render correctly.
- The search index: It is not necessary to copy this - you can run the command line task to repopulate the search index on the new site. However, depending on the size of your database, this can take some time to run. If you want to avoid any downtime, you can copy the search index from one instance to the other.
For our Premium+ hosted clients at Artefactual, we offer a 2-site deployment model - where there is a public facing read-only site, and an internal read/write edit site. Data is copied from the internal site to the public site using a replication script, which offers several advantages, such as:
- Better security: login is completely disabled on the public facing site; the internal edit site can be configured behind a firewall etc.)
- Better control over visibility: some entity types such as authority records do not have a publication status to hide them as drafts from the public - however, with the replication script, users can control when new data is copied to the public site
- Better scalability: aggressive caching can be used on the public facing site; and there are no write edits taking place. Meanwhile the internal site is not having to constantly serve end user requests.
- No downtime when repopulating the index: because we copy the entire search index at once, there is no wait time while the site repopulates.
We make the script we use for this service publicly available - it is an
Ansible deployment script that our community is welcome to use. See:
Regards,