Migrate to a new location

Install, Configure and Update
7

There are multiple options, including one in which you would

  1. on the old server, archive all projects
  2. transfer the database from the old server to the new server
  3. on the new server, unarchive all projects

and in which you could preserve your project UIDs. This approach, however, is subject to some possible pitfalls. For example:

  • you would need to transfer your database to the new master host in a valid way, either via restoration of a database backup or a valid copy of the database directory.
  • for each individual project directory, you would need to ensure that the correct directory with unchanged contents is associated with the correct project during unarchiving. As of CryoSPARC v4.3.1, one might not be prevented from linking a project directory to the incorrect project, with database and project directory corruptions the likely outcome.

For these reasons, I recommend the following approach:

  1. Do not start the migration process before having understood the following steps in their entirety.
  2. Stop all CryoSPARC work on the old server/instance.
  3. Collect and preserve the output of the command
    cryosparcm listusers.
  4. Collect and preserve the output of the command
    cryosparcm cli "get_scheduler_targets()".
  5. For each cluster lane, collect the output of the command
    cryosparcm cluster dump in separate directories.
  6. Backup the database and store the backup in a safe place. In the best case, the backup will never be needed, but when was the last time everything went 100% according to plan?
  7. Detach each attached project from the old instance.
  8. Permanently shut down the old instance.
  9. After new absolute paths to software directories have been settled, install and start CryoSPARC master software on the new server. You may reuse your old license id provided the old instance is permanently shutdown.
  10. Similarly, install cryosparc_worker software.
  11. Connect workers with reference to information collected earlier, potentially using edited (“worker_bin_path”) copies of the cluster_info.json and cluster_script.sh files dumped earlier.
  12. Create users with reference to the users list collected earlier.
  13. Attach to the new instance project directories that were earlier detached from the old instance.
  14. If needed, adjust symlinks for each project. Alternatively, you could ensure that the absolute paths to “outside-of-project” files do not change, possibly (untested by myself) with the help of directory symbolic links.