[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[EP-tech] [External Email]Re: Moving metadata and files across servers
CAUTION: This e-mail originated outside the University of Southampton.
When I've upgraded servers (different OS/MySQL/Eprints), I've used the XML export/import function. You can choose to embed the files in the XML file, or use the --enable-web-imports option on the new server to pull them over the network from the old server.
If you have import errors, you can export in reverse ID order; that's fixed it for me in the past.
mysql -u root -p --skip-column-names -e "select eprintid from eprint;" [archive_id] > ListOfEprintIDs.txt
tac < ListOfEprintIDs.txt > ListOfEprintIDs_rev.txt
~/bin/export [archive_id] archive XMLFiles $(cat ListOfEprintIDs_rev.txt) > ExportedEprintsWithFiles_rev.xml
~/bin/import [archive_id] --enable-import-fields --update --verbose archive XML 1604ExportedEprintsWithFiles_rev.xml
To get the users, you have to mysqldump the users table & import it into the new server.
Having the same Eprints version, you're probably better off using Alex's steps, but it's always good to have a fallback.
OCIO/CEC/IOD/IOSB/ARS Infrastructure Services
Email: dan.stieneke at usda.gov
From: eprints-tech-bounces at ecs.soton.ac.uk <eprints-tech-bounces at ecs.soton.ac.uk> On Behalf Of McCormick, Elizabeth via Eprints-tech
Sent: Thursday, November 17, 2022 9:12 AM
To: Alex Ball <ab318 at bath.ac.uk>; eprints-tech at ecs.soton.ac.uk
Subject: [External Email]Re: [EP-tech] Moving metadata and files across servers
If this message comes from an unexpected sender or references a vague/unexpected topic;
Use caution before clicking links or opening attachments.
Please send any concerns or suspicious messages to: Spam.Abuse at usda.gov<mailto:Spam.Abuse at usda.gov>
CAUTION: This e-mail originated outside the University of Southampton.
Thanks for the information. They are both using the same version of Eprints and I can ask the IT guy to make sure everything else is the same and up to date. I'll send him this email and see if he has any other questions. It definitely sounds like a project that can wait until the end of the academic year.
emccormick at radford.edu<mailto:emccormick at radford.edu>
"My body is my temple, and the goddess demands chocolate!"
From: Alex Ball <ab318 at bath.ac.uk<mailto:ab318 at bath.ac.uk>>
Sent: Thursday, November 17, 2022 11:07 AM
To: McCormick, Elizabeth <emccormick at radford.edu<mailto:emccormick at radford.edu>>; eprints-tech at ecs.soton.ac.uk<mailto:eprints-tech at ecs.soton.ac.uk>
Subject: Re: [EP-tech] Moving metadata and files across servers
NOTICE: This email originated externally. It is not from a Radford University account. Use caution responding, opening attachments, or clicking links.
Moving EPrints from one server to another is quite a technical process. I only have experience of moving our repository to a clean install in a new VM, but what it boils down to is (A) copying over the configuration and documents in your eprints/archives/[archive_id] folder, (B) dumping out your [archive_id] database from the source machine and loading into MySQL or whatever on your target machine, (C) connecting up the [archive_id] instance to the web server on the target machine.
If you are moving the repository into an existing EPrints installation, you will find this a lot easier if you have the same version of EPrints running on both machines, and ideally the same MySQL and web server versions as well. If you have plugins or configuration files that rely on Perl modules beyond those required by base EPrints, make sure those modules are also installed on the target machine. The existing repository on the target machine must have a different archive ID to the one you are trying to move.
You might find it easiest to do this in two stages.
1. On the target machine, use "epadmin create" to set up a fresh, empty repository using the same archive ID as the one on your source machine. Follow the usual steps to get it working. One snag is that you'll want the server to serve it from the domain name currently used by the source machine; one way to get around this is to edit the hosts file on your own computer (so just your computer will interpret the domain name as pointing to the target machine) if you have admin privileges, otherwise set up a new alias domain name you can point at the target machine. The former is preferable if you have to get SSL certificates working. Once you have this fresh installation working, you can move on to step two.
2. On the source machine, stop the indexer and prevent any more changes happening to the old repository (including any system-level cron jobs you might have set up). We use a maintenance mode script for continuity of service, but the brute force approach of shutting down the web server would work. Dump out the database to a file. (Bear in mind that if you are using your hosts file to direct requests to the new machine, this will also affect SSH requests using that domain name, so you may need to remove your override again while you do this.)
On the target machine, similarly stop the indexer and close any browser tabs accessing the fresh installation. Move the freshly created eprints/archives/[archive_id] folder to a backup location. Copy over the eprints/archives/[archive_id] folder from the source machine to the target machine, then copy some key files from the backup location to the normal location (in particular [archive_id]/cfg/cfg.d/database.pl with your new database credentials in it). Copy over the database dump and use it to restore the database into the target machine's MySQL (e.g. "mysql -p -u [archive_id] [archive_id] < backup.sql"). For good measure, you can ensure everything is back in sync by running "epadmin update [archive_id]"; you'll probably need to force a full re-index too: "epadmin reindex [archive_id] eprint".
Click around to make sure everything is working. Once you are happy it is, restart the indexer and then get the domain name to switch over from the source machine's IP address to the target machine's. Finish off by copying over any other system-level housekeeping things like cron jobs, and tidying up your temporary files.
I strongly recommend doing a dummy run, restoring your old EPrints to a close facsimile of the target VM, so you can verify the database backup/restore cycle has no nasty surprises, know exactly what files you will need replace with the fresh versions, and find out what system-level changes are needed on the target machine (if any). That way you can minimise the amount of time you spend in step 2 without a working repository.
I hope that helps, and good luck!
On Thu, 2022-11-17 at 14:11 +0000, McCormick, Elizabeth via Eprints-tech wrote:
I was not involved with the creation of our two Eprints repositories but now I handle their basic maintenance. Someone in campus IT deals with server-side maintenance. We have two servers; one is physical and ancient while the other is a VM. The physical server houses our electronic theses/dissertations; the VM houses our syllabi. I would like to move all the metadata and document files off the physical server and over to the VM both because the server itself could fail and because it makes no sense to have two machines going. What plug-in or module or process would we use in order to do that?
Alex Ball (he/him)
Research Data Librarian (Systems)
University of Bath, Bath BA2 7AY, UK
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
-------------- next part --------------
An HTML attachment was scrubbed...