Difference between revisions of "Upgrading between EPrints 3.4 versions"
m (→General Advice) |
(→General Advice) |
||
| Line 13: | Line 13: | ||
; The current EPrints codebase | ; The current EPrints codebase | ||
: In case any changes have been made to this. These may be needed if you have to rollback an upgrade or also apply these changes if they are needed in the upgraded version of EPrints. All directories in the EPrints path (e.g. /opt/eprints3/ or /usr/share/eprints/) should be backed up '''except''': ''archives'' (see above), ''debian'', ''license'', ''pod'', ''testdata'', ''tests'',''tmp'' and ''var''. No files in the top level EPrints path directory need to be backed up. | : In case any changes have been made to this. These may be needed if you have to rollback an upgrade or also apply these changes if they are needed in the upgraded version of EPrints. All directories in the EPrints path (e.g. /opt/eprints3/ or /usr/share/eprints/) should be backed up '''except''': ''archives'' (see above), ''debian'', ''license'', ''pod'', ''testdata'', ''tests'',''tmp'' and ''var''. No files in the top level EPrints path directory need to be backed up. | ||
| + | |||
| + | |||
| + | Again, if you have the ability to take a virtual machine snapshot of your EPrints repository, it is worth using this to produce a clone, if you do not already have a test or pre-production server version of your EPrints repository. This will allow you to check if you will have any snags either with the upgrade process or with the upgraded repository itself. It should also allow you to refine your upgrade schedule of your live EPrint repository to reduce teh amount of scheduled downtime required. | ||
== Upgrade Schedules == | == Upgrade Schedules == | ||
Revision as of 09:26, 1 April 2021
This page is intended to provide guidance for those upgrading between versions of EPrints 3.4. (e.g. 3.4.1 to 3.4.2). This is generally intended for those upgrading using source tarballs available on files.eprints.org or upgrading tagged release from EPrints 3.4 GitHub repository. However, if you are upgrading through EPrints Deb or RPM package repostories and you experience issues this page should also contain helpful advice.
Contents
General Advice
If you are running EPrints as a virtual machine, then it is worthwhile taking a snapshot that your could revert back to this in the event of an unsuccessful upgrade. Otherwise, you should take the following backups before starting an upgrade:
- The EPrints database
- This will likely have the same name as the archive.
- The documents directory
- This is the documents directory, directly under the archive's directory (i.e. <EPRINTS_PATH>/archives/<ARCHIVE_NAME>/).
- The Xapian index
- This is in the var directory of the archive under the directory named or starting xapian.
- Your EPrints archive
- All the directories and any files in your archive, except: documents (see above), html and var (except xapian, see above). If you have multiple archives be sure to backup each one.
- The current EPrints codebase
- In case any changes have been made to this. These may be needed if you have to rollback an upgrade or also apply these changes if they are needed in the upgraded version of EPrints. All directories in the EPrints path (e.g. /opt/eprints3/ or /usr/share/eprints/) should be backed up except: archives (see above), debian, license, pod, testdata, tests,tmp and var. No files in the top level EPrints path directory need to be backed up.
Again, if you have the ability to take a virtual machine snapshot of your EPrints repository, it is worth using this to produce a clone, if you do not already have a test or pre-production server version of your EPrints repository. This will allow you to check if you will have any snags either with the upgrade process or with the upgraded repository itself. It should also allow you to refine your upgrade schedule of your live EPrint repository to reduce teh amount of scheduled downtime required.
